public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@SteelEye.com>
To: Kay Sievers <kay.sievers@vrfy.org>
Cc: Alan Stern <stern@rowland.harvard.edu>, Greg KH <greg@kroah.com>,
	Hannes Reinecke <hare@suse.de>,
	SCSI development list <linux-scsi@vger.kernel.org>
Subject: Re: BUG in: Driver core: convert block from raw kobjects to core devices (fwd)
Date: Wed, 31 Oct 2007 11:31:10 -0500	[thread overview]
Message-ID: <1193848270.3411.39.camel@localhost.localdomain> (raw)
In-Reply-To: <1193847866.6621.5.camel@lov.site>

On Wed, 2007-10-31 at 17:24 +0100, Kay Sievers wrote:
> On Wed, 2007-10-31 at 11:13 -0500, James Bottomley wrote:
> > On Wed, 2007-10-31 at 12:04 -0400, Alan Stern wrote:
> > > On Wed, 31 Oct 2007, James Bottomley wrote:
> > > 
> > > > > Yes, the queue is a child of the disk.
> > > > 
> > > > Right, so this goes gendisk->queue (-> meaning parent of, or takes
> > > > reference to)
> > > 
> > > No, no!  The _child_ takes an implicit reference to the _parent_, not 
> > > the other way around.
> > > 
> > > > > > The scsi_device has a ref to the queue
> > > > > 
> > > > > Yeah, while the queue is a grandchild of the scsi_device with the
> > > > > unified sysfs layout.
> > > > 
> > > > No, the scsi_device is a direct parent of the queue, so we have
> > > > 
> > > > scsi_device->queue
> > > 
> > > Wrong -- the gendisk is the direct parent of the queue.  The relevant 
> > > line is in ll_rw_blk.c:blk_register_queue():
> > > 
> > > 	q->kobj.parent = kobject_get(&disk->dev.kobj);
> > > 
> > > > > Yes, sounds right. We need to break that deleted-but-wait-for-cleanup at
> > > > > least at one of the devices involved.
> > > > 
> > > > But it's broken when the driver is unbound.  Diagrammatically it's:
> > > > 
> > > > scsi_disk -> scsi_device -> queue
> > > >           -> gendisk     ->
> > > > 
> > > > It's not circular, it's released when scsi_disk is released.  It can
> > > > become circular if there's some hidden dependency between any of the
> > > > components ... but I don't think there is.
> > > 
> > > Forget about the scsi_disk.  It isn't part of the problem.  Just 
> > > concentrate on the scsi_device, the gendisk, and the queue.  We have:
> > > 
> > > 	scsi_device <- gendisk <- queue <- scsi_device,
> > 
> > OK, so where does the gendisk get a reference to the scsi device?
> 
> In the unified sysfs layout where the silly and conceptual broken idea
> of "class devices" gets removed.
> Everything that has a "device" link today will just live below the
> device the "device" link points to. The whole current kernel is already
> converted to do this, besides the "raw kobject" gendisk's, and the SCSI
> subsystem. The gendisk patch is queued in Greg's tree (see subject of
> this mail), and the conversion from "struct class_device" to "struct
> device" for the whole SCSI directory is coming soon.
> 
> With the gendisk pointing to "driverfs_dev" ("device" link) it will
> become a child of the scsi_device.

OK, light beginning to go on now.

The problem is that you've fallen into the conceptual trap we tried very
hard to avoid in the initial go around of joining SCSI upper layer
drivers to gendisks.  That's why no gendisk references are held by the
mid-layer, only by the entities that represent the objects created by
upper layer drivers.

Doesn't this circularity now exist for everything?  Every device that
creates a queue has a reference to the queue, every queue has a
reference to its attached gendisk and now every gendisk has a reference
to the device creating the queue?  This doesn't look to be a SCSI
specific problem.

James





  reply	other threads:[~2007-10-31 16:31 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-29 15:18 BUG in: Driver core: convert block from raw kobjects to core devices (fwd) Alan Stern
2007-10-29 15:35 ` James Bottomley
2007-10-29 16:38   ` Alan Stern
2007-10-29 16:45     ` James Bottomley
2007-10-29 17:04       ` Alan Stern
2007-10-29 18:47   ` Alan Stern
2007-10-29 19:13     ` Kay Sievers
2007-10-31  4:25       ` Greg KH
2007-10-31 10:46         ` Kay Sievers
2007-10-31 14:32           ` Greg KH
2007-10-31 15:15             ` James Bottomley
2007-10-31 15:40               ` Kay Sievers
2007-10-31 15:47                 ` James Bottomley
2007-10-31 16:04                   ` Alan Stern
2007-10-31 16:13                     ` James Bottomley
2007-10-31 16:24                       ` Kay Sievers
2007-10-31 16:31                         ` James Bottomley [this message]
2007-10-31 16:42                           ` Kay Sievers
2007-10-31 16:46                             ` James Bottomley
2007-10-31 17:32                               ` Kay Sievers
2007-10-31 18:36                               ` Alan Stern
2007-10-31 16:44                           ` Alan Stern
2007-10-31 17:07                             ` James Bottomley
2007-10-31 18:38                               ` Alan Stern
2007-10-31 15:58               ` Alan Stern
2007-10-31 16:11                 ` James Bottomley
2007-10-31  4:24     ` Greg KH
2007-10-31 15:51       ` Alan Stern

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1193848270.3411.39.camel@localhost.localdomain \
    --to=james.bottomley@steeleye.com \
    --cc=greg@kroah.com \
    --cc=hare@suse.de \
    --cc=kay.sievers@vrfy.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox