From: Jens Axboe <axboe@suse.de>
To: Tejun Heo <htejun@gmail.com>
Cc: Arjan van de Ven <arjan@infradead.org>,
Chris Rankin <rankincj@yahoo.com>,
linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [OOPS] 2.6.11 - NMI lockup with CFQ scheduler
Date: Wed, 6 Apr 2005 20:01:33 +0200 [thread overview]
Message-ID: <20050406180132.GD15165@suse.de> (raw)
In-Reply-To: <4253E673.2000001@gmail.com>
On Wed, Apr 06 2005, Tejun Heo wrote:
> Jens Axboe wrote:
> >On Wed, Apr 06 2005, Arjan van de Ven wrote:
> >
> >>>@@ -324,6 +334,7 @@
> >>> issue_flush_fn *issue_flush_fn;
> >>> prepare_flush_fn *prepare_flush_fn;
> >>> end_flush_fn *end_flush_fn;
> >>>+ release_queue_data_fn *release_queue_data_fn;
> >>>
> >>> /*
> >>> * Auto-unplugging state
> >>
> >>where does this function method actually get called?
> >
> >
> >I missed the hunk in ll_rw_blk.c, rmk pointed the same thing out not 5
> >minutes ago :-)
> >
> >The patch would not work anyways, as scsi_sysfs.c clears queuedata
> >unconditionally. This is a better work-around, it just makes the queue
> >hold a reference to the device as well only killing it when the queue is
> >torn down.
> >
> >Still not super happy with it, but I don't see how to solve the circular
> >dependency problem otherwise.
> >
>
> Hello, Jens.
>
> I've been thinking about it for a while. The problem is that we're
> reference counting two different objects to track lifetime of one
> entity. This happens in both SCSI upper and mid layers. In the upper
> layer, genhd and scsi_disk (or scsi_cd, ...) are ref'ed separately while
> they share their destiny together (not really different entity) and in
> the middle layer scsi_device and request_queue does the same thing.
> Circular dependency is occuring because we separate one entity into two
> and reference counting them separately. Two are actually one and
> necessarily want each other. (until death aparts. Wow, serious. :-)
That's precisely correct.
> IMHO, what we need to do is consolidate ref counting such that in each
> layer only one object is reference counted, and the other object is
> freed when the ref counted object is released. The object of choice
> would be genhd in upper layer and request_queue in mid layer. All
> ref-counting should be updated to only ref those objects. We'll need to
> add a release callback to genhd and make request_queue properly
> reference counted.
>
> Conceptually, scsi_disk extends genhd and scsi_device extends
> request_queue. So, to go one step further, as what UL represents is
> genhd (disk device) and ML request_queue (request-based device),
> embedding scsi_disk into genhd and scsi_device into request_queue will
> make the architecture clearer. To do this, we'll need something like
> alloc_disk_with_udata(int minors, size_t udata_len) and the equivalent
> for request_queue.
>
> I've done this half-way and then doing it without fixing the SCSI
> model seemed silly so got into working on the state model. (BTW, the
> state model is almost done, I'm about to run tests.)
>
> What do you think? Jens?
It is of course the optimal solution to really solve the hierarchy of
references, but more involved. If you have time / desire to do it, I'd
be happy to review it :-)
For now I'm happy with the work-around. It's not too ugly, and at least
it makes it possible to kill the worse work-around of
scsi_kill_requests().
--
Jens Axboe
next prev parent reply other threads:[~2005-04-06 18:02 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-29 12:22 [OOPS] 2.6.11 - NMI lockup with CFQ scheduler Chris Rankin
2005-03-29 12:26 ` Jens Axboe
2005-04-06 12:31 ` Jens Axboe
2005-04-06 12:52 ` Arjan van de Ven
2005-04-06 12:55 ` Jens Axboe
2005-04-06 13:38 ` Tejun Heo
2005-04-06 18:01 ` Jens Axboe [this message]
2005-04-06 20:32 ` Mike Anderson
-- strict thread matches above, loose matches on Subject: below --
2005-03-29 11:54 Chris Rankin
2005-03-29 12:03 ` Jens Axboe
2005-04-06 16:27 ` James Bottomley
2005-04-06 17:58 ` Jens Axboe
2005-04-06 18:20 ` James Bottomley
2005-04-06 19:08 ` Jens Axboe
2005-04-06 21:09 ` James Bottomley
2005-04-07 6:49 ` Jens Axboe
2005-04-07 13:18 ` James Bottomley
2005-04-07 13:22 ` Christoph Hellwig
2005-04-07 13:24 ` Jens Axboe
2005-04-07 13:30 ` James Bottomley
2005-04-07 13:32 ` Jens Axboe
2005-04-07 13:39 ` James Bottomley
2005-04-07 14:45 ` Jens Axboe
2005-04-08 13:04 ` James Bottomley
2005-04-08 13:09 ` Jens Axboe
2005-04-07 13:24 ` Jens Axboe
2005-03-27 19:22 Chris Rankin
2005-03-29 11:32 ` Jens Axboe
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=20050406180132.GD15165@suse.de \
--to=axboe@suse.de \
--cc=arjan@infradead.org \
--cc=htejun@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=rankincj@yahoo.com \
/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