On 08/20, Andy Lutomirski wrote: > > On Tue, Aug 20, 2013 at 12:05 PM, Oleg Nesterov <[email protected]> wrote: > > On 08/20, Andy Lutomirski wrote: > >> > >> On Tue, Aug 20, 2013 at 11:50 AM, Oleg Nesterov <[email protected]> wrote: > >> > > >> >> Currently (with or without your patch), vfork() followed by > >> >> unshare(CLONE_NEWUSER) or unshare(CLONE_NEWPID) will unshare the VM. > >> > > >> > Could you spell please? > >> > > >> > We never unshare the VM. CLONE_VM in sys_unshare() paths just means > >> > "fail unless ->mm is not shared". > >> > > >> > >> Argh. In that case this is probably buggy, > > > > I don't think so. Just we can't really unshare ->mm
this looks confusing, sorry. Afaics it is possible to implement unshare(CLONE_VM), but > or implement > > unshare(CLONE_THREAD). this is unlikely. but this doesn't matter, > We simply pretend it works if there is nothing > > to unshare. > > > >> sys_unshare will see CLONE_NEWPID or CLONE_NEWUSER and set > >> CLONE_THREAD. Then it will see CLONE_THREAD and set CLONE_VM. > > > > This matches copy_process() to some degree... but looks confusing, > > I agree. I only mean that copy_process() requires CLONE_VM if CLONE_THREAD. But, unlike unshare(), it fails if CLONE_VM is not set. > Huh? Doesn't this mean that unshare(CLONE_NEWPID); vfork() will work > with your patches, I hope, > but vfork(); unshare(CLONE_NEWPID) will fail? (I > admit I haven't tested it.) Do you mean that the child does unshare(CLONE_NEWPID) before exec? It should fail with or without this patch. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
