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]

Date:	Mon, 30 May 2011 21:54:34 +0200
From:	"D. Jansen" <d.g.jansen@...glemail.com>
To:	Valdis.Kletnieks@...edu
Cc:	david@...g.hm, Theodore Tso <tytso@....edu>,
	Oliver Neukum <oneukum@...e.de>, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, Dave Chinner <david@...morbit.com>,
	njs@...ox.com, bart@...wel.tk
Subject: Re: [rfc] Ignore Fsync Calls in Laptop_Mode

On Mon, May 30, 2011 at 8:43 PM,  <Valdis.Kletnieks@...edu> wrote:
> On Mon, 30 May 2011 20:28:24 +0200, "D. Jansen" said:
>
>> I'm not really sure I why shouldn't have that choice as a user. Just
>> because someone else could be running a mailserver on his system and
>> configure it in a way that it doesn't behave as it should?
>
> It cuts both ways.  If a piece of software really wants to be sure that the
> fsync() semantics it's expecting are actually adhered to and refuses to run
> otherwise, how does it tell that you're lying to it?

Well if we allow to use a library to wrap fsync into write barriers
that doesn't seem to matter because software doesn't need to know what
happens and isn't even supposed to be able to work around it.

If this was to go into the kernel as an option, the situation was
different. But really, if you look at this discussion and the feedback
so far I don't think that's an option we need to discuss at this
point...
>
>> The big problem is that so far only fsync existed and lots of software
>> seemingly abuses it as an expensive write barrier. And it would really
>> be lovely to have the choice to stop that on an opt-in basis in laptop
>> mode.
>
> It's not "seemingly abuses it".  That's the existing userspace API for
> inserting a barrier.  The problem is that as defined, it will wait for the
> writeback to actually finish - which is actually as good as you can get without
> getting into the async I/O support.  If there was a "insert barrier and return"
> API, how would it report back that the barrier had failed with EIO after it had
> already returned to userspace?

I guess with another call some time later, to check for the success of
the previous call?
--
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/