Race conditions

[John Baldwin]

On Saturday, August 29, 2015 01:30:49 PM Konstantin Belousov wrote:
> On Fri, Aug 28, 2015 at 01:34:58PM -0700, John Baldwin wrote:
> > Perhaps we could force cloning to serialize with opens? That is, use
> > some sort of global lock in devfs such that any non-cloning opens use
> > a shared lock but an exclusive lock is taken before running clone
> > event handlers (and held until after d_open returns)? To really
> > close this sort of race, the exclusive lock acquired when a clone
> > is created in lookup() would have to be held until devfs_open() is
> > called. That's rather gross. I suppose you could always aquire the
> > lock in devfs_lookup() when ISOPEN is set (exclusive if you have to
> > clone, otherwise shared) and then drop it in devfs_open() after d_open
> > returns.
> Hm, I do not think taking a lock in lookup(ISOPEN) is feasible. VFS migh
> not call VOP_OPEN() after the lookup, for misc. reasons (e.g. due to the
> permissions, or forced umount reclaiming vnode as two obvious cases).
> 
> Also, I am not sure about the definition about non-cloning open. Other
> thread might race with the cloner and open the newly cloned node
> before the cloner has a chance to proceed. Do you want to prevent this
> situation ? If yes, then why ? si_drv1 issue should be handled by other
> means.

This isn't about si_drv1, this is about my other change of trying to let
an open of /dev/tap reliably open a "free" tap device.  The race my current
change there doesn't handle is that if an open of /dev/tap that returns
a "free" tap device from the clone handler might race with another process
that opens a tap device by name (e.g. /dev/tap0).

An entirely different possibility is to change /dev/tap to not use cloning
at all and instead use cdevpriv.  It could then safely choose a "free"
tap device during its open routine.  This might be a bit of an API change
though as devname/fdevname could no longer be used to determine the name
of the interface opened by an open of /dev/tap.

> > Well, we've had this race in most cdev drivers in the tree for a long
> > time. It's a narrow one that doesn't get hit often (if at all) in
> > practice, but if I were to do a sweep to patch all the open routines
> > to handle it, I'd rather we do it this way instead. OTOH, I don't have
> > a burning desire to patch all the open routines.
> 
> For the race to be real, the device must be created after the userspace
> is running. I think that the main case there are pty.

Or kldload of a device driver.

> I do not see a possibility of removing existing make_dev*() after the
> make_dev_uber() is introduced, so there is no need for the whole tree
> sweep.

I mean more that if one wanted to fix the si_drv1 race one would have to
do some sort of sweep of affected drivers.

-- 
John Baldwin