linux-kernel - Re: [RFD driver-core] Lifetime problems of the current driver model

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]

Date:	Fri, 30 Mar 2007 09:15:50 -0400
From:	"Dmitry Torokhov" <dmitry.torokhov@...il.com>
To:	"James Bottomley" <James.Bottomley@...eleye.com>
Cc:	"Tejun Heo" <htejun@...il.com>, gregkh@...e.de, hugh@...itas.com,
	cornelia.huck@...ibm.com, oneukum@...e.de, maneesh@...ibm.com,
	rpurdie@...ys.net, "Jeff Garzik" <jgarzik@...ox.com>,
	lkml <linux-kernel@...r.kernel.org>,
	"linux-ide@...r.kernel.org" <linux-ide@...r.kernel.org>,
	"SCSI Mailing List" <linux-scsi@...r.kernel.org>
Subject: Re: [RFD driver-core] Lifetime problems of the current driver model

Hi James,

On 3/30/07, James Bottomley <James.Bottomley@...eleye.com> wrote:
> On Fri, 2007-03-30 at 18:43 +0900, Tejun Heo wrote:
> > Orphaning sysfs nodes on unregistration is a big step in this
> > direction.  With sysfs reference counting out of the picture,
> > implementing 'disconnect immediate' interface only on a few components
> > (including request_queue) should suffice for most block device
> > drivers.  I'm not familiar with other drivers but I don't think
> > they'll be very different.
>
> I agree with this statement.  The big question in my mind is how do we
> do it?
>
> The essential problem, and the reason why the lifetime rules are
> entangled is that fundamentally, sysfs entries are managed by kobjects.
> The things the device drivers are interested in is struct device, which
> is usually embedded in driver data structures.  Unfortunately, the
> required kobject is usually embedded in struct device meaning that the
> relevant driver structure cannot be freed while the sysfs entry still
> exists.
>
> It seems to me that the only way to Orphan the sysfs entries is to
> separate the kobject and the struct device so their lifetime rules are
> no longer entangled.  Then we can free the driver structure with the
> embedded struct device while still keeping the necessary kobject around
> to perform orphaned sysfs operations.
>
> So it seems to me that what we need to do is to give struct device its
> own kref and a pointer to a kobject.  Then we can manage the separate
> lifetimes independently.  The device would basically allocate and take a
> reference to the kobject on device_add() and relinquish it again (and
> null out the kobject pointer) on device_del().  The complexity here is
> that we now have to allocate the kobject somewhere else ... probably in
> device_add() (it doesn't come for free with the device structures).
>

If you want to manage lifetime rules independently you might want to
not embed struct device into you subsystems objects but attach them
via pointers and use device_create(). Now that we orphan sysfs access
upon unregistering device this will severe all ties from driver core
to your system once you start teardown of a device and you should be
in clear.

However there are simpler subsystems (input, serio, etc.) where there
is only one core module which provides services to device drivers and
handles registration and deregistration. For such substustems it makes
sense to embed struct devices and manage lifetime for all components
at once.

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