Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1613347

Re: RFC: reject unknown open flags

From Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups linux.kernel
Subject Re: RFC: reject unknown open flags
Date 2017-03-30 20:30 +0200
Message-ID <tqMZz-1Yh-1@gated-at.bofh.it> (permalink)
References <tqLh7-GX-9@gated-at.bofh.it> <tqLK9-16I-3@gated-at.bofh.it> <tqM3w-1dT-27@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Thu, Mar 30, 2017 at 10:21 AM, Christoph Hellwig <hch@lst.de> wrote:
>
> Failure atomic file updates, aka O_ATOMIC:
>
>         https://lwn.net/Articles/573092/
>
> Currently the way to probe for it is a new ioctl to check if atomicy
> is offered.  This should work, but it's rather fragile..

So quite frankly, I'd much rather see that people who really want to
check would instead just

     fd = open(... O_ATOMIC);
     if (fd < 0)
          .. regular error handling ..

     /* Did we actually get O_ATOMIC? */
     if (!(O_ATOMIC & fnctl(fd, F_GETFL, NULL)))
          .. warn about lack of O_ATOMIC ..

because I suspect that you will find users that might *want* atomic
behavior, but in the absence of atomicity guarantees will want to
still be able to do IO.

The above kind of model seems much more straightforward, and has no
backwards/forwards compatibility issues I can see.

I'm assuming you'd also possible want to be able to use F_SETFL to set
O_ATOMIC after the fact (independently of the open - I could see tools
like "dd" growing an atomic flag and setting it on stdout), so the
F_GETFL interface seems natural for that reason too.

              Linus

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

RFC: reject unknown open flags Christoph Hellwig <hch@lst.de> - 2017-03-30 18:40 +0200
  [PATCH 1/2] fs: add a VALID_OPEN_FLAGS Christoph Hellwig <hch@lst.de> - 2017-03-30 18:40 +0200
  [PATCH 2/2] fs: reject unknown open flags Christoph Hellwig <hch@lst.de> - 2017-03-30 18:40 +0200
    Re: [PATCH 2/2] fs: reject unknown open flags Linus Torvalds <torvalds@linux-foundation.org> - 2017-03-30 19:10 +0200
  Re: RFC: reject unknown open flags Linus Torvalds <torvalds@linux-foundation.org> - 2017-03-30 19:10 +0200
    Re: RFC: reject unknown open flags Christoph Hellwig <hch@lst.de> - 2017-03-30 19:30 +0200
      Re: RFC: reject unknown open flags Linus Torvalds <torvalds@linux-foundation.org> - 2017-03-30 20:30 +0200
        Re: RFC: reject unknown open flags Christoph Hellwig <hch@lst.de> - 2017-03-30 20:30 +0200
          Re: RFC: reject unknown open flags Linus Torvalds <torvalds@linux-foundation.org> - 2017-03-30 20:50 +0200
            Re: RFC: reject unknown open flags Boaz Harrosh <boaz@plexistor.com> - 2017-03-30 22:10 +0200
        Re: RFC: reject unknown open flags Paul Eggert <eggert@cs.ucla.edu> - 2017-03-30 21:10 +0200
          Re: RFC: reject unknown open flags Linus Torvalds <torvalds@linux-foundation.org> - 2017-03-30 21:20 +0200
    Re: RFC: reject unknown open flags Florian Weimer <fw@deneb.enyo.de> - 2017-03-30 21:40 +0200

csiph-web