This is a note to let you know that I've just added the patch titled
NFSv4: Revalidate uid/gid after open
to the 3.0-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:
nfsv4-revalidate-uid-gid-after-open.patch
and it can be found in the queue-3.0 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <[email protected]> know about it.
>From [email protected] Fri May 18 12:31:07 2012
From: Jonathan Nieder <[email protected]>
Date: Fri, 11 May 2012 04:20:20 -0500
Subject: NFSv4: Revalidate uid/gid after open
To: [email protected]
Cc: Rik Theys <[email protected]>, Trond Myklebust
<[email protected]>, [email protected], David Flyn
<[email protected]>, Jeff Layton <[email protected]>, [email protected]
Message-ID: <20120511092020.GD5733@burratino>
Content-Disposition: inline
From: Jonathan Nieder <[email protected]>
This is a shorter (and more appropriate for stable kernels) analog to
the following upstream commit:
commit 6926afd1925a54a13684ebe05987868890665e2b
Author: Trond Myklebust <[email protected]>
Date: Sat Jan 7 13:22:46 2012 -0500
NFSv4: Save the owner/group name string when doing open
...so that we can do the uid/gid mapping outside the asynchronous RPC
context.
This fixes a bug in the current NFSv4 atomic open code where the client
isn't able to determine what the true uid/gid fields of the file are,
(because the asynchronous nature of the OPEN call denies it the ability
to do an upcall) and so fills them with default values, marking the
inode as needing revalidation.
Unfortunately, in some cases, the VFS will do some additional sanity
checks on the file, and may override the server's decision to allow
the open because it sees the wrong owner/group fields.
Signed-off-by: Trond Myklebust <[email protected]>
Without this patch, logging into two different machines with home
directories mounted over NFS4 and then running "vim" and typing ":q"
in each reliably produces the following error on the second machine:
E137: Viminfo file is not writable: /users/system/rtheys/.viminfo
This regression was introduced by 80e52aced138 ("NFSv4: Don't do
idmapper upcalls for asynchronous RPC calls", merged during the 2.6.32
cycle) --- after the OPEN call, .viminfo has the default values for
st_uid and st_gid (0xfffffffe) cached because we do not want to let
rpciod wait for an idmapper upcall to fill them in.
The fix used in mainline is to save the owner and group as strings and
perform the upcall in _nfs4_proc_open outside the rpciod context,
which takes about 600 lines. For stable, we can do something similar
with a one-liner: make open check for the stale fields and make a
(synchronous) GETATTR call to fill them when needed.
Trond dictated the patch, I typed it in, and Rik tested it.
Addresses http://bugs.debian.org/659111 and
https://bugzilla.redhat.com/789298
Reported-by: Rik Theys <[email protected]>
Explained-by: David Flyn <[email protected]>
Signed-off-by: Jonathan Nieder <[email protected]>
Tested-by: Rik Theys <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/nfs/nfs4proc.c | 1 +
1 file changed, 1 insertion(+)
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -1771,6 +1771,7 @@ static int _nfs4_do_open(struct inode *d
nfs_setattr_update_inode(state->inode, sattr);
nfs_post_op_update_inode(state->inode, opendata->o_res.f_attr);
}
+ nfs_revalidate_inode(server, state->inode);
nfs4_opendata_put(opendata);
nfs4_put_state_owner(sp);
*res = state;
Patches currently in stable-queue which might be from [email protected] are
queue-3.0/nfsv4-revalidate-uid-gid-after-open.patch
queue-3.0/cdc_ether-ignore-bogus-union-descriptor-for-rndis-devices.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
