Allow 9ns clones of chans opened with O_PATH
authorBarret Rhoden <brho@cs.berkeley.edu>
Wed, 16 Sep 2015 16:19:54 +0000 (12:19 -0400)
committerBarret Rhoden <brho@cs.berkeley.edu>
Mon, 28 Sep 2015 19:14:00 +0000 (15:14 -0400)
commit2638db141cc42e132c0a74da7918eb1405978e75
treec2b78cd52fa8b4b6249be06da84a97ba80e32268
parentb083c4378dc883c6194bccc76a0181a6d1afc1da
Allow 9ns clones of chans opened with O_PATH

I've heard it's a bad idea to allow clones of opened chans.  I'd like to
do it for O_PATH (no I/O allowed) chans.

I don't know the reasons for not allowing the clone.  One thing is that
it appears that devices up their refcnts or otherwise keep objects
around based on an open - which stands to reason: even after you unlink,
open objects stay around.  When we devclone, we might be messing up
something where the device does not know about the cloned chan.
However, the new chan is not COPEN, so it's like one of what I call the
"kernel internal" chans.

This relates to the decision to have O_PATH actually call a device's
open.  The choices seem to be:

1) Don't call open.  The user has an FD that points to a chan that may
or may not point to an actual object (not super comfortable with that,
but it might be fine.  This is my original SYS_walk).  Devclone doesn't
allow any opened chans to be cloned (and therefore walked from), and no
O_PATHs are actually opened.  You can only openat() from one of these
O_PATHs.  FD taps (e.g. ipfdtap) will need to grab references to keep
the conversation alive (and there may be races/issues of tapping old
conversations).

2) Call open.  The user will only ever have FDs that point to opened,
possibly-refcnted objects (this might be unnecessary).  The device is
involved in an O_PATH open.  openat() can be called on any FD (we may
allow from non-dirs).  The downside is that we're cloning an open chan,
which may have bad side effects.

For now, I'll go with option 2.
kern/src/ns/dev.c