linux/fs/nfsd, branch v3.4.70

nfsd4: fix decoding of compounds across page boundaries

2013-07-13T18:03:41Z

commit 247500820ebd02ad87525db5d9b199e5b66f6636 upstream. A freebsd NFSv4.0 client was getting rare IO errors expanding a tarball. A network trace showed the server returning BAD_XDR on the final getattr of a getattr+write+getattr compound. The final getattr started on a page boundary. I believe the Linux client ignores errors on the post-write getattr, and that that's why we haven't seen this before. Reported-by: Rick Macklem Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman

nfsd4: don't allow owner override on 4.1 CLAIM_FH opens

2013-05-19T17:54:38Z

commit 9f415eb25574db4b73a9a712a4438e41dc284922 upstream. The Linux client is using CLAIM_FH to implement regular opens, not just recovery cases, so it depends on the server to check permissions correctly. Therefore the owner override, which may make sense in the delegation recovery case, isn't right in the CLAIM_FH case. Symptoms: on a client with 49f9a0fafd844c32f2abada047c0b9a5ba0d6255 "NFSv4.1: Enable open-by-filehandle", Bryan noticed this: touch test.txt chmod 000 test.txt echo test > test.txt succeeding. Reported-by: Bryan Schumaker Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman

nfsd: Decode and send 64bit time values

2013-05-08T02:51:56Z

commit bf8d909705e9d9bac31d9b8eac6734d2b51332a7 upstream. The seconds field of an nfstime4 structure is 64bit, but we are assuming that the first 32bits are zero-filled. So if the client tries to set atime to a value before the epoch (touch -t 196001010101), then the server will save the wrong value on disk. Signed-off-by: Bryan Schumaker Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman

nfsd4: don't close read-write opens too soon

2013-05-08T02:51:56Z

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 Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman

nfsd4: reject "negative" acl lengths

2013-04-05T17:04:35Z

commit 64a817cfbded8674f345d1117b117f942a351a69 upstream. Since we only enforce an upper bound, not a lower bound, a "negative" length can get through here. The symptom seen was a warning when we attempt to a kmalloc with an excessive size. Reported-by: Toralf Förster Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman

nfsd: Fix memleak

2013-03-03T22:06:42Z

commit 2d32b29a1c2830f7c42caa8258c714acd983961f upstream. When free nfs-client, it must free the ->cl_stateids. Signed-off-by: Jianpeng Ma Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman

nfsd: avoid permission checks on EXCLUSIVE_CREATE replay

2013-01-11T17:06:55Z

commit 7007c90fb9fef593b4aeaeee57e6a6754276c97c upstream. With NFSv4, if we create a file then open it we explicit avoid checking the permissions on the file during the open because the fact that we created it ensures we should be allow to open it (the create and the open should appear to be a single operation). However if the reply to an EXCLUSIVE create gets lots and the client resends the create, the current code will perform the permission check - because it doesn't realise that it did the open already.. This patch should fix this. Note that I haven't actually seen this cause a problem. I was just looking at the code trying to figure out a different EXCLUSIVE open related issue, and this looked wrong. (Fix confirmed with pynfs 4.0 test OPEN4--bfields) Signed-off-by: NeilBrown [bfields: use OWNER_OVERRIDE and update for 4.1] Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman

nfsd4: fix oops on unusual readlike compound

2013-01-11T17:06:55Z

commit d5f50b0c290431c65377c4afa1c764e2c3fe5305 upstream. If the argument and reply together exceed the maximum payload size, then a reply with a read-like operation can overlow the rq_pages array. Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman

nfsd: fix v4 reply caching

2013-01-11T17:06:55Z

commit 57d276d71aef7d8305ff002a070cb98deb2edced upstream. Very embarassing: 1091006c5eb15cba56785bd5b498a8d0b9546903 "nfsd: turn on reply cache for NFSv4" missed a line, effectively leaving the reply cache off in the v4 case. I thought I'd tested that, but I guess not. This time, wrote a pynfs test to confirm it works. Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman

nfs: fix wrong object type in lockowner_slab

2013-01-11T17:06:55Z

commit 3c40794b2dd0f355ef4e6bf8d85af5dcd7da7ece upstream. The object type in the cache of lockowner_slab is wrong, and it is better to fix it. Signed-off-by: Yanchuan Nian Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman