[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [dm-devel] [PATCH 1/2] blk-flush: move the queue kick into blk_insert_cloned_request
- From: Tejun Heo <tj kernel org>
- To: Jeff Moyer <jmoyer redhat com>
- Cc: jaxboe fusionio com, dm-devel redhat com, msnitzer redhat com, linux-kernel vger kernel org, christophe saout de
- Subject: Re: [dm-devel] [PATCH 1/2] blk-flush: move the queue kick into blk_insert_cloned_request
- Date: Wed, 12 Oct 2011 15:17:32 -0700
On Wed, Oct 12, 2011 at 05:22:41PM -0400, Jeff Moyer wrote:
> A dm-multipath user reported[1] a problem when trying to boot
> a kernel with commit 4853abaae7e4a2af938115ce9071ef8684fb7af4
> (block: fix flush machinery for stacking drivers with differring
> flush flags) applied. It turns out that an empty flush request
> can be sent into blk_insert_flush. When the BUG_ON was fixed
> to allow for this, I/O on the underlying device would stall. The
> reason is that blk_insert_cloned_request does not kick the queue.
> In the aforementioned commit, I had added a special case to
> kick the queue if data was sent down but the queue flags did
> not require a flush. A better solution is to push the queue
> kick up into blk_insert_cloned_request.
>
> This patch, along with a follow-on which fixes the BUG_ON, fixes
> the issue reported.
>
> [1] http://www.redhat.com/archives/dm-devel/2011-September/msg00154.html
>
> Reported-by: Christophe Saout <christophe saout de>
> Signed-off-by: Jeff Moyer <jmoyer redhat com>
Acked-by: Tejun Heo <tj kernel org>
Thank you for fixing this, but one curiosity, what happens for !flush
cloned requests? Is someone else responsible for kicking the queue?
--
tejun
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]