From: Cong Wang <hidden> Date: 2014-06-04 00:12:16
When we jump to free_pcpu on failure in alloc_netdev_mqs()
rx and tx queues are not yet allocated, so no need to free them.
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Cong Wang <redacted>
---
net/core/dev.c | 5 -----
1 file changed, 5 deletions(-)
From: Cong Wang <hidden> Date: 2014-06-04 00:12:18
"list_kill" is allocated on stack and it's a list head,
it is pointless to call list_del(&kill_list) especially
after unregister_netdevice_many().
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Cong Wang <redacted>
---
drivers/net/macvlan.c | 1 -
net/core/rtnetlink.c | 1 -
2 files changed, 2 deletions(-)
From: David Miller <davem@davemloft.net> Date: 2014-06-04 00:24:53
From: Cong Wang <redacted>
Date: Tue, 3 Jun 2014 17:11:55 -0700
"list_kill" is allocated on stack and it's a list head,
it is pointless to call list_del(&kill_list) especially
after unregister_netdevice_many().
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Cong Wang <redacted>
Do not edit what you do not understand:
commit ceaaec98ad99859ac90ac6863ad0a6cd075d8e0e
Author: Eric Dumazet [off-list ref]
Date: Thu Feb 17 22:59:19 2011 +0000
net: deinit automatic LIST_HEAD
commit 9b5e383c11b08784 (net: Introduce
unregister_netdevice_many()) left an active LIST_HEAD() in
rollback_registered(), with possible memory corruption.
Even if device is freed without touching its unreg_list (and therefore
touching the previous memory location holding LISTE_HEAD(single), better
close the bug for good, since its really subtle.
(Same fix for default_device_exit_batch() for completeness)
Reported-by: Michal Hocko [off-list ref]
Tested-by: Michal Hocko [off-list ref]
Reported-by: Eric W. Biderman [off-list ref]
Tested-by: Eric W. Biderman [off-list ref]
Signed-off-by: Linus Torvalds [off-list ref]
Signed-off-by: Eric Dumazet [off-list ref]
CC: Ingo Molnar [off-list ref]
CC: Octavian Purdila [off-list ref]
CC: stable [off-list ref] [.33+]
Signed-off-by: David S. Miller [off-list ref]
From: Eric Dumazet <hidden> Date: 2014-06-04 00:43:03
On Tue, 2014-06-03 at 17:11 -0700, Cong Wang wrote:
"list_kill" is allocated on stack and it's a list head,
it is pointless to call list_del(&kill_list) especially
after unregister_netdevice_many().
How pointless exactly ? Explain more please.
I suggest you read various commits adding these list_del()
f87e6f47933e3ebeced9bb12615e830a72cedce4 is a good start.
On Tue, Jun 3, 2014 at 5:43 PM, Eric Dumazet [off-list ref] wrote:
On Tue, 2014-06-03 at 17:11 -0700, Cong Wang wrote:
quoted
"list_kill" is allocated on stack and it's a list head,
it is pointless to call list_del(&kill_list) especially
after unregister_netdevice_many().
How pointless exactly ? Explain more please.
I suggest you read various commits adding these list_del()
f87e6f47933e3ebeced9bb12615e830a72cedce4 is a good start.
From: David Miller <davem@davemloft.net> Date: 2014-06-04 02:19:16
From: Cong Wang <redacted>
Date: Tue, 3 Jun 2014 17:11:54 -0700
When we jump to free_pcpu on failure in alloc_netdev_mqs()
rx and tx queues are not yet allocated, so no need to free them.
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Cong Wang <redacted>
From: Daniel Borkmann <hidden> Date: 2014-06-04 08:26:29
On 06/04/2014 04:18 AM, Alexei Starovoitov wrote:
On Tue, Jun 3, 2014 at 5:43 PM, Eric Dumazet [off-list ref] wrote:
quoted
On Tue, 2014-06-03 at 17:11 -0700, Cong Wang wrote:
quoted
"list_kill" is allocated on stack and it's a list head,
it is pointless to call list_del(&kill_list) especially
after unregister_netdevice_many().
How pointless exactly ? Explain more please.
I suggest you read various commits adding these list_del()
f87e6f47933e3ebeced9bb12615e830a72cedce4 is a good start.
Indeed, thanks for the pointer. On that note, if you grep for
unregister_netdevice_many() invocations, you'll see many more
such cases that would need a list_del() actually.
From: Cong Wang <hidden> Date: 2014-06-06 06:40:48
On Tue, Jun 3, 2014 at 5:43 PM, Eric Dumazet [off-list ref] wrote:
On Tue, 2014-06-03 at 17:11 -0700, Cong Wang wrote:
quoted
"list_kill" is allocated on stack and it's a list head,
it is pointless to call list_del(&kill_list) especially
after unregister_netdevice_many().
How pointless exactly ? Explain more please.
I suggest you read various commits adding these list_del()
f87e6f47933e3ebeced9bb12615e830a72cedce4 is a good start.
If after unregister_netdevice_many() dev->unreg_list is still needed,
then it's a nightmare to maintain these list_head's in dev:
struct list_head dev_list;
struct list_head napi_list;
struct list_head unreg_list;
struct list_head close_list;
struct list_head todo_list;
Same for struct net.
From: Eric Dumazet <hidden> Date: 2014-06-06 13:17:43
On Thu, 2014-06-05 at 23:40 -0700, Cong Wang wrote:
On Tue, Jun 3, 2014 at 5:43 PM, Eric Dumazet [off-list ref] wrote:
quoted
On Tue, 2014-06-03 at 17:11 -0700, Cong Wang wrote:
quoted
"list_kill" is allocated on stack and it's a list head,
it is pointless to call list_del(&kill_list) especially
after unregister_netdevice_many().
How pointless exactly ? Explain more please.
I suggest you read various commits adding these list_del()
f87e6f47933e3ebeced9bb12615e830a72cedce4 is a good start.
If after unregister_netdevice_many() dev->unreg_list is still needed,
then it's a nightmare to maintain these list_head's in dev:
struct list_head dev_list;
struct list_head napi_list;
struct list_head unreg_list;
struct list_head close_list;
struct list_head todo_list;
Same for struct net.
You did not really understood the problem.
This has _nothing_ to do with dev->unreg_list
Really this is all explained in the commit I gave.
In fact I suspect following is even needed :
Force the list_del() in unregister_netdevice_many(), because is really
too confusing and a common source of bugs.
I'll send a patch.
From: Eric Dumazet <hidden> Date: 2014-06-06 13:44:06
From: Eric Dumazet <edumazet@google.com>
unregister_netdevice_many() API is error prone and we had too
many bugs because of dangling LIST_HEAD on stacks.
See commit f87e6f47933e3e ("net: dont leave active on stack LIST_HEAD")
In fact, instead of making sure no caller leaves an active list_head,
just force a list_del() in the callee. No one seems to need to access
the list after unregister_netdevice_many()
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
I based this patch on net-next, but it seems to close existing bugs,
so its probably a stable candidate.
drivers/net/macvlan.c | 1 -
net/core/dev.c | 5 ++++-
net/core/rtnetlink.c | 1 -
net/mac80211/iface.c | 1 -
4 files changed, 4 insertions(+), 4 deletions(-)
On Fri, Jun 6, 2014 at 6:44 AM, Eric Dumazet [off-list ref] wrote:
From: Eric Dumazet <edumazet@google.com>
unregister_netdevice_many() API is error prone and we had too
many bugs because of dangling LIST_HEAD on stacks.
See commit f87e6f47933e3e ("net: dont leave active on stack LIST_HEAD")
In fact, instead of making sure no caller leaves an active list_head,
just force a list_del() in the callee. No one seems to need to access
the list after unregister_netdevice_many()
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
I based this patch on net-next, but it seems to close existing bugs,
so its probably a stable candidate.
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: David Miller <davem@davemloft.net> Date: 2014-06-08 21:15:32
From: Eric Dumazet <redacted>
Date: Fri, 06 Jun 2014 06:44:03 -0700
From: Eric Dumazet <edumazet@google.com>
unregister_netdevice_many() API is error prone and we had too
many bugs because of dangling LIST_HEAD on stacks.
See commit f87e6f47933e3e ("net: dont leave active on stack LIST_HEAD")
In fact, instead of making sure no caller leaves an active list_head,
just force a list_del() in the callee. No one seems to need to access
the list after unregister_netdevice_many()
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
I based this patch on net-next, but it seems to close existing bugs,
so its probably a stable candidate.
It applied cleanly to net so I applied it there and will queue up for -stable,
thanks.
From: Eric Dumazet <edumazet@google.com>
unregister_netdevice_many() API is error prone and we had too
many bugs because of dangling LIST_HEAD on stacks.
See commit f87e6f47933e3e ("net: dont leave active on stack LIST_HEAD")
In fact, instead of making sure no caller leaves an active list_head,
just force a list_del() in the callee. No one seems to need to access
the list after unregister_netdevice_many()
From: Eric Dumazet <hidden> Date: 2014-06-09 05:48:03
On Mon, 2014-06-09 at 09:27 +0800, Gao feng wrote:
On 06/06/2014 09:44 PM, Eric Dumazet wrote:
quoted
From: Eric Dumazet <edumazet@google.com>
unregister_netdevice_many() API is error prone and we had too
many bugs because of dangling LIST_HEAD on stacks.
See commit f87e6f47933e3e ("net: dont leave active on stack LIST_HEAD")
In fact, instead of making sure no caller leaves an active list_head,
just force a list_del() in the callee. No one seems to need to access
the list after unregister_netdevice_many()
From: Cong Wang <hidden> Date: 2014-06-09 05:58:21
On Fri, Jun 6, 2014 at 6:17 AM, Eric Dumazet [off-list ref] wrote:
You did not really understood the problem.
This has _nothing_ to do with dev->unreg_list
Really this is all explained in the commit I gave.
I did understand it, even before sending my patch.
I just don't even like this piece of sh*t, really, we have
to rewrite it, even after you move the list_del() into the callee.
It is still as ugly as it was.