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:01 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.