From: Fabio Olive Leite <fleite@redhat.com>
To: nfs@lists.sourceforge.net
Subject: [PATCH] Stale NFS negative dentries caused by u32 jiffy wrap
Date: Tue, 24 Apr 2007 13:26:45 -0300 [thread overview]
Message-ID: <20070424162645.GD10449@sleipnir.redhat.com> (raw)
Hi nfs@,
This patch solves an issue found on 32bit architectures, where jiffies
wrap every 50 days. Since many NFS structures are very long lived and
the code uses jiffies everywhere for timestamp comparisons, there are
many places where old data can be considered newer than something
fresh from the server. This one deals with negative dentries, and I'd
like to have it discussed in the list for sanity checking.
In 32bit architectures the NFS code uses 32bit jiffies for structures
that can very easily remain allocated for several u32 jiffy wraps,
fooling tests made only with time_after[_eq]. One such case is for
negative dentries, that given the correct timing can be considered valid
even after changing their parent dir's attributes.
=
This patch addresses that by using another unused struct dentry field to
store the higher part of the u64 jiffies. It has more comments than code
because the issue is subtle, and is made conditional on long being a
32bit quantity (64bit arches won't exhibit this behavior).
diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
index cd34697..a21fb87 100644
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@ -644,11 +644,26 @@ static int nfs_check_verifier(struct inode *dir, stru=
ct dentry *dentry)
if ((NFS_I(dir)->cache_validity & NFS_INO_INVALID_ATTR) !=3D 0
|| nfs_attribute_timeout(dir))
return 0;
+#if (BITS_PER_LONG < 64)
+ /* In 32bit architectures, also check the cached higher bits of
+ * jiffies64. NFS dentries can sit idle across two sign flips of
+ * 32bit jiffies and fool time_after[_eq].
+ */
+ if ((u32)(dentry->d_cookie) !=3D (u32)(get_jiffies_64() >> 32))
+ return 0;
+#endif
return nfs_verify_change_attribute(dir, (unsigned long)dentry->d_fsdata);
}
=
static inline void nfs_set_verifier(struct dentry * dentry, unsigned long =
verf)
{
+#if (BITS_PER_LONG < 64)
+ /* In 32bit architectures we can have problems with dentries that sit
+ * idle during two flips of the MSB of the u32 jiffies, so we keep
+ * track of the higher bits in d_cookie.
+ */
+ (u32)(dentry->d_cookie) =3D (u32)(get_jiffies_64() >> 32);
+#endif
dentry->d_fsdata =3D (void *)verf;
}
=
@@ -755,8 +770,17 @@ static int nfs_lookup_revalidate(struct dentry * dentr=
y, struct nameidata *nd)
inode =3D dentry->d_inode;
=
if (!inode) {
- if (nfs_neg_need_reval(dir, dentry, nd))
+ if (nfs_neg_need_reval(dir, dentry, nd)) {
+#if (BITS_PER_LONG < 64)
+ dfprintk(VFS, "nfs_lookup_revalidate: expiring neg dentry for %s\n",
+ dentry->d_name.name);
+ dfprintk(VFS, " d_cookie %08x high_jiffies %08x\n",
+ dentry->d_cookie, (u32)(get_jiffies_64() >> 32));
+ dfprintk(VFS, " d_fsdata %08x cache_change_attribute %08x\n",
+ dentry->d_fsdata, NFS_I(dir)->cache_change_attribute);
+#endif
goto out_bad;
+ }
goto out_valid;
}
=
Cheers,
F=E1bio
-- =
ex sed lex awk yacc, e pluribus unix, amem
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next reply other threads:[~2007-04-24 16:26 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-24 16:26 Fabio Olive Leite [this message]
2007-04-26 3:24 ` [PATCH] Stale NFS negative dentries caused by u32 jiffy wrap Fabio Olive Leite
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=20070424162645.GD10449@sleipnir.redhat.com \
--to=fleite@redhat.com \
--cc=nfs@lists.sourceforge.net \
/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