linux-kernel - Re: Re: BUG in: Driver core: convert block from raw kobjects to core devices (fwd)

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: <1194464182.2303.44.camel@lov.site>
Date:	Wed, 07 Nov 2007 20:36:22 +0100
From:	Kay Sievers <kay.sievers@...y.org>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Hannes Reinecke <hare@...e.de>, Greg KH <greg@...ah.com>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: Re: BUG in: Driver core: convert block from raw kobjects to
	core devices (fwd)

On Wed, 2007-11-07 at 10:54 -0500, Alan Stern wrote:
> On Wed, 7 Nov 2007, Hannes Reinecke wrote:
> 
> > Alan Stern wrote:
> > > 
> > > Thus we have a cycle:
> > > 
> > > 	1&2: request_queue isn't released before scsi_device;
> > > 
> > > 	3: scsi_device isn't released before gendisk;
> > > 
> > > 	4: gendisk isn't released before request_queue.
> > > 
> > > The dependency in 1&2 is hard-coded into the SCSI core.  If I 
> > > understand correctly, the core really does need the request_queue to 
> > > hang around as long as the scsi_device is still present.  According to 
> > > James Bottomley, any block device driver should be expected to have a 
> > > similar requirement.
> > > 
> > This is actually true, but as other block device drivers create the
> > LUN (or the equivalent thereof), the request queue, and the block device
> > at the same time or under control of the driver itself they don't have
> > this problem.
> > It's only due to the decoupling of the block driver from the underlying
> > device (ie sd driver and scsi_device) when this problem arises.
> 
> I don't understand your reasoning.  If the same parent-child
> relationships exist then it doesn't matter who creates the data
> stuctures.  All that matters is that the block device's reference to
> the request_queue isn't dropped until the device is released.
> 
> > > But the dependencies in 3 and 4 are unnecessary.  They are artifacts,
> > > caused by the fact that a kobject doesn't drop its reference to its
> > > parent until it is released.  If instead the reference to the parent
> > > were dropped when the kobject was removed then 3 and 4 wouldn't apply.
> > > 
> > And should be okay as the device isn't accessible from userland
> > anyway after doing a device_del(). And the implication is that it's
> > going to be remove soon entirely. So we're just moving the timing
> > of the eventual call to the ->release() function; the events will
> > be triggered by device_del() and won't be changed.
> > And if some device actually requires a reference to the parent
> > during ->release() it can as well acquire it manually and shouldn't
> > rely on the core logic to do that automatically.
> 
> My thinking exactly.

It would remove another implicit "magic" from the core, which is good.

Otherwise we will need to introduce a kobject_orphan(), to disassociate
an object from its parent, which would be kind of weird, just to break
out of the default core logic.

I would expect this patch to have an effect only at the pretty complex
refcounting users of the driver core, which are SCSI and USB, and I
expect the people involved are good prepared now, to fix such possible
bugs, should they show up. :)

Kay

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