public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Neil Brown <neilb@cse.unsw.edu.au>
Cc: David Fries <dfries@umr.edu>, linux-kernel@vger.kernel.org
Subject: Re: Stale NFS handles on 2.4.2
Date: Thu, 1 Mar 2001 02:13:48 +0100 (CET)	[thread overview]
Message-ID: <15005.41548.370345.60631@charged.uio.no> (raw)
In-Reply-To: <15005.30849.720697.525157@notabene.cse.unsw.edu.au>
In-Reply-To: <20010214002750.B11906@unthought.net> <20010224141855.B12988@d-131-151-189-65.dynamic.umr.edu> <15000.39826.947692.141119@notabene.cse.unsw.edu.au> <20010224235342.D483@d-131-151-189-65.dynamic.umr.edu> <15000.53110.664338.230709@notabene.cse.unsw.edu.au> <20010225131013.E483@d-131-151-189-65.dynamic.umr.edu> <15004.16978.439300.108625@notabene.cse.unsw.edu.au> <shsd7c3817s.fsf@charged.uio.no> <15005.30849.720697.525157@notabene.cse.unsw.edu.au>

>>>>> " " == Neil Brown <neilb@cse.unsw.edu.au> writes:

     > In short, I really don't think that NFS_INO_STALE (or any other
     > item if information received from the server) should be
     > considered to be permanent and never rechecked.

There are 2 problems of inode corruption if you allow inodes to die
and then reappear at will:

  1) is that several servers, including the userspace nfsd, have
     problems with filehandle reuse. You do not want to fall victim
     either to corruption either of the inode cache or (worse) the
     file itself.

     In the same vein, consider all these horror stories about people
     sharing CDROMs over NFS, mounting/umounting them at will...

  2) Even on servers that strictly respect the uniqueness of
     filehandles you can risk cache/file corruption due to inode
     aliasing when for instance you are using shared mmap between 2
     processes.

     For instance: under a lookup() operation, the client notices that
     the inode is stale, creates a new one (after unhashing the old
     one of course but otherwise not invalidating it).
     If the old inode is then magically declared to be OK, you
     suddenly have 2 inodes with 2 different caches that are
     supposed to represent the same file.

Of course, the second problem is not really relevant to the root
directory inode (which should never get aliased anyway). Perhaps the
correct thing to do would be to allow root inodes to clear the
NFS_INO_STALE flag? Something like the following...

Cheers,
   Trond

--- linux-2.4.2/fs/nfs/inode.c.orig	Wed Feb 14 01:14:28 2001
+++ linux-2.4.2/fs/nfs/inode.c	Thu Mar  1 02:08:59 2001
@@ -819,24 +819,22 @@
 int
 __nfs_revalidate_inode(struct nfs_server *server, struct inode *inode)
 {
-	int		 status = 0;
+	int		 status = -ESTALE;
 	struct nfs_fattr fattr;
 
 	dfprintk(PAGECACHE, "NFS: revalidating (%x/%Ld)\n",
 		inode->i_dev, (long long)NFS_FILEID(inode));
 
 	lock_kernel();
-	if (!inode || is_bad_inode(inode) || NFS_STALE(inode)) {
-		unlock_kernel();
-		return -ESTALE;
-	}
+	if (!inode || is_bad_inode(inode))
+ 		goto out_nowait;
+	if (NFS_STALE(inode) && inode != inode->i_sb->s_root->d_inode)
+ 		goto out_nowait;
 
 	while (NFS_REVALIDATING(inode)) {
 		status = nfs_wait_on_inode(inode, NFS_INO_REVALIDATING);
-		if (status < 0) {
-			unlock_kernel();
-			return status;
-		}
+		if (status < 0)
+			goto out_nowait;
 		if (time_before(jiffies,NFS_READTIME(inode)+NFS_ATTRTIMEO(inode))) {
 			status = NFS_STALE(inode) ? -ESTALE : 0;
 			goto out_nowait;
@@ -850,7 +848,8 @@
 			 inode->i_dev, (long long)NFS_FILEID(inode), status);
 		if (status == -ESTALE) {
 			NFS_FLAGS(inode) |= NFS_INO_STALE;
-			remove_inode_hash(inode);
+			if (inode != inode->i_sb->s_root->d_inode)
+				remove_inode_hash(inode);
 		}
 		goto out;
 	}
@@ -863,6 +862,8 @@
 	}
 	dfprintk(PAGECACHE, "NFS: (%x/%Ld) revalidation complete\n",
 		inode->i_dev, (long long)NFS_FILEID(inode));
+
+	NFS_FLAGS(inode) &= ~NFS_INO_STALE;
 out:
 	NFS_FLAGS(inode) &= ~NFS_INO_REVALIDATING;
 	wake_up(&inode->i_wait);

  reply	other threads:[~2001-03-01  1:14 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-13 23:27 Stale NFS handles on 2.4.1 Jakob Østergaard
2001-02-13 23:31 ` Alan Cox
2001-02-13 23:43   ` Jakob Østergaard
2001-02-14  8:35   ` Rogier Wolff
2001-02-14  0:02 ` Trond Myklebust
2001-02-24 20:18 ` Stale NFS handles on 2.4.2 David Fries
2001-02-25  5:43   ` Neil Brown
2001-02-25  5:53     ` David Fries
2001-02-25  9:25       ` Neil Brown
2001-02-25 19:10         ` David Fries
2001-02-28  0:12           ` Neil Brown
2001-02-28 12:02             ` Trond Myklebust
2001-02-28 22:15               ` Neil Brown
2001-03-01  1:13                 ` Trond Myklebust [this message]
     [not found]                   ` <20010228211808.C24668@d-131-151-189-65.dynamic.umr.edu>
2001-03-01  9:07                     ` Trond Myklebust
     [not found]                       ` <s5gwva9simp.fsf@egghead.curl.com>
2001-03-01 14:13                         ` Stale NFS handles on 2.4.2^H^H^H^H^H2.2.19 Trond Myklebust
2001-02-25 14:00   ` Stale NFS handles on 2.4.2 Trond Myklebust
2001-02-26  9:54     ` Lennert Buytenhek
2001-02-26 15:56       ` David Fries

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=15005.41548.370345.60631@charged.uio.no \
    --to=trond.myklebust@fys.uio.no \
    --cc=dfries@umr.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neilb@cse.unsw.edu.au \
    /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