regression (4.10) - interface remove uevents not generated

regression (4.10) - interface remove uevents not generated

[Mantas Mikulėnas]

Hello,

It seems that commit 002d8a1a6c11b9b2a8ac615095589111dd52749b ("net:
skip genenerating uevents for network namespaces that are exiting")
broke 'remove' uevents for *all* network interfaces, even for those in
the main/default namespace.

Other than breaking some of my udev rules, this also causes problems for
NetworkManager, which apparently relies on those uevents to update its
interface information cache. (I ended up reverting that commit locally
just so I could connect to VPNs again.)

This problem is present in both v4.10.1 and current master
(v4.11-rc1-290-g434fd6353b4c).

-- 
Mantas Mikulėnas <grawity@gmail.com>

Re: regression (4.10) - interface remove uevents not generated

[Andrei Vagin]

[-- Attachment #1: Type: text/plain, Size: 812 bytes --]

Hi Mantas,

Thank you for the report. Could you try out the attached patch?

On Sat, Mar 11, 2017 at 05:10:22PM +0200, Mantas Mikulėnas wrote:
> Hello,
> 
> It seems that commit 002d8a1a6c11b9b2a8ac615095589111dd52749b ("net:
> skip genenerating uevents for network namespaces that are exiting")
> broke 'remove' uevents for *all* network interfaces, even for those in
> the main/default namespace.
> 
> Other than breaking some of my udev rules, this also causes problems for
> NetworkManager, which apparently relies on those uevents to update its
> interface information cache. (I ended up reverting that commit locally
> just so I could connect to VPNs again.)
> 
> This problem is present in both v4.10.1 and current master
> (v4.11-rc1-290-g434fd6353b4c).
> 
> -- 
> Mantas Mikulėnas <grawity@gmail.com>

[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 691 bytes --]

diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
index 3c4bbec..20c48cf 100644
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -34,6 +34,7 @@ EXPORT_SYMBOL_GPL(net_namespace_list);
 
 struct net init_net = {
 	.dev_base_head = LIST_HEAD_INIT(init_net.dev_base_head),
+	.exit_list = LIST_HEAD_INIT(init_net.exit_list),
 };
 EXPORT_SYMBOL(init_net);
 
@@ -286,6 +287,7 @@ static __net_init int setup_net(struct net *net, struct user_namespace *user_ns)
 	net->user_ns = user_ns;
 	idr_init(&net->netns_ids);
 	spin_lock_init(&net->nsid_lock);
+	INIT_LIST_HEAD(&net->exit_list);
 
 	list_for_each_entry(ops, &pernet_list, list) {
 		error = ops_init(ops, net);

Re: regression (4.10) - interface remove uevents not generated

[Mantas Mikulėnas]

On 2017-03-11 21:50, Andrei Vagin wrote:
> Hi Mantas,
> 
> Thank you for the report. Could you try out the attached patch?

Thanks, I tested it on current master but it doesn't seem to help; there
still aren't any uevents for removed interfaces.

-- 
Mantas Mikulėnas <grawity@gmail.com>

Re: regression (4.10) - interface remove uevents not generated

[Andrei Vagin]

[-- Attachment #1: Type: text/plain, Size: 474 bytes --]

On Sat, Mar 11, 2017 at 11:24:34PM +0200, Mantas Mikulėnas wrote:
> On 2017-03-11 21:50, Andrei Vagin wrote:
> > Hi Mantas,
> > 
> > Thank you for the report. Could you try out the attached patch?
> 
> Thanks, I tested it on current master but it doesn't seem to help; there
> still aren't any uevents for removed interfaces.

I reproduced the issue on my host and the correct patch is attached to
this message. Thanks!

> 
> -- 
> Mantas Mikulėnas <grawity@gmail.com>
> 

[-- Attachment #2: 0001-net-check-net-count-to-check-whether-a-netns-is-aliv.patch --]
[-- Type: text/plain, Size: 1976 bytes --]

>From 456e28813d40f2076d4b9346fe8633c83b7a19d8 Mon Sep 17 00:00:00 2001
From: Andrei Vagin <avagin@openvz.org>
Date: Sat, 11 Mar 2017 15:18:25 -0800
Subject: [PATCH] net: check net->count to check whether a netns is alive or
 not

The previous idea was to check whether a net namespace is in
net_exit_list or not. It doesn't work, because net->exit_list is used in
__register_pernet_operations and __unregister_pernet_operations where
all namespaces are added to a temporary list to make cleanup in error
cases, so list_empty(&net->exit_list) always returns false.

Fixes: 002d8a1a6c11 ("net: skip genenerating uevents for network namespaces that are exiting")
Signed-off-by: Andrei Vagin <avagin@openvz.org>
---
 net/core/net-sysfs.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index b0c04cf..1004418 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -952,7 +952,7 @@ net_rx_queue_update_kobjects(struct net_device *dev, int old_num, int new_num)
 	while (--i >= new_num) {
 		struct kobject *kobj = &dev->_rx[i].kobj;
 
-		if (!list_empty(&dev_net(dev)->exit_list))
+		if (!atomic_read(&dev_net(dev)->count))
 			kobj->uevent_suppress = 1;
 		if (dev->sysfs_rx_queue_group)
 			sysfs_remove_group(kobj, dev->sysfs_rx_queue_group);
@@ -1370,7 +1370,7 @@ netdev_queue_update_kobjects(struct net_device *dev, int old_num, int new_num)
 	while (--i >= new_num) {
 		struct netdev_queue *queue = dev->_tx + i;
 
-		if (!list_empty(&dev_net(dev)->exit_list))
+		if (!atomic_read(&dev_net(dev)->count))
 			queue->kobj.uevent_suppress = 1;
 #ifdef CONFIG_BQL
 		sysfs_remove_group(&queue->kobj, &dql_group);
@@ -1557,7 +1557,7 @@ void netdev_unregister_kobject(struct net_device *ndev)
 {
 	struct device *dev = &(ndev->dev);
 
-	if (!list_empty(&dev_net(ndev)->exit_list))
+	if (!atomic_read(&dev_net(ndev)->count))
 		dev_set_uevent_suppress(dev, 1);
 
 	kobject_get(&dev->kobj);
-- 
2.9.3

Re: regression (4.10) - interface remove uevents not generated

[Mantas Mikulėnas]

On 2017-03-12 08:51, Andrei Vagin wrote:
> On Sat, Mar 11, 2017 at 11:24:34PM +0200, Mantas Mikulėnas wrote:
>> On 2017-03-11 21:50, Andrei Vagin wrote:
>>> Hi Mantas,
>>>
>>> Thank you for the report. Could you try out the attached patch?
>>
>> Thanks, I tested it on current master but it doesn't seem to help; there
>> still aren't any uevents for removed interfaces.
> 
> I reproduced the issue on my host and the correct patch is attached to
> this message. Thanks!

Just tested, the new patch seems to be working fine here.

Thanks for the quick fix; any chance of getting it into 4.10.x as well?

-- 
Mantas Mikulėnas <grawity@gmail.com>