Allow Qlistens to be partially opened with O_PATH
authorBarret Rhoden <brho@cs.berkeley.edu>
Fri, 11 Sep 2015 16:01:16 +0000 (12:01 -0400)
committerBarret Rhoden <brho@cs.berkeley.edu>
Mon, 28 Sep 2015 19:14:00 +0000 (15:14 -0400)
commit5a590d0cc053b6f2aa5b92f419a6124e06e9c720
treeb87d8d1b075b1e7cc9095e9f6962c3a178a930eb
parenta85ac2bf79d1ec86f1f55aa5486bf13071330864
Allow Qlistens to be partially opened with O_PATH

This gives us an FD that actually points to Qlisten.  Otherwise, when
you do a full open of Qlisten, you get a chan that points to a new
conversation that you listened for.  With this FD, we'll be able to tap
Qlisten to find out about new conversations (epoll).

There's a few things I don't understand about how #I interacts with 9ns
and what the rules are.  For instance, you can namec to get a chan that
points to an object.  Now your chan has a QID and a device, uniquely
identifying the object.  Once you have that, are you supposed to have a
reference to the object that does not disappear until the chan is
released?  That would make sense.  Note that 9ns will call the device's
close() method on the chan, including chans that were not actually
opened.  #I deals with this by checking c->flags for COPEN so that it
only calls closeconv on chans that called ipopen().

That's also not what seems to happen with #I; there's no permanence
between gen and open.  ipgen will create conversation directories up to
"ac", which is the number of active conversations.  That seems to be the
only check in ipgen, and there's nothing that keeps those conversations
alive.  That's probably why we have a high water mark of conversations
in #I: once created, they are around forever.  Their status might just
change.

I think it is possible to namec/ipgen a chan for something like ctl,
data, or now listen and get the "wrong" conversation.  Say we gen a chan
for "data" for a conversation, but do not open it.  Then that
conversation closes (or it can even be closed already), and then a new
thread opens "clone" and gets a new conversation that has the same QID
as the genned chan.  (Here, Fsprotoclone checks inuse, but inuse is 0
still).  Then the genned chan is opened, and we now have an FD pointing
to a chan that is pointing to a conversation that wasn't the
conversation we originally asked for.

One way to think about this is "you asked for tcp/1/data, that's what
you get.  There's no guarantee that that conversation is the one you
actually want."

Anyway, you can now do that same thing with "listen".

Oh, and be careful if you try to hang refcnted blobs off c->aux.  I
tried that a while ago with #s and it was a nightmare.  Maybe it can
work, but again, the rules for how everything works are not clear.
kern/src/net/devip.c