Re: [PATCH RFD] alternative kobject release wait mechanism

[Tejun Heo <htejun@gmail.com>]

Tejun Heo wrote:
>> Incidentally, Tejun, I'm all in favor of a immediate-detach driver model 
>> approach.  Unfortunately it's impossible to realize fully, although we 
>> could come much closer than we are now.
>>
>> Here's an example where immediate-detach cannot be implemented.  A driver 
>> binds to a device and uses that device is a kernel thread.  The thread 
>> carries out certain operations which require it to hold the device 
>> semaphore (because, for example, they need to be mutually exclusive with 
>> unbind).
>>
>> The driver's remove() method is called with the semaphore held.  If the
>> thread tries to lock the semaphore at the same time and blocks, there is
>> no way at all for the remove() method to force the thread to drop its
>> reference.
>>
>> This isn't merely a theoretical example.  The USB hub driver works in
>> exactly this way.
> 
> Dunno if I understood the problem right but can't we do the following?
> 
> remove()
> {
> 	acquire sem;
> 	device_del();
> 	release sem;
> 	device_put_wait();
> }

More afterthoughts.  If a mutex is used to protect access against
removal.  There is no reason to hold reference to it.

kernel_thread()
{
	/* wanna dereference my_obj */
	mutex_lock();
	verify my_obj is there and use it if so.
	mutex_unlock();
}

remove()
{
	mutex_lock();
	kill_it();
	mutex_unlock();
}

I probably have over simplified it but using both mutex and reference
counts doesn't make much sense.  IOW, you get an active reference when
you grab the mutex excluding its removal and verified it's still there.

There probably are other reasons why things are done that way and we can
 and probably will have to resort to mixed solutions in foreseeable
future but I don't think there is any inherent problem in applying
immediate-disconnect in the described situation.

Feel free to scream at me if I'm getting it totally wrong.  :-)

Thanks.

-- 
tejun