public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Linda Dunaphant <linda.dunaphant@ccur.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: linux-kernel@vger.kernel.org
Subject: NFS: NFS3 lookup fails if creating a file with O_EXCL & multiple mountpoints in pathname
Date: Mon, 06 Jun 2005 22:29:08 -0400	[thread overview]
Message-ID: <1118111348.13894.29.camel@lindad> (raw)
In-Reply-To: <1118104107.13894.20.camel@lindad>

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.
 
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.

The following patch for 2.6.12-rc5 fixed the problem.

Regards,
Linda

diff -ura base/fs/nfs/dir.c new/fs/nfs/dir.c
--- base/fs/nfs/dir.c	2005-06-06 20:59:22.000000000 -0400
+++ new/fs/nfs/dir.c	2005-06-06 22:14:24.000000000 -0400
@@ -705,7 +705,7 @@
 {
 	if (NFS_PROTO(dir)->version == 2)
 		return 0;
-	if (!nd || (nd->flags & LOOKUP_CONTINUE) || !(nd->flags & LOOKUP_CREATE))
+	if (!nd || (nd->flags & LOOKUP_PARENT) || !(nd->flags & LOOKUP_CREATE))
 		return 0;
 	return (nd->intent.open.flags & O_EXCL) != 0;
 }



  reply	other threads:[~2005-06-07  2:32 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         ` Linda Dunaphant [this message]
2005-06-07  3:01           ` NFS: NFS3 lookup fails if creating a file with O_EXCL & multiple mountpoints in pathname Trond Myklebust
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=1118111348.13894.29.camel@lindad \
    --to=linda.dunaphant@ccur.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=trond.myklebust@fys.uio.no \
    /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