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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ