netdev - Re: "ip netns create" hangs forever, spamming console with "unregister_netdevice: waiting for lo to become free"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKCAbMj9tKg95mNyUQZxRHxtTTCb2BQxYLehtA8XjD7Sf_t1Cw@mail.gmail.com>
Date:	Tue, 26 May 2015 14:56:41 -0400
From:	Zack Weinberg <zackw@...ix.com>
To:	netdev@...r.kernel.org
Subject: Re: "ip netns create" hangs forever, spamming console with
 "unregister_netdevice: waiting for lo to become free"

On Tue, May 26, 2015 at 12:21 PM, Zack Weinberg <zackw@...ix.com> wrote:
> I have an application that makes heavy use of network namespaces,
> creating and destroying them on the fly during operation.  With 100%
> reproducibility, the first invocation of "ip netns create" after any
> "ip netns del" hangs forever in D-state; only rebooting the machine
> clears the condition.

Following up to myself to say that reproduction is not as simple as
'ip netns add test; ip netns del test; ip netns add test2'.  In fact,
not even bringing the namespace (and all associated interfaces) up and
then  down again _exactly_ as my production code does it will trigger
the bug.  It appears to be necessary to push a significant amount of
data through interfaces attached to the namespace.

Since I had to reset the machine to attempt to create a repro recipe,
I can no longer perform diagnostics on the hung processes, but I've
restarted the application and it should reach the problem state again
in a day or two.

zw
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html