All of
 help / color / mirror / Atom feed
From: Al Viro <>
To: Linus Torvalds <>
Cc: Linux Kernel Mailing List <>,
	linux-fsdevel <>
Subject: Re: [git pull] vfs.git part 2
Date: Fri, 12 Jul 2013 06:48:17 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, Jul 11, 2013 at 02:42:54PM -0700, Linus Torvalds wrote:
> On Wed, Jul 3, 2013 at 5:29 AM, Al Viro <> wrote:
> >         Assorted f_pos race fixes, making do_splice_direct() safe to
> > call with i_mutex on parent, O_TMPFILE support, Jeff's locks.c series,
> > ->d_hash/->d_compare calling conventions changes from Linus, misc stuff
> > all over the place.  Please, pull from
> > git:// for-linus
> Btw, the new O_TMPFILE support seems to have a fundamental interface
> problem: old kernels ignore that flag, and happily implement totally
> different semantics than the intended new ones.
> So with a *new* kernel, if the filesystem doesn't support O_TMPFILE,
> you get an ENOTSUPP error, and you can fall back on whatever old
> tmpfile logic you had.
> But with an *old* kernel, O_TMPFILE will just silently be ignored as
> an unrecognized flag, and things won't work. If you do
>   fd = open("dirname", O_CREAT | O_TMPFILE | O_RDWR, 0666);
> it may be that it ends up acting as a "create file at specified
> directory path" instead of what the user *meant* for it to do, which
> was "create unnamed temporary file in the specified directory".
> This seems to make the feature actively dangerous. You can't just try
> to use it and have a fallback, because that "try to use it" phase may
> incorrectly succeed.
> Yes, you can force things to not work on old systems by having a slash
> at the end of the directory name, but if you ever forget that, you'll
> end up with the above problem.
> Am I missing something?

It's slightly less painful than that - if dirname exists, the old kernels
will fail; O_CREAT for existing directory means an error.  So in practice
you can use it safely.  I'm not too happy about that situation, but I
hadn't been able to come up with anything better, short of a new syscall
that would duplicate openat(2), but reject unknown values in flags argument
from the very beginning ;-/  Which is what we probably should've done with
openat(2) itself, but it's too late for that now...

  reply	other threads:[~2013-07-12  5:48 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 [this message]
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
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.