netdev - Re: [PATCH] netns: fix net_alloc

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 for Android: free password hash cracker in your pocket

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

Message-ID: <m1k44d8wkw.fsf@fess.ebiederm.org>
Date:	Thu, 26 Jan 2012 22:54:07 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Pavel Emelyanov <xemul@...allels.com>,
	Sjur Brændeland <sjur.brandeland@...ricsson.com>,
	"levinsasha928\@gmail.com" <levinsasha928@...il.com>,
	"netdev\@vger.kernel.org" <netdev@...r.kernel.org>,
	"davem\@davemloft.net" <davem@...emloft.net>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
	"davej\@redhat.com" <davej@...hat.com>,
	"sjurbren\@gmail.com" <sjurbren@...il.com>
Subject: Re: [PATCH] netns: fix net_alloc_generic()

Eric Dumazet <eric.dumazet@...il.com> writes:

> Le jeudi 26 janvier 2012 à 14:57 -0800, Eric W. Biederman a écrit :
>
>> It is not a chicken and egg problem.  It is a bug in caif.
>> caif is claiming to be a network device when it is acting as a subsytem.
>> That means it is being initialized too late.
>> 
>
> Ah ok !
>
>> Untested but this should trivially fix the problem, and a bunch
>> of others of the same ilk.
>> 
>
> Hmm, please refrain from using "trivially" or "trivial", you're not
> fooling anyone.

All I meant is that the change was trivial.

> Truth is this netns layer is horribly complex, since this CAIF bug
> needed no more than four patch attempts and lastly your own work before
> finding the root cause.

As for the complexity I don't know that it is noticeably worse than the
initialization complexity of the network stack in general.

I do think that it is non-obvious that serious initialization ordering
problems can be caused by such a small difference.  The non-locality
and of cause and effect, combined with unfamiliarity of the code seems
to be what hides problems like this.

Once you know that initialization ordering problems tend to registering
the wrong way.  Aka as a device instead of a subsys the solution to
problems like this tend to jump out at you.

Now the common plumbing in net/core/net_namespace.c does count as
complex.  The fact we missed such an obvious optimization opportunity
for so long seems to confirm that.

I am open for ideas on how to simply things.  

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