linux-kernel - Re: [PATCH 1/2] blk-flush: move the queue kick into blk_insert_cloned

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 12 Oct 2011 15:17:32 -0700
From:	Tejun Heo <tj@...nel.org>
To:	Jeff Moyer <jmoyer@...hat.com>
Cc:	linux-kernel@...r.kernel.org, jaxboe@...ionio.com,
	christophe@...ut.de, dm-devel@...hat.com, msnitzer@...hat.com
Subject: Re: [PATCH 1/2] blk-flush: move the queue kick into
 blk_insert_cloned_request

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@...ut.de>
> Signed-off-by: Jeff Moyer <jmoyer@...hat.com>

Acked-by: Tejun Heo <tj@...nel.org>

Thank you for fixing this, but one curiosity, what happens for !flush
cloned requests?  Is someone else responsible for kicking the queue?

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