Messages in this thread | | | Date | Fri, 23 Jan 2004 19:45:46 +0000 | From | viro@parcelfa ... | Subject | Re: PATCH: (as177) Add class_device_unregister_wait() and platform_device_unregister_wait() to the driver model core |
| |
On Fri, Jan 23, 2004 at 10:11:06AM -0800, Greg KH wrote: > On Fri, Jan 23, 2004 at 09:42:09AM -0800, Linus Torvalds wrote: > > > > > > On Fri, 23 Jan 2004, Alan Stern wrote: > > > > > > Since I haven't seen any progress towards implementing the > > > class_device_unregister_wait() and platform_device_unregister_wait() > > > functions, here is my attempt. > > > > So why would this not deadlock? > > It will deadlock if the user does something braindead like: > rmmod foo < /sys/class/foo_class/foo1/file > > Now I know the network code can handle something like that, but they > have their own thread to handle issues like this... It's not sane to > make every driver subsystem do that...
Network code does *NOT* wait for references to kobject to disappear. ->release() for those buggers is not in a module and freeing can happen way after the rmmod. No threads involved.
What it does wait for is different - in effect, net_device has a special-cased rwsem in it, heavily optimised for down_read(). dev_hold() is an equivalent of down_read(). dev_put() - up_read(). And unregister_netdev() does an equivalent of down_write() after removing from all search structures.
That's what it is waiting for - it wants all readers (semaphore is unfair) to go away. It's not a refcounting issue at all - it's an exclusion around the net_device shutdown, freeing resources, etc.
There was an optimistic attempt to turn that animal into sysfs refcount. It didn't work - we had to add real refcounting there and make sysfs code do essentially an equivalent of down_try_read() before accessing the guts of net_device(). And we have ->release() for those buggers in core kernel. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |