litmus2008.git/fs/nfs, branch master

NFSv4: Give the lock stateid its own sequence queue

2008-01-10T21:35:32+00:00

Sharing the open sequence queue causes a deadlock when we try to take
both a lock sequence id and and open sequence id.

This fixes the regression reported by Dimitri Puzin and Jeff Garzik: See

	http://bugzilla.kernel.org/show_bug.cgi?id=9712

for details.

Reported-and-tested-by: Dimitri Puzin 
Signed-off-by: Trond Myklebust 
Tested-by: Jeff Garzik 
Signed-off-by: Linus Torvalds

NFSv4: Fix open_to_lock_owner sequenceid allocation...

2008-01-03T14:37:17+00:00

NFSv4 file locking is currently completely broken since it doesn't respect
the OPEN sequencing when it is given an unconfirmed lock_owner and needs to
do an open_to_lock_owner. Worse: it breaks the sunrpc rules by doing a
GFP_KERNEL allocation inside an rpciod callback.

Fix is to preallocate the open seqid structure in nfs4_alloc_lockdata if we
see that the lock_owner is unconfirmed.
Then, in nfs4_lock_prepare() we wait for either the open_seqid, if
the lock_owner is still unconfirmed, or else fall back to waiting on the
standard lock_seqid.

Signed-off-by: Trond Myklebust

NFSv4: nfs4_open_confirm must not set the open_owner as confirmed on error

2008-01-03T14:37:17+00:00

RFC3530 states that the open_owner is confirmed if and only if the client
sends an OPEN_CONFIRM request with the appropriate sequence id and stateid
within the lease period.

Signed-off-by: Trond Myklebust

NFSv4: Fix circular locking dependency in nfs4_kill_renewd

2008-01-03T14:37:16+00:00

Erez Zadok reports:

=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.24-rc6-unionfs2 #80
-------------------------------------------------------
umount.nfs4/4017 is trying to acquire lock:
 (&(&clp->cl_renewd)->work){--..}, at: []
__cancel_work_timer+0x83/0x17f

but task is already holding lock:
 (&clp->cl_sem){----}, at: [] nfs4_kill_renewd+0x17/0x29 [nfs]

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 (&clp->cl_sem){----}:
       [] __lock_acquire+0x9cc/0xb95
       [] lock_acquire+0x5f/0x78
       [] down_read+0x3a/0x4c
       [] nfs4_renew_state+0x1c/0x1b8 [nfs]
       [] run_workqueue+0xd9/0x1ac
       [] worker_thread+0x7a/0x86
       [] kthread+0x3b/0x62
       [] kernel_thread_helper+0x7/0x10
       [] 0xffffffff

-> #0 (&(&clp->cl_renewd)->work){--..}:
       [] __lock_acquire+0x8bc/0xb95
       [] lock_acquire+0x5f/0x78
       [] __cancel_work_timer+0xb7/0x17f
       [] cancel_delayed_work_sync+0xb/0xd
       [] nfs4_kill_renewd+0x1e/0x29 [nfs]
       [] nfs_free_client+0x37/0x9e [nfs]
       [] nfs_put_client+0x5d/0x62 [nfs]
       [] nfs_free_server+0x75/0xae [nfs]
       [] nfs4_kill_super+0x27/0x2b [nfs]
       [] deactivate_super+0x3f/0x51
       [] mntput_no_expire+0x42/0x67
       [] path_release_on_umount+0x15/0x18
       [] sys_umount+0x1a3/0x1cb
       [] sys_oldumount+0x19/0x1b
       [] sysenter_past_esp+0x5f/0xa5
       [] 0xffffffff

Looking at the code, it would seem that taking the clp->cl_sem in
nfs4_kill_renewd is completely redundant, since we're already guaranteed to
have exclusive access to the nfs_client (we're shutting down).

Signed-off-by: Trond Myklebust

NFS: Fix a possible Oops in fs/nfs/super.c

2008-01-03T14:37:11+00:00

Sigh... commit 4584f520e1f773082ef44ff4f8969a5d992b16ec (NFS: Fix NFS
mountpoint crossing...) had a slight flaw: server can be NULL if sget()
returned an existing superblock.

Fix the fix by dereferencing s->s_fs_info.

Thanks to Coverity/Adrian Bunk and Frank Filz for spotting the bug.
(See http://bugzilla.kernel.org/show_bug.cgi?id=9647)

Also add in the same namespace Oops fix for NFSv4 in both the mountpoint
crossing case, and the referral case.

Signed-off-by: Trond Myklebust

NFS: Fix an Oops in NFS unmount

2007-12-12T16:12:15+00:00

Ensure that the dummy 'root dentry' is invisible to d_find_alias(). If not,
then it may be spliced into the tree if a parent directory from the same
filesystem gets mounted at a later time.

Signed-off-by: Trond Myklebust

Revert "NFS: Ensure we return zero if applications attempt to write zero bytes"

2007-12-12T16:08:33+00:00

This reverts commit b9148c6b80d802dbc2a7530b29915a80432e50c7.

On Wed, 12 Dec 2007 10:57:30 -0500, Chuck Lever wrote
> commit b9148c6b should be reverted.  It was recently forward-ported
> from some years-old patches, and is clearly not needed now.
>
> On Dec 11, 2007, at 5:21 PM, Adrian Bunk wrote:
>
>> This code became dead after commit
>> b9148c6b80d802dbc2a7530b29915a80432e50c7
>> (which BTW doesn't seem to have changed any behaviour) and can
>> therefore
>> be removed.
>>
>> Spotted by the Coverity checker.
>>
>> Signed-off-by: Adrian Bunk 
>>
>> ---
>> --- linux-2.6/fs/nfs/direct.c.old     2007-12-02 21:54:53.000000000 +0100
>> +++ linux-2.6/fs/nfs/direct.c 2007-12-02 21:55:10.000000000 +0100
>> @@ -897,15 +897,12 @@ ssize_t nfs_file_direct_write(struct kio
>>       if (!count)
>>               goto out;       /* return 0 */
>>
>>       retval = -EINVAL;
>>       if ((ssize_t) count < 0)
>>               goto out;
>> -     retval = 0;
>> -     if (!count)
>> -             goto out;
>>
>>       retval = nfs_sync_mapping(mapping);
>>       if (retval)
>>               goto out;
>>
>>       retval = nfs_direct_write(iocb, iov, nr_segs, pos, count);
>>

Signed-off-by: Trond Myklebust

NFSv2/v3: Fix a memory leak when using -onolock

2007-12-12T03:01:56+00:00

Neil Brown said:
> Hi Trond,
> 
> We found that a machine which made moderately heavy use of
> 'automount' was leaking some nfs data structures - particularly the
> 4K allocated by rpc_alloc_iostats.
> It turns out that this only happens with filesystems with -onolock
> set.

> The problem is that if NFS_MOUNT_NONLM is set, nfs_start_lockd doesn't
> set server->destroy, so when the filesystem is unmounted, the
> ->client_acl is not shutdown, and so several resources are still
> held.  Multiple mount/umount cycles will slowly eat away memory
> several pages at a time.

Signed-off-by: Trond Myklebust 
Acked-by: NeilBrown

NFS: Fix NFS mountpoint crossing...

2007-12-12T00:01:45+00:00

The check that was added to nfs_xdev_get_sb() to work around broken
servers, works fine for NFSv2, but causes mountpoint crossing on NFSv3 to
always return ESTALE.

Signed-off-by: Trond Myklebust

NFS: Clean up new multi-segment direct I/O changes

2007-11-26T21:32:40+00:00

Simplify calling sequence of nfs_direct_{read,write}_schedule(), and
rename them to reflect their new role.

Signed-off-by: Chuck Lever 
Signed-off-by: Trond Myklebust