All of
 help / color / mirror / Atom feed
From: Rasmus Villemoes <>
Subject: Re: [git pull] vfs.git part 2
Date: Mon, 15 Jul 2013 23:13:01 +0000	[thread overview]
Message-ID: <> (raw)

Linus Torvalds <> writes:

> On Fri, Jul 12, 2013 at 12:39 PM, Al Viro <> wrote:
>> [suggested by Rasmus Villemoes] make O_DIRECTORY | O_RDWR part of O_TMPFILE;
>> that will fail on old kernels in a lot more cases than what I came up with.
> So see earlier about why I'm not convinced about O_RDWR. But even if
> we really want that (and it might be better to start off too narrow
> than accept anything else) your patch tests those bits the wrong way
> (any O_RDWR test should be done using the O_ACCMODE mask, not using
> the O_RDWR value itself as a mask)

On further thought, I think I'll retract the suggestion to include
O_RDWR in O_TMPFILE: If that is done, I don't see how one can ever allow
O_WRONLY functionality without breaking the ABI (or introducing
and correct use is open(path, O_TMPFILE|O_RDWR, mode).

Also, O_TMPFILE without O_RDWR (or O_WRONLY) should then give -EINVAL. 


The access mode is explicit
Easy to allow O_TMPFILE|O_WRONLY in the future (or now?)
Static code checkers complaining about the lack of
O_{RDONLY,RDWR,WRONLY} in open() (?)


We catch one fewer case on older kernels, but not one which is likely to
occur in real programs: On old kernels, O_TMPFILE|O_RDONLY, or
equivalently O_TMPFILE, may give a valid file descriptor (in the case
where path does name a directory). However: Anyone writing a program
using O_TMPFILE probably at least tests on a kernel knowing about that,
and so would be given the -EINVAL error, and the documentation can just
spell out that O_TMPFILE is not compatible with O_RDONLY.


  parent reply	other threads:[~2013-07-15 23:13 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-03 12:29 [git pull] vfs.git part 2 Al Viro
2013-07-11 21:42 ` Linus Torvalds
2013-07-12  5:48   ` Al Viro
2013-07-12 11:54     ` Al Viro
2013-07-12 12:02     ` Rasmus Villemoes
2013-07-12 15:48       ` Al Viro
2013-07-12 16:30         ` Rasmus Villemoes
2013-07-12 19:13           ` Al Viro
2013-07-12 19:39             ` Al Viro
2013-07-12 20:21               ` Linus Torvalds
2013-07-12 21:16                 ` Al Viro
2013-07-15 23:13                 ` Rasmus Villemoes [this message]
2013-07-12 19:42             ` Linus Torvalds
2013-07-12 20:02               ` Al Viro
2017-07-05  7:14 Al Viro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.