linux-kernel - blk-mq flush fix

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-next>] [day] [month] [year] [list]

Message-ID: <20131026114612.GA8576@infradead.org>
Date:	Sat, 26 Oct 2013 04:46:12 -0700
From:	Christoph Hellwig <hch@...radead.org>
To:	Alexander Gordeev <agordeev@...hat.com>,
	Jens Axboe <axboe@...nel.dk>, Tejun Heo <tj@...nel.org>,
	Nicholas Bellinger <nab@...ux-iscsi.org>
Cc:	linux-kernel@...r.kernel.org
Subject: blk-mq flush fix

I've just ran into an issue where I ran out of blk-mq tags on my virtio
setup on what appears a heavy fsync workload.  When drilling it down it
seemed to be a tag leak.  This reminded me of a commit I had seen in
the scsi-mq tree but never on any mailinglist (and neither in my Inbox
despite the Cc tag) which turned out to be in Jens' blk-mq tree either.

https://git.kernel.org/cgit/linux/kernel/git/nab/target-pending.git/commit/?h=scsi-mq&id=620fe5a562440a823e7a25ae99dc19a6fbd53949

>From a quick look over the patch I'm not entirely sure it's correct, but
it's at least going in the right direction.  The reason for the issue
that Alexander and I saw is the following:

The flush state machine takes in a struct request, which then is
submitted multiple times to the underling driver.  The old block code
requeses the same request for each of those, so it does not have an
issue with tapping into the request pool.  The new one on the other hand
allocates a new request for each of the actualy steps of the flush
sequence.

In theory this should make the patch from Alexander the right fix,
except that we do have a corner case where we do not do the above steps:
In case the state machine doesn't need to be run we issue the request
directly.  This either happens if the driver doesn't need any cache
flushes, or we only requested force unit access and the driver supports
that natively.

It seems like we should set simply not require a tag at all for those
sub requests and solve the issue that way.

And Alexander and Nick: how did this patch end up in Nick's tree?  I'm a
bit curious at all as there's been no visibility at all, despite Cc tags
to Jens and me.
--
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/