linux-kernel - Re: ext2 + -osync: not as easy as it seems

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, 14 Jan 2009 15:43:46 +0100
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Theodore Tso <tytso@....EDU>
Cc:	Jan Kara <jack@...e.cz>,
	Fernando Luis Vázquez Cao 
	<fernando@....ntt.co.jp>, Alan Cox <alan@...rguk.ukuu.org.uk>,
	Pavel Machek <pavel@...e.cz>,
	kernel list <linux-kernel@...r.kernel.org>, sandeen@...hat.com
Subject: Re: ext2 + -osync: not as easy as it seems

On Wed, Jan 14 2009, Theodore Tso wrote:
> On Wed, Jan 14, 2009 at 03:08:04PM +0100, Jens Axboe wrote:
> > 
> > It also guarentees that when you get a completion for that barrier
> > write, it's on safe storage. Think of it as a flush-write-flush
> > operation, in the presence of write back caching.
> > 
> 
> Is that true even if the barrier isn't attached to a write operation,
> i.e., when using
> 
>       blkdev_issue_flush(sb, NULL);
> 
> ?

No, since there's no specific write to protect in that case. The above
will flush existing writes to platter, but has no bearing on writes
submitted later (other than the obvious effect that they will be on disk
later then previously submitted writes). So for blkdev_issue_flush(),
when that returns with good status, then the writes are safe. In the
absence of the barrier flag on a write, completion of that write may
just mean that the disk drive is aware of it, not that it is in any way
safe.

The hardware may even treat the flush as a noop and do absolutely
nothing, which is perfectly valid if it guarantees us that it will never
lose a submitted write.

-- 
Jens Axboe

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