linux-kernel - Re: [rfc] Ignore Fsync Calls in Laptop

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]

Message-ID: <BANLkTiks7U28D1896318rK0j=W-tux1uJA@mail.gmail.com>
Date:	Mon, 23 May 2011 15:05:50 +0200
From:	"D. Jansen" <d.g.jansen@...glemail.com>
To:	Oliver Neukum <oneukum@...e.de>
Cc:	Dave Chinner <david@...morbit.com>, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, tytso@....edu
Subject: Re: [rfc] Ignore Fsync Calls in Laptop_Mode

On Mon, May 23, 2011 at 10:12 AM, Oliver Neukum <oneukum@...e.de> wrote:
>> > 3. A lib doesn't fix the ordering guarantee problem.
>>
>> A properly implemented filesystem will not have ordering problems
>> just because fsyncs are not issued.
>
> But user space will have this problem. A single task's sequence of
> write(); fsync(); write(); does give an implicit guarantee of ordering
> to user space. To keep that guarantee, you need kernel support,
> because only the kernel can issue the necessary barrier/flush commands.
> A filesystem is not required to make sure your writes hit the disk
> in the order you issued them, unless you use fsync, which gives
> an even larger guarantee, but also implies ordering.

If this is correct, we do need some form of kernel support. To ensure
that one fsync means the write comes before another. Because how would
it be implemented in user space to ensure write ordering without
fsync? The library could only request the kernel to enforce write
ordering. Otherwise it would have to catch and buffer all writes
itself and then commit them with fsyncs in between. _That_ doesn't
sound like a good idea at all...

And the alternative would be that a write of
1. XXXXXXXXXXXXXXXX (file)
2. XXHHHHHXXXXXXX (write H)
3. XXHHHNNNNXXXX (write N)

would become
1. XXXXXXXXXXXXXXXX (file)
2. XXXXXXNNNNXXXX (write N)
3. XXHHHHHNNXXXX (write H)

And we have data that was never supposed to be on disk this way...
--
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/