On Fri, Feb 08, 2013 at 12:13:09PM -0800, Eric W. Biederman wrote: > Josh Boyer <jwbo...@redhat.com> 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. Seems to be failing on forking a umount command > >> after init'ing the chroot. I can put the full output somewhere if > >> people are interested. > > > > OK. I've bisected this down to: > > > > 50804fe3737ca6a5942fdc2057a18a8141d00141 is the first bad commit > > commit 50804fe3737ca6a5942fdc2057a18a8141d00141 > > Author: Eric W. Biederman <ebied...@xmission.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.
< Two emails fly past each other in the night > > 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 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 exited in > the pid namespace). -ENOMEM will be generated because of a failure of > alloc_pid. > > Looking at that code path a little closer that just about has to be it, > because I goofed and the error path drops the lock but not irqs. The > patch below should fix the nasty warning and confirm where the code is > failing in copy_process. OK. I'll turn the debug option back on and give this patch a try. > An strace to see which syscalls mock is making and with which flags > would be very interesting. I am almost certain that there is a > unshare(CLONE_NEWPID) somewhere in there. But in a remote corner of > possibility it could weird clone flags, or something else. Oh, I have that but it's a python app with a helper C app and it's a... verbose strace. It's here for one failure: http://jwboyer.fedorapeople.org/pub/mock-strace Hopefully the testcase from my other email will help though. It's much simpler. > Beyond that I suspect we want to work with the mock folks so they get > their code to use a pid namespace working the way they intended. Right. CC'd Clark (for real this time). I'll let you know on the patch. josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
