LKML Archive on
 help / color / Atom feed
From: "Michael Kerrisk" <>
To: Linus Torvalds <>
Subject: Re: unhare() interface design questions and man page
Date: Thu, 2 Mar 2006 05:48:44 +0100 (MET)
Message-ID: <> (raw)
In-Reply-To: <>


> 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.

I care about this from an (kernel-userland) *interface* point 
of view.  I see a small but steady stream of unnecessarily 
confusing interfaces going into the kernel-userland interface; 
the problem is that no-one (or not enough people) seem to really
care about this.

The key point is this: if it looks like a duck, I expect it
to behave like a duck.  When interfaces have the same name, 
then users expect the interfaces to provide the same 
behaviour.  Now with unshare() we have the situation that
a set of flags with the same name reverses the 
corresponding flags for clone().  From an interface design 
point of view that might almost be okay.  But one flag
breaks the pattern: CLONE_NEWNS, does the same thing in 
both clone() and unshare().

Inflicting this sort of messiness on userland is a recipe 
for programmer confusion, with bugs and security holes 
in userland programs as the possible result. If you agree
that that is a possible result, then why not avoid the
possibility?  It does not cost much to do so.

> > 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.

See my comments above.  (And in case it wasn't clear, I meant 
make a complete set of UNSHARE_* flags that mirror the 
corresponding CLONE_* 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.

No checking in clone() was probably a mistake (now difficult 
to rectify because it could break bad userland apps).
Is that past mistake a rationale for making the same
mistake in future interfaces?  Without checks such as I've 
described, the kernel is not providing ABI stability (i.e.,
if some bit that was meaningless in the past acquires a meaning
in later kernels, then (older) application behaviour arbitrarily
and unexpectedly changes.  Why does that possibility not matter?
Making the change I suggest would help userland programmers.
What is the cost of making it?  (i.e., is there some good reason
not to do it?)



Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7 

Want to help with man page maintenance?  
Grab the latest tarball at, 
read the HOWTOHELP file and grep the source 
files for 'FIXME'.

  reply index

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2006-02-13 22:10 ` Michael Kerrisk
2006-02-14 13:44   ` JANAK DESAI
2006-02-14 18:49     ` Michael Kerrisk
2006-02-14 20:47       ` JANAK DESAI
2006-02-16  5:50         ` Michael Kerrisk
2006-02-19 17:52           ` Janak Desai
2006-03-02  3:31             ` Michael Kerrisk
2006-03-02  4:03               ` Linus Torvalds
2006-03-02  4:48                 ` Michael Kerrisk [this message]
2006-03-02 21:40                 ` Michael Kerrisk

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LKML Archive on

Archives are clonable:
	git clone --mirror lkml/git/0.git
	git clone --mirror lkml/git/1.git
	git clone --mirror lkml/git/2.git
	git clone --mirror lkml/git/3.git
	git clone --mirror lkml/git/4.git
	git clone --mirror lkml/git/5.git
	git clone --mirror lkml/git/6.git
	git clone --mirror lkml/git/7.git
	git clone --mirror lkml/git/8.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ \
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone