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:	Wed, 25 Apr 2007 11:00:05 +0200
From:	Cornelia Huck <cornelia.huck@...ibm.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Greg KH <greg@...ah.com>, Tejun Heo <htejun@...il.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>
Subject: Re: [PATCH RFD] alternative kobject release wait mechanism

On Tue, 24 Apr 2007 15:38:12 -0400 (EDT),
Alan Stern <stern@...land.harvard.edu> wrote:

> We ought to make it explicitly clear that _all_ subsystems should behave
> this way.  Maybe it isn't necessary to go as far as having device_del()
> call itself recursively; doing that would open up lots of possible races.  
> But I think it would be a good idea to add a WARN_ON in device_del, right
> after the call to bus_remove_device(), that would be triggered if the
> device still had any children.

If we decide that this should be policy, WARN_ON may be the least
invasive option.

Should it be a possible option to move children to a different parent,
so that the requirement wouldn't be "unregister all children", but "no
children remain after remove() returns"?

> It would also be good to document (but where?) some lifetime rules for 
> device drivers.

Documentation/driver-model/lifetime-rules.txt?

> Something like this:
> 
> 	When a driver's remove() method returns, the driver must no
> 	longer try to use the device it was just unbound from.  The
> 	device may be physically gone, or a different driver may be
> 	bound to it.  Most importantly, remove() should unregister
> 	all child devices created by the driver.

s/should/must/, if we agree on the policy above.

The remove() method must also unset driver_data.

> 	To accomplish all this safely, the driver should allocate a
> 	private data structure containing at least a "gone" flag and 
> 	a mutex or spinlock for synchronization.  Each time the driver
> 	needs to use the device, it should first lock the mutex or 
> 	spinlock and check the "gone" flag.

How should a driver make the device -> private data transition if it
may no longer have private data attached to the device?

> 	Ideally remove() should release all of the driver's references
> 	to the device, in accord with the "Immediate Detach" principle.
> 	However it is acceptable for the driver to retain a reference,
> 	provided it meets the following conditions:
> 
> 		The reference must be dropped in a timely manner,
> 		such as when the release() methods for all child
> 		devices have run.
> 
> 		The driver must also retain a module reference to
> 		the owner of the device.  In practice this means the
> 		driver must contain static code references to the
> 		subsystem which created the device, since struct
> 		device doesn't have an "owner" field.

Uhm. This would imply that a driver may never create a device itself.
However, the kobject->owner and module refcounting stuff should remove
this restriction.

> 		The driver must restrict itself to reading (not
> 		writing!) the fields in the device structure.  The
> 		only exception is that the driver may lock/unlock
> 		dev->sem.

And it may decrease the reference count, of course :)

> How does that sound?

Yes, we should have some documentation like that.
-
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/