Kernel BUG on network namespace deletion

Kernel BUG on network namespace deletion

[Марк Коренберг]

Kernel 6.6.9-200.fc39.x86_64

The following bash script demonstrates the problem (run under root):

```
#!/bin/bash

set -e -u -x

# Some cleanups
ip netns delete myspace || :
ip link del qweqwe1 || :

# The bug happens only with physical interfaces, not with, say, dummy one
ip link property add dev enp0s20f0u2 altname myname
ip netns add myspace
ip link set enp0s20f0u2 netns myspace

# add dummy interface + set the same altname as in background namespace.
ip link add name qweqwe1 type dummy
ip link property add dev qweqwe1 altname myname

# Trigger the bug. The kernel will try to return ethernet interface
# back to root namespace, but it can not, because of conflicting
# altnames.
ip netns delete myspace

# now `ip link` will hang forever !!!!!
```

I think, the problem is obvious. Although I don't know how to fix.
Remove conflicting altnames for interfaces that returns from killed
namespaces ?

On kernel 6.3.8 (at least) was another bug, that allows duplicate
altnames, and it was fixed mainline somewhere. I have another script
to trigger the bug on these old kernels. I did not bisect.

````
[  494.473906] default_device_exit_net: failed to move enp0s20f0u2 to
init_net: -17
[  494.473926] ------------[ cut here ]------------
[  494.473927] kernel BUG at net/core/dev.c:11520!
[  494.473932] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
[  494.473935] CPU: 3 PID: 3852 Comm: kworker/u32:17 Not tainted
6.6.9-200.fc39.x86_64 #1
[  494.473938] Workqueue: netns cleanup_net
[  494.473944] RIP: 0010:default_device_exit_batch+0x295/0x2a0
```

-- 
Segmentation fault

Re: Kernel BUG on network namespace deletion

[Jakub Kicinski]

On Mon, 15 Jan 2024 18:59:54 +0500 Марк Коренберг wrote:
> Kernel 6.6.9-200.fc39.x86_64
> 
> The following bash script demonstrates the problem (run under root):

Hi thank you for the report and analysis, fix will be coming shortly..

Re: kernel BUG on network namespace deletion

[Марк Коренберг]

Hi, netdev. I have found a bug in the Linux Kernel. Please take a look.

пн, 15 янв. 2024 г. в 13:25, Greg KH <gregkh@linuxfoundation.org>:
>
> On Mon, Jan 15, 2024 at 12:19:06PM +0500, Марк Коренберг wrote:
> > Kernel 6.6.9-200.fc39.x86_64
> >
> > The following bash script demonstrates the problem (run under root):
> >
> > ```
> > #!/bin/bash
> >
> > set -e -u -x
> >
> > # Some cleanups
> > ip netns delete myspace || :
> > ip link del qweqwe1 || :
> >
> > # The bug happens only with physical interfaces, not with, say, dummy one
> > ip link property add dev enp0s20f0u2 altname myname
> > ip netns add myspace
> > ip link set enp0s20f0u2 netns myspace
> >
> > # add dummy interface + set the same altname as in background namespace.
> > ip link add name qweqwe1 type dummy
> > ip link property add dev qweqwe1 altname myname
> >
> > # Trigger the bug. The kernel will try to return ethernet interface
> > back to root namespace, but it can not, because of conflicting
> > altnames.
> > ip netns delete myspace
> >
> > # now `ip link` will hang forever !!!!!
> > ```
> >
> > I think, the problem is obvious. Althougn I don't know how to fix.
> > Remove conflicting altnames for interfaces that returns from killed
> > namespaces ?
>
> As this can only be triggered by root, not much for us to do here,
> perhaps discuss it on the netdev mailing list for all network developers
> to work on?
>
> > On kernel 6.3.8 (at least) was another bug, that allows dulicate
> > altnames, and it was fixed mainline somewhere. I have another script
> > to trigger the bug on these old kernels. I did not bisect.
>
> If this is an issue on 6.1.y, that would be good to know so that we can
> try to fix the issue there if bisection can find it.  Care to share the
> script so that I can test?
>
> thanks,
>
> greg k-h



-- 
Segmentation fault

Re: kernel BUG on network namespace deletion

[Greg KH]

On Mon, Jan 15, 2024 at 03:00:36PM +0500, Марк Коренберг wrote:
> Hi, netdev. I have found a bug in the Linux Kernel. Please take a look.

That's not a good way to post, sorry.  Also what does this have to do
with stable@?

Please resend your original message to netdev, top-posting doesn't go
very well here, as per the email guidelines in our documentation :)

thanks,

greg k-h