On 23.12.2017 21:10, Mathias Tillman wrote:
Thank you, I will test that patch and see if I can find anything interesting in the log. Will have to be some time later next week due to
the holidays, but I will get back to you with the results.
Ok, I'll be waiting.
Probably you could share your kernel config and lsmod output?
What commit are you referring to exactly? I can test it to see if it's fixed.
Commit that was added into v4.4.103 - 76da0704507bbc51875013f6557877ab308cfd0a upstream.
Also, I should mention that it's not just vsftpd it causes problems with - some other people have reported problems with starting and
stopping lxc containers. I don't use those myself so I can't really comment on that, but it does seem to have been fixed by reverting the
commit I mentioned.
Yes. This is common problem for all network namespaces.
Bug somewhere else and requires particular configuration.
Greg: Can't say if the problem exists on master or not - I'm really only able to reproduce it on the Turris Omnia router as I said in the
bug report. It's based on openwrt and requires some device-specific patches to function properly, so I'm not sure it would work on the
latest - but I can give it a try.
Regards
Mathias
On Sat, 23 Dec 2017, 17:36 Konstantin Khlebnikov, <khlebnikov@xxxxxxxxxxxxxx <mailto:khlebnikov@xxxxxxxxxxxxxx>> wrote:
On 23.12.2017 16:52, Greg KH wrote:
> adding stable@ and netdev@
>
> On Sat, Dec 23, 2017 at 10:49:27AM +0000, Mathias Tillman wrote:
>> Hi, I wanted to make you aware of a recent regression to the Linux kernel
>> introduced with commit 2417da3f4d6bc4fc6c77f613f0e2264090892aa5:
>>
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/net/ipv6?h=linux-4.4.y&id=2417da3f4d6bc4fc6c77f613f0e2264090892aa5
>
> Is this issue also present in Linus's tree?
>
>> I have reported it here:
>> https://bugzilla.kernel.org/show_bug.cgi?id=198189
>
> Bugzilla doesn't work for networking bugs, nor stable stuff, just for a
> few subsystems, sorry.
>
>> Basically, that commit causes an endless loop if, for some reason, not all
>> devices are unregistered in the rollback_registered_many function in
>> net/dev.c
>>
>> Decided to contact you directly since I have yet to receive any reply on
>> the bug report, and I wasn't entirely sure what the procedure was. Please
>> do let me know if I have to change anything in the report.
>
> I can revert it, but it would be good to verify if this is an issue in
> the latest releases or not first.
Most likely bug fixed by that commit hid refcount leak for loopback device.
Mathias, please try debug patch from attachment.
It logs all refcount changes for loopback in non-host net namespace.
Hopefully log would will be tiny and show what is missing.
Looks like vsftpd creates and destroys empty net-ns, like "unshare -n true"