Re: [PATCH net 1/2] sit: allow to use rtnl ops on fb tunnel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Oct 2, 2013 at 3:15 AM, Nicolas Dichtel
<nicolas.dichtel@xxxxxxxxx> wrote:
> Le 01/10/2013 18:59, David Miller a écrit :
>
>> From: Nicolas Dichtel <nicolas.dichtel@xxxxxxxxx>
>> Date: Tue,  1 Oct 2013 18:04:59 +0200
>>
>>> rtnl ops where introduced by ba3e3f50a0e5 ("sit: advertise tunnel param
>>> via
>>> rtnl"), but I forget to assign rtnl ops to fb tunnels.
>>>
>>> Now that it is done, we must remove the explicit call to
>>> unregister_netdevice_queue(), because  the fallback tunnel is added to
>>> the queue
>>> in sit_destroy_tunnels() when checking rtnl_link_ops of all netdevices
>>> (this
>>> is valid since commit 5e6700b3bf98 ("sit: add support of x-netns")).
>>>
>>> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@xxxxxxxxx>
>>
>>
>> Applied and queued up for -stable.
>>
>> But I imagine since the x-netns changes aren't in various -stable
>> branches this will need to be adjusted a bit?
>
> Yes, it's what I've tried to say in the commit log ;-)
>
> In fact, before the x-netns changes, we must keep the
> unregister_netdevice_queue() line.

In 3.11 linux-stable, this patch was merged between 3.11.4 and 3.11.5
in commit 3783100, after the x-netns changes in commit 5e6700b3bf, but
the unregister_netdevice_queue was kept.

I think that caused the following bug. In 3.11.6, a simple `modprobe
sit && rmmod sit` hits the BUG at net/core/dev.c:5039:

  BUG_ON(dev->reg_state != NETREG_REGISTERED);

The device is actually NETREG_RELEASED at one point because the device
is now unregistered twice. The issue goes away by porting the
remainder of the original commit: the one liner that removes the call
to unregister_netdevice_queue.

+++ b/net/ipv6/sit.c
@@ -1708,7 +1708,6 @@ static void __net_exit sit_exit_net(struct net *net)

        sit_destroy_tunnels(sitn, &list);
-       unregister_netdevice_queue(sitn->fb_tunnel_dev, &list);
        unregister_netdevice_many(&list);

If correct, let me know if I should send a proper one-line patch
against 3.11.y. Since I haven't looked at this code before, I found it
safer to report the issue first.

5e6700b3bf was not applied to 3.10 stable, so that branch is not affected.
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]