On Fri, 20 Apr 2007, Dmitry Torokhov wrote:
> On 4/19/07, Alan Stern <[email protected]> wrote:
> >
> > Among the worst offenders are character devices. None of the subsystem
> > providers offering char device registration performs immediate detach --
> > they are a lot like sysfs used to be. (In fact, they probably _can't_
> > provide it since read() or write() calls can block indefinitely in the
> > lower-level driver; the subsystem may have no way to force them to
> > fail-fast.)
>
>
> That shoudl be doable - the read/write routines should check if device
> is still alive and return immideately when device is dead. When
> disconnecting device just wake up all readers and writers and they
> should eventually fall off.
Read and write don't matter so much; they can be handled easily enough in
the driver. The real problem is the race between open() and unregister().
We rely on the low-level drivers to make them mutually exclusive, but it
really should be done by the subsystem. More precisely, the subsystem
should guarantee that all outstanding calls to open() have completed
before unregister() returns.
> Hmm, I guess am starting to think that using refcounting everywhere is
> not a good idea. We are trying to have "immediate disconnect" behavior
> and refcounting is an antithesis of it. Refcounting works well when it
> is contained - register grabs reference; unregister puts it back; but
> there is no passing references down between the layers. When device is
> being removed it needs to signal downstream that it is gone and should
> not be accessed anymore. And we need to do that anyway because if
> device is really gone but its users ignore it they will get endless
> stream of errors when trying to access it.
"Should not be accessed" is correct, but there's nothing wrong in
principle with acquiring a lock in the device structure, provided the
driver does nothing else. And provided that the driver pins the subsystem
module, so the device's release() routine will be called _before_ the
subsystem can be unloaded.
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
