From: Jens Axboe <axboe@kernel.dk>
To: Jeff Moyer <jmoyer@redhat.com>
Cc: Tejun Heo <tj@kernel.org>, Mike Snitzer <snitzer@gmail.com>,
Jan Beulich <JBeulich@novell.com>,
"David S. Miller" <davem@davemloft.net>,
linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org
Subject: Re: [PATCH v2.6.38-rc5 2/2] block: blk-flush shouldn't call directly into q->request_fn() __blk_run_queue()
Date: Mon, 07 Mar 2011 20:41:10 +0100 [thread overview]
Message-ID: <4D7534D6.7020000@kernel.dk> (raw)
In-Reply-To: <x49mxl6sot4.fsf@segfault.boston.devel.redhat.com>
On 2011-03-07 20:39, Jeff Moyer wrote:
> Jens Axboe <axboe@kernel.dk> writes:
>
>> On 2011-03-07 20:33, Jeff Moyer wrote:
>>> Tejun Heo <tj@kernel.org> writes:
>>>
>>>> Hello, Jens.
>>>>
>>>> On Wed, Mar 02, 2011 at 08:46:46AM -0500, Jens Axboe wrote:
>>>>>> Right, thanks. Jens, after you apply the two fixes for 2.6.38, I can
>>>>>> create a merge branch for for-2.6.39/core which you can pull. Would
>>>>>> that work for you?
>>>>>
>>>>> Thanks, that would be great. I'm applying them now.
>>>>
>>>> Okay, please pull from the following branch to receive the merge
>>>> between linux-2.6-block:for-linus and :for-2.6.39/core.
>>>>
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc.git block-for-2.6.39-core
>>>>
>>>> HEAD is e83a46bbb1d4c03defd733a64b727632a40059ad but git.korg seems a
>>>> bit slow to sync, so if you don't see the commit there, please pull
>>>> from master.korg.
>>>>
>>>> ssh://master.kernel.org/pub/scm/linux/kernel/git/tj/misc.git block-for-2.6.39-core
>>>>
>>>> Thanks.
>>>
>>> I know I'm coming to the party late (and maybe wrong), but I've got some
>>> questions here.
>>>
>>> Tejun, you introduced a commit to the ide driver that made it block in
>>> its request function. As far as I know, that's not allowed. For scsi,
>>> at least, it has always allowed calling back into the request function
>>> from the completion handler, and I think this is actully the common case
>>> (not some corner case).
>>>
>>> So, why doesn't the ide driver see calls back into its request function
>>> from the completion handler? It's clear that it calls blk_end_request
>>> from ide_end_rq, which can definitely call __blk_run_queue. In other
>>> words, why is it that the flush requests are triggerring this problem
>>> while normal I/O isn't?
>>>
>>> I think the real issue may just be that the ide driver is blocking in
>>> its request function. What have I missed?
>>
>> So the only case where the request_fn is called and you cannot block, is
>> if you call it from your completion function. Any other invocation
>> should be from process context. As long as you remember to drop the
>> queue lock and re-enable interrupts, it should work. It's not great
>> style and I would not recommend it for a performance environment, but it
>> should work.
>
> So are you agreeing with me or disagreeing? ;-) It sounds to me like
> you're saying that the ide driver should be able to cope with being
> called from softirq context.
I'm just stating how it should work :-)
But yes, it sounds like IDE is violating this rule and that's why it was
broken. Even with that, having explicit control of the queue running
does make sense.
--
Jens Axboe
next prev parent reply other threads:[~2011-03-07 19:41 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-17 11:15 [PATCH v2.6.38-rc5 1/2] block: add @force_kblockd to __blk_run_queue() Tejun Heo
2011-02-17 11:16 ` [PATCH v2.6.38-rc5 2/2] block: blk-flush shouldn't call directly into q->request_fn() __blk_run_queue() Tejun Heo
2011-02-17 15:01 ` Mike Snitzer
2011-02-18 9:49 ` Tejun Heo
2011-03-02 13:46 ` Jens Axboe
2011-03-04 18:25 ` Tejun Heo
2011-03-07 8:41 ` Jens Axboe
2011-03-07 19:33 ` Jeff Moyer
2011-03-07 19:36 ` Jens Axboe
2011-03-07 19:39 ` Jeff Moyer
2011-03-07 19:41 ` Jens Axboe [this message]
2011-03-07 19:50 ` Jeff Moyer
2011-03-08 7:54 ` Tejun Heo
2011-03-02 12:53 ` [PATCH v2.6.38-rc5 1/2] block: add @force_kblockd to __blk_run_queue() Jan Beulich
2011-03-02 12:53 ` Jan Beulich
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=4D7534D6.7020000@kernel.dk \
--to=axboe@kernel.dk \
--cc=JBeulich@novell.com \
--cc=davem@davemloft.net \
--cc=jmoyer@redhat.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=snitzer@gmail.com \
--cc=tj@kernel.org \
/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.