Re: PATCH: (as177) Add class_device_unregister_wait() andplatform_device_unregister_wait() to the driver model core

[Linus Torvalds]

On Fri, 23 Jan 2004, Alan Stern wrote:
> > 
> > So why would this not deadlock?
> 
> Kind of a general question, so I'll give a general answer.  This wouldn't
> deadlock for the same reason as anything else: People use it properly!

No.

> > The reason we don't wait on things like this is that it's basically
> > impossible not to deadlock.
> 
> That's an exaggeration.

Not by much.

>		  There are places where it's _necessary_ to
> wait.  For example, consider this extract from a recent patch written by
> Greg KH:
> 
> +	/* FIXME change this when the driver core gets the
> +	 * class_device_unregister_wait() call */
> +	init_completion(&bus->released);
>  	class_device_unregister(&bus->class_dev);
> +	wait_for_completion(&bus->released);
> 
> For the full patch, see 
> http://marc.theaimsgroup.com/?l=linux-usb-devel&m=107109069106188&w=2
> 
> The general context is that a module is trying to unload, but it can't
> until the release() callback for its device has finished.

And in just about any circumstance, with the _possible_ exception of 
module unload, things like this can be fooled into deadlocking by a 
non-root user.

To the point where root can no longer fix things up.

We've had these bugs before. It's a mistake to make interfaces that 
positively _encourage_ bugs like this.

The canonical example of a bug like this is when a regular user can 
trigger an event that causes the wait, and then makes sure that it holds a 
reference count on the event - by opening a file descriptor. 

> And sometimes a part of the kernel has to wait until the reference count
> drops to 0.

Not likely. The rest of the kernel never does it.

What is it with USB that makes people think so? Remember all the USB bugs 
early on that were due to _exactly_ that thinking. 

It's wrong. YOU SHOULD NEVER WAIT FOR THE REFERNCE COUNT TO DROP TO ZERO!

You just ignore it. With proper memory management it doesn't matter.

For module unload, it's likely better to return an error than to wait. 
Tell the super-user that you're busy.

> By the way, adding class_device_unregister_wait() has an excellent
> precedent.  The driver model core _already_ includes
> device_unregister_wait(), merged by Pat Mochel.  Are you saying that
> function shouldn't exist either?

Quite probably.

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/