On Thu, 2 Mar 2006, Michael Kerrisk wrote:
> > >>>>>
> > >>>>> That is, CLONE_FS, CLONE_FILES, and CLONE_VM *reverse* the
> > >>>>> effects of the clone() flags of the same name, but CLONE_NEWNS
> > >>>>> *has the same meaning* as the clone() flag of the same name.
Well, if this is the only problem, who cares? CLONE_NEWNS itself is
actually a reversal of clone flags: unlike the others, that tell to
_share_ things that normally aren't shared across a fork(), CLONE_NEWNS
does the opposite: it asks to unshare something that normally is shared.
So the fact that it then acts not as a reversal when doing "unshare()" is
actually consistent with the fact that it's a already a "unshare" event
for clone() itself.
> Do you have any further response on this point?
> (There was none in your last message?)
I personally don't think it's worth makign UNSHARE_NEWNS just because it's
a flag that acts differently from the other CLONE_xxx flags.
As to whether allow or not allow unknown unshare() flags, I don't think
it's a huge deal either way. Right now we don't check the flags to
"clone()" either, I think.
Linus
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
