Re: Odd ENOMEM being returned in 3.8-rcX

From: Clark Williams
Date: Fri Feb 08 2013 - 17:41:20 EST


On Fri, 08 Feb 2013 14:05:55 -0800
ebiederm@xxxxxxxxxxxx (Eric W. Biederman) wrote:

> Josh Boyer <jwboyer@xxxxxxxxxx> writes:
>
> >> So it looks mock is taking a buggy untested code path and things are not
> >> working as it expected.
> >
> > Quite possibly, yes. I instrumented the kernel a bit and it is indeed
> > failing in the alloc_pid call.
> >
> > Clark, thoughts here?
>
> I will just add the solution is probably for mock to fork immediate
> after the unshare succeeds in creating a pid namespace. With the
> original process waiting for mock to exit and the child process
> doing everything that mock does now.
>
> That will allow mock to act as the init process in the pid namespace it
> just created.
>
> Eric
>

Well, mock is not really setup to act as an init (i.e. reap all the
child processes in the new namespace). Not really sure that's what I
want anyway, verses just nuking CLONE_NEWPID and running in the same
pidspace.

I added some debugging output in the code around the unshare() calls and
so far I can't seem to get unshare() to succeed when NEWPID is one of
the flags. I'll admit that I'm running a realtime kernel (3.6.11-rt28
with CONFIG_PID_NS=y) so I'll boot into the latest F18 and make sure of
this, but I'm leaning towards just removing NEWPID, since we weren't
using it right and I'm not convinced that we need it.

Clark

Attachment: signature.asc
Description: PGP signature