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: <4625EB20.5000306@gmail.com>
Date:	Wed, 18 Apr 2007 18:55:44 +0900
From:	Tejun Heo <htejun@...il.com>
To:	Cornelia Huck <cornelia.huck@...ibm.com>
CC:	linux-kernel <linux-kernel@...r.kernel.org>,
	Alan Stern <stern@...land.harvard.edu>,
	Greg K-H <greg@...ah.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	dmitry.torokhov@...il.com
Subject: Re: [PATCH RFD] alternative kobject release wait mechanism

Cornelia Huck wrote:
> On Wed, 18 Apr 2007 17:46:09 +0900,
> Tejun Heo <htejun@...il.com> wrote:
> 
>> It's debatable but I think things will be safer this way.  If we wait by
>> default, we are forced to check that all references are dropped and will
>> have a stack dump indicating which object is causing problem when
>> something goes wrong, which is better than silent object leaking and/or
>> jumping to non-existent address way later.
> 
> I agree that oopsing is bad. However, lingering references are not
> always coding errors. What if it will just take long for a reference to
> be given up? You'd have a hanging device_unregister(), with no
> particular gain.

It's more like future plan than immediately applicable.  I think most 
high-level driver related interfaces can be converted as sysfs was 
converted such that they disconnect immediately from the device - 
resolving conflicts between higher layer using reference counts and 
device driver layer which expects immediate disconnect is responsibility 
of those interfaces - just as sysfs does it.

If you have lingering reference to struct device after driver is 
detached, you're already screwed.  If there's outstanding reference to 
it from the previous driver, how are you gonna load the next one? 
You're gonna have to wait somewhere for all the references to go away. 
Actually, your patch series is doing exactly this during module 
unloading.  Problem is that you'll need to do the same thing before 
attaching the next driver for the same device.

Immediate-disconnect from all higher interface for device drivers is my 
goal for driver model as I wrote in the RFD about lifetime rules.  I 
think it's doable and should result in easier model to get right, but I 
might be missing something big time, so please point out if you can spot 
holes or don't agree.

>> I personally think all driver interface should be made this way such
>> that completion of unregister function guarantees no further access to
>> the object or module.  IMHO, it's more intuitive and easier to force
>> correctness.
> 
> If we really did this, we should also provide a non-waiting alternative.

For transitional purpose, sure.  In the long term, I think it's better 
if we can do without it.

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/