Re: [PATCH] parport/ppdev: fix registration of sysctl entries

[Al Viro <viro@ZenIV.linux.org.uk>]

On Sun, Jul 06, 2008 at 01:11:48AM +0100, Al Viro wrote:
> On Sun, Jul 06, 2008 at 12:51:48AM +0100, Al Viro wrote:
> 
> > I don't believe that it's right.  Note that if you *do* race there, you
> > are fucked regardless of sysctls - ppdev.c::register_device() racing
> > with itself will do tons of fun things all by itself (starting with two
> > threads allocating different pdev and both setting pp->pdev).
> > 
> > IOW, *if* that's what we are hitting here, you've only papered over the
> > visible symptom.
> 
> BTW, with your patch you'll have 100% reproducible double registration if
> you do PPCLAIM/PPRELEASE/PPCLAIN on one file descriptor.

FWIW, here's what's going on in ppdev:
	a) we *are* allowed to create several pardevice over the same
port, one per each open().  Each is essentially a parport scheduling
entity.  So far, so good.
	b) creation is actually delayed until an ioclt (PPCLAIM).  That
appears to be a result of shitty API (another ioctl (PPEXCL) instead of
just using O_EXCL at open() time, as any normal driver would).  In any
case, it's badly racy - two tasks doing PPCLAIM on the same struct file
(e.g. one had opened it, then called fork(), then both child and parent
had called ioctl(fd, PPCLAIM, 0)) can race, leading to rather nasty
effects.  Check for delayed registration + register_device() call should
be atomic.  That's solvable by a mutex.
	c) *HOWEVER*, all races aside, we have a genuinely fscked up
API.  Each of these parport scheduling entities has a parameter - timeslice.
That parameter is exposed as sysctl.  And we definitely want these per-open,
not per-port.  And we get everything for the same port mapped to the same
sysctl.