netdev - Re: RFC Hanging clean-up of a namespace

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]

Date:	Sun, 22 Jan 2012 23:17:00 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Hans Schillstrom <hans.schillstrom@...csson.com>
Cc:	Hagen Paul Pfeifer <hagen@...u.net>,
	David Miller <davem@...emloft.net>,
	"equinox\@diac24.net" <equinox@...c24.net>,
	"netdev\@vger.kernel.org" <netdev@...r.kernel.org>
Subject: Re: RFC Hanging clean-up of a namespace

Hans Schillstrom <hans.schillstrom@...csson.com> writes:

> On Monday 23 January 2012 07:25:52 Eric W. Biederman wrote:
>> Hans Schillstrom <hans.schillstrom@...csson.com> writes:
>> 
>> > On Friday 20 January 2012 21:55:27 Eric W. Biederman wrote:
>> >> My current hypothesis is that the namespace actually didn't get freed
>> >> until the tcp socket finished closing.  You can check by looking at when
>> >> __put_net and then cleanup_net are called.
>> >
>> > __put_net() is called just after tcp_write_timer() fires and then
>> > cleanup_net()
>> 
>> Hypothesis confirmed.  Your speed problem is that it is taking 2 minutes
>> in the pathological case for your tcp socket to close.
>> 
>> Do you have any clue why it is taking your sockets so long to close?
>> Is the other side simply not responding?
>> 
>
> The root cause of death is that the other side (init_net namespace) dies first 
> and when it dies all containers will be killed ...

?????

init_net can not die.  init_net must not die.  It makes no sense for the
ref count on init_net to drop to 0.  Among other places every kernel
thread uses init_net.  Furthermore the network namespaces are
independent so even the impossible death of the initial network
namespace should not kill a child network namespace.

Did I misunderstand what you said?

If you have a setup where you stop being able to talk to the outside
world because you were relaying through the initial network namespace
and the relay through the initial network namespace stopped functioning
that makes sense.  So effectively all of your packets are being dropped
on the floor the tcp retransmit behavior on closing a socket makes
sense.  I just don't get how you have triggered that state.

Eric
--
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