linux-toradex.git/fs/nfs, branch v2.6.33.19

NFSv4.1: Ensure state manager thread dies on last umount

2011-05-09T23:04:40+00:00

commit 47c2199b6eb5fbe38ddb844db7cdbd914d304f9c upstream.

Currently, the state manager may continue to try recovering state forever
even after the last filesystem to reference that nfs_client has umounted.

Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

nfs: don't lose MS_SYNCHRONOUS on remount of noac mount

2011-05-09T23:04:40+00:00

commit 26c4c170731f00008f4317a2888a0a07ac99d90d upstream.

On a remount, the VFS layer will clear the MS_SYNCHRONOUS bit on the
assumption that the flags on the mount syscall will have it set if the
remounted fs is supposed to keep it.

In the case of "noac" though, MS_SYNCHRONOUS is implied. A remount of
such a mount will lose the MS_SYNCHRONOUS flag since "sync" isn't part
of the mount options.

Reported-by: Max Matveev 
Signed-off-by: Jeff Layton 
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

NFS: nfs_wcc_update_inode() should set nfsi->attr_gencount

2011-05-09T23:04:35+00:00

commit 27dc1cd3ad9300f81e1219e5fc305d91d85353f8 upstream.

If the call to nfs_wcc_update_inode() results in an attribute update, we
need to ensure that the inode's attr_gencount gets bumped too, otherwise
we are not protected against races with other GETATTR calls.

Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

NFS: fix the return value of nfs_file_fsync()

2011-03-21T19:45:07+00:00

commit 0702099bd86c33c2dcdbd3963433a61f3f503901 upstream.

By the commit af7fa16 2010-08-03 NFS: Fix up the fsync code
close(2) became returning the non-zero value even if it went well.
nfs_file_fsync() should return 0 when "status" is positive.

Signed-off-by: J. R. Okajima 
Signed-off-by: Trond Myklebust 
Signed-off-by: Tim Gardner 
Signed-off-by: Greg Kroah-Hartman

NFS: Fix "kernel BUG at fs/aio.c:554!"

2011-03-21T19:44:52+00:00

commit 839f7ad6932d95f4d5ae7267b95c574714ff3d5b upstream.

Nick Piggin reports:

> I'm getting use after frees in aio code in NFS
>
> [ 2703.396766] Call Trace:
> [ 2703.396858]  [] ? native_sched_clock+0x27/0x80
> [ 2703.396959]  [] ? put_lock_stats+0xe/0x40
> [ 2703.397058]  [] ? lock_release_holdtime+0xa8/0x140
> [ 2703.397159]  [] lock_acquire+0x95/0x1b0
> [ 2703.397260]  [] ? aio_put_req+0x2b/0x60
> [ 2703.397361]  [] ? get_parent_ip+0x11/0x50
> [ 2703.397464]  [] _raw_spin_lock_irq+0x41/0x80
> [ 2703.397564]  [] ? aio_put_req+0x2b/0x60
> [ 2703.397662]  [] aio_put_req+0x2b/0x60
> [ 2703.397761]  [] do_io_submit+0x2be/0x7c0
> [ 2703.397895]  [] sys_io_submit+0xb/0x10
> [ 2703.397995]  [] system_call_fastpath+0x16/0x1b
>
> Adding some tracing, it is due to nfs completing the request then
> returning something other than -EIOCBQUEUED, so aio.c
> also completes the request.

To address this, prevent the NFS direct I/O engine from completing
async iocbs when the forward path returns an error without starting
any I/O.

This fix appears to survive ^C during both "xfstest no. 208" and "fsx
-Z."

It's likely this bug has existed for a very long while, as we are seeing
very similar symptoms in OEL 5.  Copying stable.

Signed-off-by: Chuck Lever 
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

NFS: Fix fcntl F_GETLK not reporting some conflicts

2011-03-21T19:44:22+00:00

commit 21ac19d484a8ffb66f64487846c8d53afef04d2b upstream.

The commit 129a84de2347002f09721cda3155ccfd19fade40 (locks: fix F_GETLK
regression (failure to find conflicts)) fixed the posix_test_lock()
function by itself, however, its usage in NFS changed by the commit
9d6a8c5c213e34c475e72b245a8eb709258e968c (locks: give posix_test_lock
same interface as ->lock) remained broken - subsequent NFS-specific
locking code received F_UNLCK instead of the user-specified lock type.
To fix the problem, fl->fl_type needs to be saved before the
posix_test_lock() call and restored if no local conflicts were reported.

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=23892
Tested-by: Alexander Morozov 
Signed-off-by: Sergey Vlasov 
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

NFS: Fix panic after nfs_umount()

2011-03-21T19:44:21+00:00

commit 5b362ac3799ff4225c40935500f520cad4d7ed66 upstream.

After a few unsuccessful NFS mount attempts in which the client and
server cannot agree on an authentication flavor both support, the
client panics.  nfs_umount() is invoked in the kernel in this case.

Turns out nfs_umount()'s UMNT RPC invocation causes the RPC client to
write off the end of the rpc_clnt's iostat array.  This is because the
mount client's nrprocs field is initialized with the count of defined
procedures (two: MNT and UMNT), rather than the size of the client's
proc array (four).

The fix is to use the same initialization technique used by most other
upper layer clients in the kernel.

Introduced by commit 0b524123, which failed to update nrprocs when
support was added for UMNT in the kernel.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=24302
BugLink: http://bugs.launchpad.net/bugs/683938

Reported-by: Stefan Bader 
Tested-by: Stefan Bader 
Signed-off-by: Chuck Lever 
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

NFSv4: Ensure that /proc/self/mountinfo displays the minor version number

2010-08-02T17:26:30+00:00

commit 0be8189f2c87fcc747d6a4a657a0b6e2161b2318 upstream.

Currently, we do not display the minor version mount parameter in the
/proc mount info.

Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

NFSv4: Fix an embarassing typo in encode_attrs()

2010-08-02T17:26:30+00:00

commit d3f6baaa34c54040b3ef30950e59b54ac0624b21 upstream.

Apparently, we have never been able to set the atime correctly from the
NFSv4 client.

Reported-by: 小倉一夫 
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

NFS: rsize and wsize settings ignored on v4 mounts

2010-05-12T22:02:40+00:00

commit 356e76b855bdbfd8d1c5e75bcf0c6bf0dfe83496 upstream.

NFSv4 mounts ignore the rsize and wsize mount options, and always use
the default transfer size for both.  This seems to be because all
NFSv4 mounts are now cloned, and the cloning logic doesn't copy the
rsize and wsize settings from the parent nfs_server.

I tested Fedora's 2.6.32.11-99 and it seems to have this problem as
well, so I'm guessing that .33, .32, and perhaps older kernels have
this issue as well.

Signed-off-by: Chuck Lever 
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman