From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stanislav Kinsbursky Subject: Re: [RFC PATCH] fs: call_usermodehelper_root helper introduced Date: Thu, 23 May 2013 12:11:34 +0400 Message-ID: <519DCF36.80708@parallels.com> References: <20130522072840.27720.85023.stgit@localhost.localdomain> <878v36ex6n.fsf@xmission.com> <87wqqqdfqr.fsf@xmission.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: , , , , , , , , , , , To: "Eric W. Biederman" Return-path: In-Reply-To: <87wqqqdfqr.fsf@xmission.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 22.05.2013 22:35, Eric W. Biederman =EF=E8=F8=E5=F2: > ebiederm@xmission.com (Eric W. Biederman) writes: > >> I am missing a lot of context here and capturing the context of a >> process at time time we mount the filesystem and reconstituing it in >> call user mode helper seems like something we could do. > > If we want to do something like this the only sane thing I can see is= to > have a per container version of kthread call it uthread. That the us= er > mode helper code would use to launch a new process. > The main point here, is that a container can have it's own root, differ= ent to kthread's one (another mount or at least chroot result). > Anything else and I expect we will be tearing our hair out for the re= st > of our lives with weird corner cases or unexpected semantics. > > At first glace I would exepct uthread to be per pid namespace in > implementation. > Having a per-pidnamespace kernel thread would be really great. But regrettably doesn't solve the root swapping problem. > Eric > > --=20 Best regards, Stanislav Kinsbursky