linux-kernel - Re: RFC: reject unknown open flags

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: <CA+55aFyKLCCe2OFCnyLYPDMT+DNWhYRQiLwFx1UU1+sf9w3oKA@mail.gmail.com>
Date:   Thu, 30 Mar 2017 12:14:54 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Paul Eggert <eggert@...ucla.edu>
Cc:     Christoph Hellwig <hch@....de>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Linux API <linux-api@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        libc-alpha <libc-alpha@...rceware.org>
Subject: Re: RFC: reject unknown open flags

On Thu, Mar 30, 2017 at 12:02 PM, Paul Eggert <eggert@...ucla.edu> wrote:
>
>> I'm assuming you'd also possible want to be able to use F_SETFL to set
>> O_ATOMIC after the fact
>
> Just for fun, one thread can set O_ATOMIC at the same time another thread is
> doing a 'write'....

I'm sure that falls under "if you break it, you get to keep both
pieces". IOW, I don't think anybody will ever say that the concurrent
write has to have some particular semantics wrt the concurrent
O_ATOMIC. Maybe *part* of the write will be done with some semantics,
and part of the write will be done with other semantics.

My guess is that there is going to be very few O_ATOMIC users anyway,
and they'll very carefully set it once and test it (or not even test
it - just make it be a configuration flag and tell people "don't ask
for O_ATOMIC if your system doesn't support it")

                  Linus