linux-kernel - Re: [PATCH RFD] alternative kobject release wait mechanism

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 21 Apr 2007 11:30:36 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
cc:	Tejun Heo <htejun@...il.com>,
	Cornelia Huck <cornelia.huck@...ibm.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Greg K-H <greg@...ah.com>,
	Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: [PATCH RFD] alternative kobject release wait mechanism

On Fri, 20 Apr 2007, Dmitry Torokhov wrote:

> On 4/19/07, Alan Stern <stern@...land.harvard.edu> 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/