mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: linda.dunaphant@ccur.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: NFS: NFS3 lookup fails if creating a file with O_EXCL & multiple mountpoints in pathname
Date: Mon, 06 Jun 2005 23:01:54 -0400	[thread overview]
Message-ID: <1118113315.13667.8.camel@lade.trondhjem.org> (raw)
In-Reply-To: <1118111348.13894.29.camel@lindad>

må den 06.06.2005 Klokka 22:29 (-0400) skreiv Linda Dunaphant:
> Hi Trond,
> 
> One of our applications was doing an open on a NFS client with the flags
> set for O_WRONLY|O_CREAT|O_EXCL|0x4. There are numerous symlinks in the
> pathname for the file that go into two different NFS filesystems. The
> file create works properly if the filesystems are mounted as NFS2, but
> it fails with NFS3 mounts.
>  
> In nfs_lookup() there is a check to see if it is an exclusive create.
> If it is exclusive, nfs_lookup() bypasses ("optimizes" away) the rest
> of the lookup. When the problem occurs, I see it stop the lookup too
> early. This only occurs when the basename portion of the pathname is
> not currently in the NFS cache from a previous non- O_EXCL pathname lookup.
>  
> The nfs_is_exclusive_create() was returning TRUE, even when the
> search wasn't at the last pathname component. This occurred because
> the LOOKUP_CONTINUE flag is reset when it crosses the second
> mountpoint into the NFS filesystem.  nfs_is_exclusive_create() was
> trying to use this flag to determine if it was at the end point
> of the pathname search. Since it was reset when it crossed the
> mountpoint boundary, it returned TRUE several pathname levels too
> early.

Then the correct fix here is to fix the LOOKUP_CONTINUE flag so that it
is set in the above situations.

> I changed the nfs_is_exclusive_create() to use the LOOKUP_PARENT
> flag instead of the LOOKUP_CONTINUE flag. I found that LOOKUP_PARENT
> stays set until you get to the very last pathname level, which is
> the correct point for it to check whether it is an exclusive create.

Vetoed. LOOKUP_PARENT and LOOKUP_CONTINUE are _very_ different flags.
The former tells you what the goal of the lookup operation is. The
latter tells you about the current state of the lookup operation (namely
whether or not the VFS thinks it is on the last element of the path
lookup).

Cheers,
  Trond


  reply	other threads:[~2005-06-07  3:03 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-08  0:52 [PATCH] mtime attribute is not being updated on client Linda Dunaphant
2005-04-08 13:11 ` Trond Myklebust
2005-04-08 20:54   ` Linda Dunaphant
2005-04-09  1:23     ` Linda Dunaphant
2005-06-07  0:28       ` Linda Dunaphant
2005-06-07  2:29         ` NFS: NFS3 lookup fails if creating a file with O_EXCL & multiple mountpoints in pathname Linda Dunaphant
2005-06-07  3:01           ` Trond Myklebust [this message]
2005-06-07 13:41           ` Trond Myklebust
2005-06-07 22:10             ` Linda Dunaphant

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=1118113315.13667.8.camel@lade.trondhjem.org \
    --to=trond.myklebust@fys.uio.no \
    --cc=linda.dunaphant@ccur.com \
    --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

all inboxes | Powered by JetHome®