[PATCH 1/3] NFS: Fix READDIR oops with NFSv4 on RDMA

[Chuck Lever <chuck.lever@oracle.com>]

When starting the Connectathon basic tests on an NFSv4 RDMA
mount, I encountered this oops:

  BUG: unable to handle kernel NULL pointer dereference at (null)
  IP: [<ffffffff8129cc56>] memcpy+0x6/0x110
  PGD 2106cd067 PUD 20fef9067 PMD 0
  Oops: 0000 [#1] SMP

 ...

  [<ffffffffa05dc1b1>] ? xdr_inline_decode+0xb1/0x120 [sunrpc]
  [<ffffffffa071f19c>] nfs4_decode_dirent+0x4c/0x250 [nfsv4]
  [<ffffffff81178a02>] ? alloc_pages_current+0xb2/0x170
  [<ffffffffa06a1225>] nfs_readdir_page_filler+0xe5/0x2c0 [nfs]
  [<ffffffffa06a1622>] nfs_readdir_xdr_to_array+0x222/0x2e0 [nfs]
  [<ffffffffa06a1702>] nfs_readdir_filler+0x22/0x90 [nfs]
  [<ffffffff8112f975>] ? add_to_page_cache_lru+0x35/0x50
  [<ffffffff8112faee>] __read_cache_page+0x7e/0xe0
  [<ffffffffa06a16e0>] ? nfs_readdir_xdr_to_array+0x2e0/0x2e0 [nfs]
  [<ffffffffa06a16e0>] ? nfs_readdir_xdr_to_array+0x2e0/0x2e0 [nfs]
  [<ffffffff8113079c>] do_read_cache_page+0x3c/0x110
  [<ffffffff811308b9>] read_cache_page_async+0x19/0x20
  [<ffffffff811308ce>] read_cache_page+0xe/0x20
  [<ffffffffa06a1c1e>] nfs_readdir+0x14e/0x3d0 [nfs]
  [<ffffffffa071f150>] ? decode_pathconf+0x1c0/0x1c0 [nfsv4]
  [<ffffffff811a811d>] iterate_dir+0xad/0xd0
  [<ffffffff811a71ca>] ? do_fcntl+0x28a/0x370
  [<ffffffff811a82d5>] SyS_getdents+0x95/0x100
  [<ffffffff811a83e0>] ? SyS_old_readdir+0xa0/0xa0
  [<ffffffff815a7752>] system_call_fastpath+0x16/0x1b

The problem does not occur with NFSv3 over RDMA.

nfs4_decode_dirent() is confused because the xdr_buf's page
vector starts long after the first directory entry in the
server's reply.

Commit aa9c2669, "NFS: Client implementation of Labeled-NFS,"
is reported by git bisect as the first bad commit.

This commit changes the decode_readdir_maxsz macro.  This macro
controls where the generic XDR routines split incoming readdir
reply data between the head[0] buffer and the page cache.

Security labels go with each directory entry, thus they are
always stored in the page cache, not in the head buffer.  The
length of the reply that goes in head[0] should not change.

I've reverted the change to decode_readdir_maxsz.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=68371
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Cc: <stable@vger.kernel.org> # 3.11+
---

 fs/nfs/nfs4xdr.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/fs/nfs/nfs4xdr.c b/fs/nfs/nfs4xdr.c
index 5be2868..79e1d02 100644
--- a/fs/nfs/nfs4xdr.c
+++ b/fs/nfs/nfs4xdr.c
@@ -203,8 +203,7 @@ static int nfs4_stat_to_errno(int);
 				 2 + encode_verifier_maxsz + 5 + \
 				nfs4_label_maxsz)
 #define decode_readdir_maxsz	(op_decode_hdr_maxsz + \
-				 decode_verifier_maxsz + \
-				nfs4_label_maxsz + nfs4_fattr_maxsz)
+				 decode_verifier_maxsz)
 #define encode_readlink_maxsz	(op_encode_hdr_maxsz)
 #define decode_readlink_maxsz	(op_decode_hdr_maxsz + 1)
 #define encode_write_maxsz	(op_encode_hdr_maxsz + \