recipes-kernel/linux/linux-ti33x-psp-3.2/3.2.18/0022-NFSv4-Revalidate-uid-gid-after-open.patch

   1 From 28797e10f3879232042e0f636e6650a2b35912f6 Mon Sep 17 00:00:00 2001
   2 From: Jonathan Nieder <jrnieder@gmail.com>
   3 Date: Fri, 11 May 2012 04:20:20 -0500
   4 Subject: [PATCH 22/56] NFSv4: Revalidate uid/gid after open
   5
   6 This is a shorter (and more appropriate for stable kernels) analog to
   7 the following upstream commit:
   8
   9 commit 6926afd1925a54a13684ebe05987868890665e2b
  10 Author: Trond Myklebust <Trond.Myklebust@netapp.com>
  11 Date:   Sat Jan 7 13:22:46 2012 -0500
  12
  13     NFSv4: Save the owner/group name string when doing open
  14
  15     ...so that we can do the uid/gid mapping outside the asynchronous RPC
  16     context.
  17     This fixes a bug in the current NFSv4 atomic open code where the client
  18     isn't able to determine what the true uid/gid fields of the file are,
  19     (because the asynchronous nature of the OPEN call denies it the ability
  20     to do an upcall) and so fills them with default values, marking the
  21     inode as needing revalidation.
  22     Unfortunately, in some cases, the VFS will do some additional sanity
  23     checks on the file, and may override the server's decision to allow
  24     the open because it sees the wrong owner/group fields.
  25
  26     Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
  27
  28 Without this patch, logging into two different machines with home
  29 directories mounted over NFS4 and then running "vim" and typing ":q"
  30 in each reliably produces the following error on the second machine:
  31
  32         E137: Viminfo file is not writable: /users/system/rtheys/.viminfo
  33
  34 This regression was introduced by 80e52aced138 ("NFSv4: Don't do
  35 idmapper upcalls for asynchronous RPC calls", merged during the 2.6.32
  36 cycle) --- after the OPEN call, .viminfo has the default values for
  37 st_uid and st_gid (0xfffffffe) cached because we do not want to let
  38 rpciod wait for an idmapper upcall to fill them in.
  39
  40 The fix used in mainline is to save the owner and group as strings and
  41 perform the upcall in _nfs4_proc_open outside the rpciod context,
  42 which takes about 600 lines.  For stable, we can do something similar
  43 with a one-liner: make open check for the stale fields and make a
  44 (synchronous) GETATTR call to fill them when needed.
  45
  46 Trond dictated the patch, I typed it in, and Rik tested it.
  47
  48 Addresses http://bugs.debian.org/659111 and
  49           https://bugzilla.redhat.com/789298
  50
  51 Reported-by: Rik Theys <Rik.Theys@esat.kuleuven.be>
  52 Explained-by: David Flyn <davidf@rd.bbc.co.uk>
  53 Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
  54 Tested-by: Rik Theys <Rik.Theys@esat.kuleuven.be>
  55 Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
  56 ---
  57  fs/nfs/nfs4proc.c |    1 +
  58  1 files changed, 1 insertions(+), 0 deletions(-)
  59
  60 diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
  61 index 51f6a40..bab7c58 100644
  62 --- a/fs/nfs/nfs4proc.c
  63 +++ b/fs/nfs/nfs4proc.c
  64 @@ -1802,6 +1802,7 @@ static int _nfs4_do_open(struct inode *dir, struct dentry *dentry, fmode_t fmode
  65                         nfs_setattr_update_inode(state->inode, sattr);
  66                 nfs_post_op_update_inode(state->inode, opendata->o_res.f_attr);
  67         }
  68 +       nfs_revalidate_inode(server, state->inode);
  69         nfs4_opendata_put(opendata);
  70         nfs4_put_state_owner(sp);
  71         *res = state;
  72 --
  73 1.7.7.6
  74