This is a note to let you know that I've just added the patch titled
nfsd4: don't close read-write opens too soon
to the 3.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
nfsd4-don-t-close-read-write-opens-too-soon.patch
and it can be found in the queue-3.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <[email protected]> know about it.
>From 0c7c3e67ab91ec6caa44bdf1fc89a48012ceb0c5 Mon Sep 17 00:00:00 2001
From: "J. Bruce Fields" <[email protected]>
Date: Thu, 28 Mar 2013 20:37:14 -0400
Subject: nfsd4: don't close read-write opens too soon
From: "J. Bruce Fields" <[email protected]>
commit 0c7c3e67ab91ec6caa44bdf1fc89a48012ceb0c5 upstream.
Don't actually close any opens until we don't need them at all.
This means being left with write access when it's not really necessary,
but that's better than putting a file that might still have posix locks
held on it, as we have been.
Reported-by: Toralf Förster <[email protected]>
Signed-off-by: J. Bruce Fields <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/nfsd/nfs4state.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -213,13 +213,7 @@ static void __nfs4_file_put_access(struc
{
if (atomic_dec_and_test(&fp->fi_access[oflag])) {
nfs4_file_put_fd(fp, oflag);
- /*
- * It's also safe to get rid of the RDWR open *if*
- * we no longer have need of the other kind of access
- * or if we already have the other kind of open:
- */
- if (fp->fi_fds[1-oflag]
- || atomic_read(&fp->fi_access[1 - oflag]) == 0)
+ if (atomic_read(&fp->fi_access[1 - oflag]) == 0)
nfs4_file_put_fd(fp, O_RDWR);
}
}
Patches currently in stable-queue which might be from [email protected] are
queue-3.4/nfsd-decode-and-send-64bit-time-values.patch
queue-3.4/nfsd4-don-t-close-read-write-opens-too-soon.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
