Re: Multi-partition block layer behaviour

From: Shaohua Li
Date: Mon Oct 31 2011 - 20:21:23 EST


On Mon, 2011-10-31 at 18:21 +0800, Tiju Jacob wrote:
> >> ok, thanks. So this means the elevator is switching in the test. How
> >> about below patch:
> >>
> >> diff --git a/block/elevator.c b/block/elevator.c
> >> index a3b64bc..e14824a 100644
> >> --- a/block/elevator.c
> >> +++ b/block/elevator.c
> >> @@ -683,8 +683,13 @@ void __elv_add_request(struct request_queue *q, struct request *rq, int where)
> >> * - Usually, back inserted requests won't be merged
> >> * with anything. There's no point in delaying queue
> >> * processing.
> >> + * If elevator is switching, doesn't need run the queue.
> >> + * elevator switching will run it anyway. And this could
> >> + * cause warning since the code might run in atomic
> >> + * environment(blk_flush_plug_list() callbed in schedule())
> >> */
> >> - __blk_run_queue(q);
> >> + if (!test_bit(QUEUE_FLAG_ELVSWITCH, &q->queue_flags))
> >> + __blk_run_queue(q);
> >> break;
> >>
> >> case ELEVATOR_INSERT_SORT_MERGE:
> >>
> >>
> > oh, wait. We should have no this issue with latest kernel, because
> > blk_schedule_flush_plug is moved out of schedule atomic environment. please
> > try a latest kernel, for example, 3.1.
> >
>
> Even after applying the above patch, I am getting the same error. We
> have to use the linux 3.0.* kernel series. So is there a fix for the
> 3.0 series?
> We'll defenetly check with the 3.1 kernel and let know.
please ignore the patch. There is a fix in upstream:
9c40cef2b799f9b5e7fa5de4
and it's marked -stable, so it will go to 3.0 stable.
if 3.1 kernel doesn't work, please report back with a log.

Thanks,
Shaohua

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/