linux-kernel - Re: POSIX violation by writeback error

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

Message-ID: <20180925002104.2da0140c@alans-desktop>
Date:   Tue, 25 Sep 2018 00:21:04 +0100
From:   Alan Cox <gnomes@...rguk.ukuu.org.uk>
To:     "Theodore Y. Ts'o" <tytso@....edu>
Cc:     焦晓冬 <milestonejxd@...il.com>,
        jlayton@...hat.com, R.E.Wolff@...wizard.nl,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: POSIX violation by writeback error

> The other thing which you seem to be assuming is that applications
> which care about precious data won't use fsync(2).  And in general,
> it's been fairly well known for decades that if you care about your
> data, you have to use fsync(2) or O_DIRECT writes; and you *must*
> check the error return of both the fsync(2) and the close(2) system
> calls.  Emacs got that right in the mid-1980's --- over 30 years ago.
> We mocked GNOME and KDE's toy notepad applications for getting this
> wrong a decade ago, and they've since fixed it.

That's also because our fsync no longer sucks rocks. It used to be
possible for a box under heavy disk I/O to take minutes to fsync a file
because our disk scheduling was so awful (hours if doing a backup to USB
stick).

The problem I think actually is a bit different. There isn't an

	int fbarrier(int fd, ...);

call with more relaxed semantics so that you can say 'what I have done so
far must not be consumed by a reader until we are sure it is stable, but
I don't actually need it to hit disk right now'. That's just a flag on
buffers saying 'if we try to read this, make sure we write it out first',
and the flag is cleared as the buffer hits media in writeback.

All of this is still probabilities. I can do all the fsync's I like,
consume the stable data, cause actions over the network like sending
people goods, and then the server is destroyed by a power surge.
Transactions are a higher level concept and the kernel can't fix that.

Alan