linux-kernel - Re: Odd ENOMEM being returned in 3.8-rcX

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:	Fri, 8 Feb 2013 15:40:38 -0500
From:	Josh Boyer <jwboyer@...hat.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	Mel Gorman <mgorman@...e.de>, linux-kernel@...r.kernel.org,
	williams@...hat.com
Subject: Re: Odd ENOMEM being returned in 3.8-rcX

On Fri, Feb 08, 2013 at 12:36:08PM -0800, Eric W. Biederman wrote:
> Josh Boyer <jwboyer@...hat.com> writes:
> >> OK.  I've bisected this down to:
> >> 
> >> 50804fe3737ca6a5942fdc2057a18a8141d00141 is the first bad commit
> >> commit 50804fe3737ca6a5942fdc2057a18a8141d00141
> >> Author: Eric W. Biederman <ebiederm@...ssion.com>
> >> Date:   Tue Mar 2 15:41:50 2010 -0800
> >> 
> >>     pidns: Support unsharing the pid namespace.
> >>     
> >> 
> >> I haven't really gotten much farther than that yet, but the bisect was
> >> pretty straight forward.  Eric, is there anything specific I can gather
> >> or do to help figure out why that is causing mock to get such a weird
> >> error?  I can provide the bisect log if you'd like.
> >
> > I took a look at what mock was doing and it was mostly very simple
> > stuff.  The two exceptions were that it was calling unshare, then doing
> > some file checks and I/O, and then calling fork to exec off some helper
> > things.  Up until the point it fails, the forks work and the children go
> > do whatever it is they were supposed to do.  I've CC'd Clark Williams
> > just in case people have questions on mock itself, but I'm not sure that
> > will be needed.
> 
> Our emails crossed paths.  You have just confirmed my suspicion about
> what was going wrong.
> 
> The practical question is why mock is calling unshare(CLONE_NEWPID)
> because it clearly seems not to understand how to unshare the pid
> namespace and use it that way.

I don't know either, and I've CC'd Clark on this thread now (again for
real this time).

> Except for forgeting to reenable irqs in the failure path of alloc_pid
> the behavior is exactly correct and is how the pid namespace is designed
> to behave in the case of unshare.

Well... ok.  Personally, I'm confused why mock was working before that
commit and now it doesn't.  Were we just buggy in the kernel prior to
that?

> > which is consistent with what mock is seeing.  If I comment out the call
> > to unshare, it seems to always work.  It seems to consistently fail with
> > ENOMEM after the first 3-5 forked children, but it varies within that
> > range.
> 
> If you add a waitpid or space out your forks you will see that it always
> fails after your first child in the pid namespace has exited.
> 
> We don't allow children in a pid namespace after fork has exited.

Hm.  Mock seems to make it a ways along as well though, and it isn't
doing rapid fire fork/exec.  I believe it's forking helpers and waiting
for them to return before continuing on.

josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/