n.c:359
[<6839b4d0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes: cb626bf566eb ("net-sysfs: Fix reference count leak")
Reported-by: Hulk Robot
Signed-off-by: Weilong Chen
---
net/core/rtnetlink.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --
On 2020/7/15 13:45, Cong Wang wrote:
> On Tue, Jul 14, 2020 at 6:27 PM Weilong Chen wrote:
>>
>> When vlan_newlink call register_vlan_dev fails, it might return error
>> with dev->reg_state = NETREG_UNREGISTERED. The rtnl_newlink should
>> free the memory. But cu
n.c:359
[<6839b4d0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes: e51fb152318ee6 ("rtnetlink: fix a memory leak when ->newlink fails")
Reported-by: Hulk Robot
Cc: David S. Miller
Signed-off-by: Wei Yongjun
Signed-off-by: Weilong Chen
---
net/core/rtnetlink.c
on.c:359
[<6839b4d0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes: e51fb152318ee6 (rtnetlink: fix a memory leak when ->newlink fails)
Reported-by: Hulk Robot
Cc: David S. Miller
Signed-off-by: Wei Yongjun
Signed-off-by: Weilong Chen
---
net/core/rtnetlink.c | 3 ++-
1
.c:359
[<6839b4d0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes: commit e51fb152318ee6 (rtnetlink: fix a memory leak when ->newlink fails)
Cc: David S. Miller
Reported-by: Hulk Robot
Signed-off-by: Weilong Chen
---
net/core/rtnetlink.c | 3 ++-
1 file changed, 2 inser
On 2020/7/14 3:02, David Miller wrote:
> From: Weilong Chen
> Date: Mon, 13 Jul 2020 15:55:28 +0800
>
>> When vlan_newlink call register_vlan_dev fails, it might return error
>> with dev->reg_state = NETREG_UNREGISTERED. The rtnl_newlink should
>> free the memory. B
ket.c:672
[<1c30ffe4>] sys_sendmsg+0x5f5/0x780 net/socket.c:2352
[<b71ca6f3>] ___sys_sendmsg+0x11d/0x1a0 net/socket.c:2406
[<07297384>] __sys_sendmsg+0xeb/0x1b0 net/socket.c:2439
[<0eb29b11>] do_syscall_64+0x56/0xa0 arch/x86/entry/commo
5Ew/aPdYLXfYBQAJ
Reported-by: syzbot+52fced2d288f8ecd2...@syzkaller.appspotmail.com
Cc: Qian Cai
Cc: Oleg Nesterov
Cc: Christian Brauner
Cc: Marco Elver
Signed-off-by: Zefan Li
Signed-off-by: Weilong Chen
---
kernel/fork.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ker
ror:
https://bugzilla.kernel.org/show_bug.cgi?id=208245
Signed-off-by: Weilong Chen
---
drivers/virtio/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 5809e5f5b157..5c92e4a50882 100644
--- a/drivers/virtio/Kconfig
+++ b/driv
_do_fork+0xf7/0x790 kernel/fork.c:2430
__do_sys_clone+0xf9/0x130 kernel/fork.c:2585
__se_sys_clone kernel/fork.c:2566 [inline]
__x64_sys_clone+0x6c/0x80 kernel/fork.c:2566
do_syscall_64+0xc7/0x3b0 arch/x86/entry/common.c:295
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Signed-off-by: Weilong Chen
Hi, when we change the mtu to a small value, for example, ifconfig eth0
mtu 68, IPERF test shows there's a great bandwidth drop while previous
kernel versions don't.
Git bisect find the differences is from the patch
28d35bcdd3925e7293408cdb8aa5f2aac5f0d6e3 (net: ipv4: don't let PMTU
updates
Hi,
We came across this problem:
Second kernel hang with intel_iommu=on
We can reproduce the problem by the following steps:
1. start the kernel with intel_iommu=on
2. ifconfig eth6 up;ifconfig eth8 up.(eth6 is Intel Corporation 82599ES
10-Gigabit and eth8 is Broadcom Limited NetXtreme BCM5719
Hi,
We came across this problem:
Second kernel hang with intel_iommu=on
We can reproduce the problem by the following steps:
1. start the kernel with intel_iommu=on
2. ifconfig eth6 up;ifconfig eth8 up.(eth6 is Intel Corporation 82599ES
10-Gigabit and eth8 is Broadcom Limited NetXtreme BCM5719
imeout:
...
ent->timeout -= timeout_period;
if (ent->timeout > 0)
return;
...
The type of timeout_period is long, but ent->timeout is unsigned long.
This patch makes the type consistent.
Reported-by: Weilong Chen <chenweil...@huawei.com>
Signed-off-
out -= timeout_period;
if (ent->timeout > 0)
return;
...
The type of timeout_period is long, but ent->timeout is unsigned long.
This patch makes the type consistent.
Reported-by: Weilong Chen
Signed-off-by: Corey Minyard
---
I like to keep things consistent (though
, but ent->timeout is unsigned long.
This patch makes the type consistent.
Signed-off-by: Weilong Chen <chenweil...@huawei.com>
---
drivers/char/ipmi/ipmi_msghandler.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/char/ipmi/ipmi_msghandler.c
b
, but ent->timeout is unsigned long.
This patch makes the type consistent.
Signed-off-by: Weilong Chen
---
drivers/char/ipmi/ipmi_msghandler.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/char/ipmi/ipmi_msghandler.c
b/drivers/char/ipmi/ipmi_msghandler.c
i
to 60 bytes.
- Alex
On Tue, Dec 20, 2016 at 3:50 AM, Weilong Chen <chenweil...@huawei.com> wrote:
Hi,
Thanks for you reply.
We test you patch, but the problem is still there, it seems do not work.
I'm not sure why ixgbe use the limit 17. The kenel use ETH_ZLEN (60) with
out FCS. A lot of
to 60 bytes.
- Alex
On Tue, Dec 20, 2016 at 3:50 AM, Weilong Chen wrote:
Hi,
Thanks for you reply.
We test you patch, but the problem is still there, it seems do not work.
I'm not sure why ixgbe use the limit 17. The kenel use ETH_ZLEN (60) with
out FCS. A lot of drivers such as e1000 use it. Any e
:
On Thu, Dec 15, 2016 at 3:40 AM, Weilong Chen <chenweil...@huawei.com> wrote:
Nessus report the vf appears to leak memory in network packets.
Fix this by padding all small packets manually.
And the CVE-2003-0001.
https://ofirarkin.files.wordpress.com/2008/11/atstake_etherleak_report.pdf
:
On Thu, Dec 15, 2016 at 3:40 AM, Weilong Chen wrote:
Nessus report the vf appears to leak memory in network packets.
Fix this by padding all small packets manually.
And the CVE-2003-0001.
https://ofirarkin.files.wordpress.com/2008/11/atstake_etherleak_report.pdf
Signed-off-by: Weilong Chen
Nessus report the vf appears to leak memory in network packets.
Fix this by padding all small packets manually.
And the CVE-2003-0001.
https://ofirarkin.files.wordpress.com/2008/11/atstake_etherleak_report.pdf
Signed-off-by: Weilong Chen <chenweil...@huawei.com>
---
drivers/net/ethernet
Nessus report the vf appears to leak memory in network packets.
Fix this by padding all small packets manually.
And the CVE-2003-0001.
https://ofirarkin.files.wordpress.com/2008/11/atstake_etherleak_report.pdf
Signed-off-by: Weilong Chen
---
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
modules does.
Steps to reproduce:
while true; do modprobe xfs; rmmod xfs; done
vs
while true; do cat /proc/kallsyms >/dev/null; done
Signed-off-by: Weilong Chen
---
kernel/kallsyms.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index 5c5987f..e09d
modules does.
Steps to reproduce:
while true; do modprobe xfs; rmmod xfs; done
vs
while true; do cat /proc/kallsyms >/dev/null; done
Signed-off-by: Weilong Chen <chenweil...@huawei.com>
---
kernel/kallsyms.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/kallsyms.c b/ke
modules does.
Steps to reproduce:
while true; do modprobe xfs; rmmod xfs; done
vs
while true; do cat /proc/kallsyms >/dev/null; done
ref:http://lkml.iu.edu/hypermail/linux/kernel/0703.1/2582.html
https://bugzilla.kernel.org/show_bug.cgi?id=111541
Signed-off-by: Weilong Chen
---
kernel/ka
modules does.
Steps to reproduce:
while true; do modprobe xfs; rmmod xfs; done
vs
while true; do cat /proc/kallsyms >/dev/null; done
ref:http://lkml.iu.edu/hypermail/linux/kernel/0703.1/2582.html
https://bugzilla.kernel.org/show_bug.cgi?id=111541
Signed-off-by: Weilong Chen <chenweil.
27 matches
Mail list logo
