linux-kernel - Re: FLUSH/FUA documentation & code discrepancy

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:	Tue, 4 Sep 2012 15:46:20 -0700
From:	Tejun Heo <tj@...nel.org>
To:	Philipp Reisner <philipp.reisner@...bit.com>
Cc:	Jens Axboe <axboe@...nel.dk>, Christoph Hellwig <hch@....de>,
	linux-kernel@...r.kernel.org, drbd-dev@...ts.linbit.com
Subject: Re: FLUSH/FUA documentation & code discrepancy

Hello,

On Tue, Sep 04, 2012 at 02:32:01PM +0200, Philipp Reisner wrote:
> I think commit 1e87901e18 was wrong. Starting with that commit the REQ_FLUSH 
> and REQ_FUA bits get stripped away if the queue does not advertise REQ_FLUSH
> or REQ_FUA support.
> 
> But the REQ_FLUSH bit is also tested for when not merging requests
> (blk_queue_bio()) or when it comes to the elevator (blk_flush_plug_list()).
> 
> So, since this patch the elevator reorders write requests on queues that 
> do not have REQ_FLUSH or REQ_FUA set.
> 
> While on queues that have REQ_FLUSH or REQ_FUA set, the elevator does
> not reorder writes across FLUSHes.

Currently, FLUSH/FUA doesn't enforce any ordering requirement.  File
systems are responsible for draining all writes which have to happen
before and not issue further writes which should come after.  The use
of SOFTBARRIER there is mostly historical.  I *suspect* we should be
able to drop that as RQ_NOMERGE_FLAGS already contain FLUSH and FUA.
Not really looked through it tho.

> I have the impression every file system lets IO drain, and issues a
> flush afterwards with the blkdev_issue_flush() function. BTW that
> function turns into a non-obvious no-op as soon as the queue does not
> have the REQ_FUA or REQ_FLUSH bits set. It does not look like it is
> a no-op by intention.

So, yeah, it is no-op by intention.  We probably should make the
documentation clearer.

Thanks.

-- 
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/