Andrew Morton writes:
> On Fri, 08 Feb 2013 12:13:09 -0800
> ebied...@xmission.com (Eric W. Biederman) wrote:
>
>> If mock has called unshare(CLONE_NEWPID). And then forked a process and
>> that process exited, and then forked anothe process that second and all
>> subsequent fork calls will fail
On Fri, 08 Feb 2013 12:13:09 -0800
ebied...@xmission.com (Eric W. Biederman) wrote:
> If mock has called unshare(CLONE_NEWPID). And then forked a process and
> that process exited, and then forked anothe process that second and all
> subsequent fork calls will fail with -ENOMEM (because init has e
On Fri, 08 Feb 2013 14:40:13 -0800
ebied...@xmission.com (Eric W. Biederman) wrote:
> Clark Williams writes:
>
> > The more I look at that the more I think I should nuke CLONE_NEWPID in
> > mock. It came in with a commit that added NEWIPC, which I think is valid
> > for mock managing a chroot, b
On Fri, 08 Feb 2013 14:05:55 -0800
ebied...@xmission.com (Eric W. Biederman) wrote:
> Josh Boyer 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
> >
Clark Williams writes:
> The more I look at that the more I think I should nuke CLONE_NEWPID in
> mock. It came in with a commit that added NEWIPC, which I think is valid
> for mock managing a chroot, but we're not looking to do full-up
> containers at this point and it looks like containers is t
On Fri, Feb 08, 2013 at 12:13:09PM -0800, Eric W. Biederman wrote:
For posterity's sake
> From: "Eric W. Biederman"
> Date: Fri, 8 Feb 2013 12:05:54 -0800
> Subject: [PATCH] pid: unlock_irq when alloc_pid fails because init has
> exited.
>
> Signed-off-by: "Eric W. Biederman"
Tested-by: Josh
On Fri, 8 Feb 2013 16:27:26 -0500
Josh Boyer wrote:
> On Fri, Feb 08, 2013 at 12:45:47PM -0800, Eric W. Biederman wrote:
> > Josh Boyer writes:
> >
> > > < Two emails fly past each other in the night >
> >
> > Yep.
> >
> > >> My best guess in some dark corner of mock has untested code to unsh
Josh Boyer 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
On Fri, Feb 08, 2013 at 12:45:47PM -0800, Eric W. Biederman wrote:
> Josh Boyer writes:
>
> > < Two emails fly past each other in the night >
>
> Yep.
>
> >> My best guess in some dark corner of mock has untested code to unshare a
> >> pid namespace, and that corner started doing something now
Josh Boyer writes:
> < Two emails fly past each other in the night >
Yep.
>> My best guess in some dark corner of mock has untested code to unshare a
>> pid namespace, and that corner started doing something now that
>> unsharing of the pid namespace actually works.
>>
>> If mock has called un
On Fri, Feb 08, 2013 at 12:36:08PM -0800, Eric W. Biederman wrote:
> Josh Boyer writes:
> >> OK. I've bisected this down to:
> >>
> >> 50804fe3737ca6a5942fdc2057a18a8141d00141 is the first bad commit
> >> commit 50804fe3737ca6a5942fdc2057a18a8141d00141
> >> Author: Eric W. Biederman
> >> Date:
Josh Boyer writes:
> On Fri, Feb 08, 2013 at 01:19:49PM -0500, Josh Boyer wrote:
>> On Thu, Feb 07, 2013 at 07:35:01PM -0500, Josh Boyer wrote:
>> > On Thu, Feb 07, 2013 at 02:15:02PM -0800, Andrew Morton wrote:
>> > > On Thu, 7 Feb 2013 16:57:42 -0500
>> > > Josh Boyer wrote:
>> > >
>> > > > H
On Fri, Feb 08, 2013 at 12:13:09PM -0800, Eric W. Biederman wrote:
> Josh Boyer writes:
> >> Right, agreed. As I said, I think that is mostly a secondary issue.
> >> Hopefully it will be easy to fix once we figure out why we're getting
> >> the ENOMEM error.
> >>
> >> Python backtrace below. Se
On Fri, Feb 08, 2013 at 01:19:49PM -0500, Josh Boyer wrote:
> On Thu, Feb 07, 2013 at 07:35:01PM -0500, Josh Boyer wrote:
> > On Thu, Feb 07, 2013 at 02:15:02PM -0800, Andrew Morton wrote:
> > > On Thu, 7 Feb 2013 16:57:42 -0500
> > > Josh Boyer wrote:
> > >
> > > > Hi All,
> > > >
> > > > We've
Josh Boyer writes:
> On Thu, Feb 07, 2013 at 07:35:01PM -0500, Josh Boyer wrote:
>> On Thu, Feb 07, 2013 at 02:15:02PM -0800, Andrew Morton wrote:
>> > On Thu, 7 Feb 2013 16:57:42 -0500
>> > Josh Boyer wrote:
>> >
>> > > Hi All,
>> > >
>> > > We've hit a weird error in Fedora using the 3.8-rcX
On Thu, Feb 07, 2013 at 07:35:01PM -0500, Josh Boyer wrote:
> On Thu, Feb 07, 2013 at 02:15:02PM -0800, Andrew Morton wrote:
> > On Thu, 7 Feb 2013 16:57:42 -0500
> > Josh Boyer wrote:
> >
> > > Hi All,
> > >
> > > We've hit a weird error in Fedora using the 3.8-rcX kernels. It seems
> > > the
On Thu, Feb 07, 2013 at 02:15:02PM -0800, Andrew Morton wrote:
> On Thu, 7 Feb 2013 16:57:42 -0500
> Josh Boyer wrote:
>
> > Hi All,
> >
> > We've hit a weird error in Fedora using the 3.8-rcX kernels. It seems
> > the mock tool is getting back ENOMEM when doing very simple things that
> > norm
On Thu, 7 Feb 2013 16:57:42 -0500
Josh Boyer wrote:
> Hi All,
>
> We've hit a weird error in Fedora using the 3.8-rcX kernels. It seems
> the mock tool is getting back ENOMEM when doing very simple things that
> normally just work. The 3.7 kernels on the same userspace work just
> fine. It se
Hi All,
We've hit a weird error in Fedora using the 3.8-rcX kernels. It seems
the mock tool is getting back ENOMEM when doing very simple things that
normally just work. The 3.7 kernels on the same userspace work just
fine. It seems just running 'mock init -v' is enough to cause the
failure.
B
19 matches
Mail list logo
