public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Jan Hudec <bulb@ucw.cz>
Cc: linux-fsdevel@vger.kerner.org, linux-kernel@vger.kernel.org
Subject: Re: Race in open(O_CREAT|O_EXCL) and network filesystem
Date: 29 Jul 2002 13:45:52 +0200	[thread overview]
Message-ID: <shsk7nezrin.fsf@charged.uio.no> (raw)
In-Reply-To: <20020728165256.GA4631@vagabond>

>>>>> " " == Jan Hudec <bulb@ucw.cz> writes:

     > Hi all, maybe I'm blind, but I think there is a race featuring
     > open(O_CREAT|O_EXCL) and nfs or any other network fs.

     > 1) Is there some reason this can't happen that I overlooked?

No. It can indeed happen, and it is one of my pet peeves in the
current open_namei() layout. The VFS seems all too often to assume
that a semaphore suffices to ensure atomicity. This is obviously not
the case for networked filesystems.

     > 2) If it is a problem (comment in NFS suggest so), I can see
     >    two ways of
     > handling this. Either pass the flags to the create method, or
     > restart the open when create returns EEXISTS. Which one would
     > be prefered?

I'd rather like to see some method by which we could merge the
lookup() and create() calls.

Given its support for exclusive create, there is no reason why we
should be doing the lookup in the first place on NFSv3. It's just a
waste of an RPC call...
IIRC, the NFSv4 client actually has to work around the whole
open_namei() thingy with a new 'open()' method in order to conform to
the RFCs.

The minimum change I'd need, though, is for vfs_create() to actually
pass me the O_EXCL flag.

Cheers,
  Trond

  reply	other threads:[~2002-07-29 11:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-28 16:52 Race in open(O_CREAT|O_EXCL) and network filesystem Jan Hudec
2002-07-29 11:45 ` Trond Myklebust [this message]
2002-07-29 11:50 ` Neil Brown
2002-07-29 15:02   ` Andreas Dilger
2002-07-29 23:04     ` Neil Brown
2002-07-29 23:44       ` Andreas Dilger

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=shsk7nezrin.fsf@charged.uio.no \
    --to=trond.myklebust@fys.uio.no \
    --cc=bulb@ucw.cz \
    --cc=linux-fsdevel@vger.kerner.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox