cdev destroy_dev() and detach races

[Daniel Roethlisberger]

Kostik Belousov <kostikbel at gmail.com> 2007-07-03:
> On Mon, Jul 02, 2007 at 06:20:58PM +0200, Daniel Roethlisberger wrote:
> > Kostik Belousov <kostikbel at gmail.com> 2007-07-02:
> > > On Mon, Jul 02, 2007 at 02:01:31PM +0200, Daniel Roethlisberger wrote:
> > > > I have been doing some finishing work on my cmx driver [1] and have run
> > > > into some difficulties involving detach races.  This is a pccard driver
> > > > with a cdev interface, the device is a PCMCIA based smartcard reader.
> > > > 
> > > > Originally, I thought destroy_dev() would block until all threads have
> > > > left the cdevsw handlers.  Then I found out that it would only do so if
> > > > d_purge is set in cdevsw.  However, there aren't an awful lot of drivers
> > > > using this.  My attempts to use a d_purge handler resulted in crashes
> > > > within kern/kern_conf.c when having an endless cat loop running while
> > > > detaching the device.
> > > Do you referring to RELENG_6 or CURRENT ? In CURRENT, destroy_devl() does
> > > sleep until there is any thread that grabbed thread reference. Look at the
> > > rev. 1.199 of kern_conf.c. On the other hand, this was never MFCed, and
> > > cause some other troubles that are being worked on.
> > 
> > RELENG_6, sorry for not mentioning.
> > 
> > > > The solution I am using now is that I sleep in detach() until
> > > > cdev->si_threadcount is 0.  This seems to have done the trick, but I
> > > > still have to do more testing to be sure.
> > > This looks like a workaround.
> > 
> > Why don't all the other drivers in RELENG_6 need some kind of workaround
> > to detach reliably?  Did I just look at the wrong drivers?
> The problem you described is a bug in RELENG_6. The fix changes devfs
> infrastructure instead of modyfing all the drivers.

Hum, that's not what I meant, sorry for not being clear.  I understand
the implications of the fix.  But since the fix was not MFCed, why
aren't there drivers in RELENG_6 crashing on this issue?  Why don't I
see more workarounds like mine in RELENG_6 drivers?  That's what I
wondered.

Since my driver now works flawlessly, it doesn't really matter.

> One of the reason why the fix (rev. 1.199 of kern_conf.c) it is not
> MFCed is some undesirable consequences, in particular, interaction
> with drivers calling destroy_dev() from cdev methods.

-Dan

-- 
Daniel Roethlisberger <daniel at roe.ch>