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]

Message-ID: <46263D0E.2000702@gmail.com>
Date:	Thu, 19 Apr 2007 00:45:18 +0900
From:	Tejun Heo <htejun@...il.com>
To:	Alan Stern <stern@...land.harvard.edu>
CC:	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>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>
Subject: Re: [PATCH RFD] alternative kobject release wait mechanism

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
-
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/