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

Message-ID: <20180926191055.6fc1514f@alans-desktop>
Date:   Wed, 26 Sep 2018 19:10:55 +0100
From:   Alan Cox <gnomes@...rguk.ukuu.org.uk>
To:     "Theodore Y. Ts'o" <tytso@....edu>
Cc:     Jeff Layton <jlayton@...hat.com>,
        焦晓冬 <milestonejxd@...il.com>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        Rogier Wolff <R.E.Wolff@...Wizard.nl>
Subject: Re: POSIX violation by writeback error

> And I think that's fine.  The only way we can make any guarantees is
> if we do what Alan suggested, which is to imply that a read on a dirty
> page *block* until the the page is successfully written back.  This
> would destroy performance.

In almost all cases you don't care so you wouldn't use it. In those cases
where it might matter it's almost always the case that a reader won't
consume it before it hits the media.

That's why I suggested having an fbarrier() so you can explicitly say 'in
the even that case does happen then stall and write it'. It's kind of
lazy fsync. That can be used with almost no cost by things like mail
daemons. Another way given that this only really makes sense with locks
is to add that fbarrier notion as a file locking optional semantic so you
can 'unlock with barrier' and 'lock with barrier honoured'

Alan