linux-kernel - Block layer - meaning of REQ

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: <FA28BBF6-1D91-4F9B-99DF-5C46F27E2D44@alex.org.uk>
Date:	Fri, 1 Apr 2016 16:27:35 +0100
From:	Alex Bligh <alex@...x.org.uk>
To:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	nbd-general@...ts.sourceforge.net
Cc:	Alex Bligh <alex@...x.org.uk>, Eric Blake <eblake@...hat.com>
Subject: Block layer - meaning of REQ_FUA on not write requests

I am trying to clean up the documentation of the NBD protocol. NBD's
support for Force Unit Access (FUA) was modelled on the linux kernel
block layer. When I added support a few years ago, I omitted to find
out exactly what types of request it applies to. Obviously it applies
to write requests, but how about others (e.g. read)?

https://www.kernel.org/doc/Documentation/block/writeback_cache_control.txt

seems somewhat ambiguous. It says

> The REQ_FUA flag can be OR ed into the r/w flags of a bio submitted from the
> filesystem and will make sure that I/O completion for this request is only
> signaled after the data has been committed to non-volatile storage.

and

> For devices that also support the FUA bit the block layer needs
> to be told to pass through the REQ_FUA bit using:
> 
> 	blk_queue_flush(sdkp->disk->queue, REQ_FLUSH | REQ_FUA);
> 
> and the driver must handle write requests that have the REQ_FUA bit set
> in prep_fn/request_fn.  If the FUA bit is not natively supported the block
> layer turns it into an empty REQ_FLUSH request after the actual write.

I can see four possible interpretations for reads:

1. REQ_FUA is not permitted on requests other than write, and it is an
   error to include it.

2. REQ_FUA does nothing on requests other than writes, and whilst permitted
   is ignored.

3. REQ_FUA has the following meaning on read: that area of data referred
   to by the read must be written to persistent storage if it is dirty.

and the following which is not an interpretation of the above, but is
logical:

4. REQ_FUA means that any in-memory copy of the data to be read must be
   discarded and the data reread from persistent storage (in case it
   has been written to by another client, for instance).

What meaning does REQ_FUA have for reads? Similarly what meaning does
it have for other block layer requests (e.g. trim)?

-- 
Alex Bligh