linux-kernel - Question: block layer and 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>] [day] [month] [year] [list]

Message-ID: <4C9FE036825E46DE8121365F@Ximines.local>
Date:	Tue, 24 May 2011 13:19:05 +0100
From:	Alex Bligh <alex@...x.org.uk>
To:	linux-kernel@...r.kernel.org, Jan Kara <jack@...e.cz>
cc:	Alex Bligh <alex@...x.org.uk>
Subject: Question: block layer and REQ_FLUSH

Documentation/block/writeback_cache_control.txt says:

> The REQ_FLUSH flag can be OR ed into the r/w flags of a bio submitted from
> the filesystem and will make sure the volatile cache of the storage device
> has been flushed before the actual I/O operation is started.  This
> explicitly guarantees that previously completed write requests are on
> non-volatile storage before the flagged bio starts.

>>From the block driver's point of view, is it only necessary to ensure
*completed* I/O operations are flushed to disk (as per the text), or
is it also necessary to ensure *in flight* requests (i.e. those that
have not been completed) are flushed to disk too? IE when the block
layer does the flush, does it also wait for in-flight I/O to complete?

IE if the time sequence is
	WRITE1
	WRITE2
	WRITE3
			Complete WRITE2 -> sent to volatile cache
	WRITE4
	REQ_FLUSH

Do I need to only ensure WRITE2 is flushed, or (as I suspect) do I
need to wait for all bios previously submitted to the driver to
complete? If so, from the driver's point of view anyway, should the
guarantee refer to "previously submitted write requests" as opposed
to "previously completed"?

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