Race conditions

[John Baldwin]

On Thursday, September 03, 2015 12:47:27 PM Konstantin Belousov wrote:
> On Wed, Sep 02, 2015 at 10:59:12AM -0700, John Baldwin wrote:
> > If we allow a cdevsw to override how devname works, then that would probably
> > be sufficient on its own.  I don't think you would need to change the
> > /dev/tapX devices at all.  The cdevpriv for /dev/tap desciptors would have a
> > reference to the /dev/tapX device it is using and return that device's name
> > in the devname override.
> You mean, the consumers of tap use fdevname(3), not devname(3) ?  Since
> for devname(), there is no access to cdevpriv.

Correct, if you open /dev/tap to get a free tap device, you want to find out
which interface you actually opened, so fdevname() on the descriptor would
work.  If you used fstat() to extract a dev_t to pass to devname() I guess
that would still just return '/dev/tap'.

> > Another option that I had started to play with previously is to let devices
> > auto-created by /dev/tap set an internal 'destroy-on-close' flag.  That
> > seems a bit more heavyweight, but it might also be simpler to implement?
> 
> Could you, please, clarify, how this would help to handle the race at
> open ?

Hmm, I guess it wouldn't really help.  There's just no way to reliably
interlock between the clone handler and the open routine.  Even with "simple"
cloning I think you will always have a race in that the clone handler might
create a new device to use but then fail the open.  I think that from an
API perspective, opening a "clone" device should never fail.

Hmm, looking at /dev/ptmx, it handles this by not doing a clone on open,
but instead using a d_fdopen routine and explicitly setting up the new
file descriptor as if it had opened the equivalent named device.  Perhaps
that is what I should do instead in my tap change.  If I go that route,
then I think that fdevname/devname would already DTRT without needing a
new cdevsw method.

-- 
John Baldwin