On 2011-03-07 20:39, Jeff Moyer wrote: > Jens Axboe <axboe@xxxxxxxxx> writes: > >> On 2011-03-07 20:33, Jeff Moyer wrote: >>> Tejun Heo <tj@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
