1. 30 1月, 2008 27 次提交
  2. 11 1月, 2008 1 次提交
  3. 03 1月, 2008 4 次提交
    • T
      NFSv4: Fix open_to_lock_owner sequenceid allocation... · e6e21970
      Trond Myklebust 提交于
      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: NTrond Myklebust <Trond.Myklebust@netapp.com>
      e6e21970
    • T
      NFSv4: nfs4_open_confirm must not set the open_owner as confirmed on error · bb22629e
      Trond Myklebust 提交于
      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: NTrond Myklebust <Trond.Myklebust@netapp.com>
      bb22629e
    • T
      NFSv4: Fix circular locking dependency in nfs4_kill_renewd · b274b48f
      Trond Myklebust 提交于
      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: [<c0223e53>]
      __cancel_work_timer+0x83/0x17f
      
      but task is already holding lock:
       (&clp->cl_sem){----}, at: [<f8879897>] 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){----}:
             [<c0230699>] __lock_acquire+0x9cc/0xb95
             [<c0230c39>] lock_acquire+0x5f/0x78
             [<c0397cb8>] down_read+0x3a/0x4c
             [<f88798e6>] nfs4_renew_state+0x1c/0x1b8 [nfs]
             [<c0223821>] run_workqueue+0xd9/0x1ac
             [<c0224220>] worker_thread+0x7a/0x86
             [<c0226b49>] kthread+0x3b/0x62
             [<c02033a3>] kernel_thread_helper+0x7/0x10
             [<ffffffff>] 0xffffffff
      
      -> #0 (&(&clp->cl_renewd)->work){--..}:
             [<c0230589>] __lock_acquire+0x8bc/0xb95
             [<c0230c39>] lock_acquire+0x5f/0x78
             [<c0223e87>] __cancel_work_timer+0xb7/0x17f
             [<c0223f5a>] cancel_delayed_work_sync+0xb/0xd
             [<f887989e>] nfs4_kill_renewd+0x1e/0x29 [nfs]
             [<f885a8f6>] nfs_free_client+0x37/0x9e [nfs]
             [<f885ab20>] nfs_put_client+0x5d/0x62 [nfs]
             [<f885ab9a>] nfs_free_server+0x75/0xae [nfs]
             [<f8862672>] nfs4_kill_super+0x27/0x2b [nfs]
             [<c0258aab>] deactivate_super+0x3f/0x51
             [<c0269668>] mntput_no_expire+0x42/0x67
             [<c025d0e4>] path_release_on_umount+0x15/0x18
             [<c0269d30>] sys_umount+0x1a3/0x1cb
             [<c0269d71>] sys_oldumount+0x19/0x1b
             [<c02026ca>] sysenter_past_esp+0x5f/0xa5
             [<ffffffff>] 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: NTrond Myklebust <Trond.Myklebust@netapp.com>
      b274b48f
    • T
      NFS: Fix a possible Oops in fs/nfs/super.c · e9cc6c23
      Trond Myklebust 提交于
      Sigh... commit 4584f520 (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: NTrond Myklebust <Trond.Myklebust@netapp.com>
      e9cc6c23
  4. 13 12月, 2007 2 次提交
    • T
      NFS: Fix an Oops in NFS unmount · a10db50a
      Trond Myklebust 提交于
      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: NTrond Myklebust <Trond.Myklebust@netapp.com>
      a10db50a
    • T
      Revert "NFS: Ensure we return zero if applications attempt to write zero bytes" · a5576cfa
      Trond Myklebust 提交于
      This reverts commit b9148c6b.
      
      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
      >> b9148c6b
      >> (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 <bunk@kernel.org>
      >>
      >> ---
      >> --- 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: NTrond Myklebust <Trond.Myklebust@netapp.com>
      a5576cfa
  5. 12 12月, 2007 2 次提交
    • T
      NFSv2/v3: Fix a memory leak when using -onolock · 5cef338b
      Trond Myklebust 提交于
      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: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Acked-by: NNeilBrown <neilb@suse.de>
      5cef338b
    • T
      NFS: Fix NFS mountpoint crossing... · 4584f520
      Trond Myklebust 提交于
      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: NTrond Myklebust <Trond.Myklebust@netapp.com>
      4584f520
  6. 27 11月, 2007 4 次提交