linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Trond Myklebust <Trond.Myklebust@netapp.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org,
	David Howells <dhowells@redhat.com>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: [GIT PULL] Please pull NFS client bugfixes...
Date: Thu, 06 May 2010 22:22:43 -0400	[thread overview]
Message-ID: <1273198963.2661.12.camel@localhost.localdomain> (raw)

Hi Linus,

Please pull from the "bugfixes" branch of the repository at

   git pull git://git.linux-nfs.org/projects/trondmy/nfs-2.6.git bugfixes

This will update the following files through the appended changesets.

  Cheers,
    Trond

----
 fs/nfs/delegation.c |   86 ++++++++++++++++++++++++++++++---------------------
 1 files changed, 51 insertions(+), 35 deletions(-)

commit 17d2c0a0c4d4e074f0a2a5c0090ff6d88f5e1d44
Author: David Howells <dhowells@redhat.com>
Date:   Sat May 1 12:37:18 2010 -0400

    NFS: Fix RCU issues in the NFSv4 delegation code
    
    Fix a number of RCU issues in the NFSv4 delegation code.
    
     (1) delegation->cred doesn't need to be RCU protected as it's essentially an
         invariant refcounted structure.
    
         By the time we get to nfs_free_delegation(), the delegation is being
         released, so no one else should be attempting to use the saved
         credentials, and they can be cleared.
    
         However, since the list of delegations could still be under traversal at
         this point by such as nfs_client_return_marked_delegations(), the cred
         should be released in nfs_do_free_delegation() rather than in
         nfs_free_delegation().  Simply using rcu_assign_pointer() to clear it is
         insufficient as that doesn't stop the cred from being destroyed, and nor
         does calling put_rpccred() after call_rcu(), given that the latter is
         asynchronous.
    
     (2) nfs_detach_delegation_locked() and nfs_inode_set_delegation() should use
         rcu_derefence_protected() because they can only be called if
         nfs_client::cl_lock is held, and that guards against anyone changing
         nfsi->delegation under it.  Furthermore, the barrier imposed by
         rcu_dereference() is superfluous, given that the spin_lock() is also a
         barrier.
    
     (3) nfs_detach_delegation_locked() is now passed a pointer to the nfs_client
         struct so that it can issue lockdep advice based on clp->cl_lock for (2).
    
     (4) nfs_inode_return_delegation_noreclaim() and nfs_inode_return_delegation()
         should use rcu_access_pointer() outside the spinlocked region as they
         merely examine the pointer and don't follow it, thus rendering unnecessary
         the need to impose a partial ordering over the one item of interest.
    
         These result in an RCU warning like the following:
    
    [ INFO: suspicious rcu_dereference_check() usage. ]
    ---------------------------------------------------
    fs/nfs/delegation.c:332 invoked rcu_dereference_check() without protection!
    
    other info that might help us debug this:
    
    rcu_scheduler_active = 1, debug_locks = 0
    2 locks held by mount.nfs4/2281:
     #0:  (&type->s_umount_key#34){+.+...}, at: [<ffffffff810b25b4>] deactivate_super+0x60/0x80
     #1:  (iprune_sem){+.+...}, at: [<ffffffff810c332a>] invalidate_inodes+0x39/0x13a
    
    stack backtrace:
    Pid: 2281, comm: mount.nfs4 Not tainted 2.6.34-rc1-cachefs #110
    Call Trace:
     [<ffffffff8105149f>] lockdep_rcu_dereference+0xaa/0xb2
     [<ffffffffa00b4591>] nfs_inode_return_delegation_noreclaim+0x5b/0xa0 [nfs]
     [<ffffffffa0095d63>] nfs4_clear_inode+0x11/0x1e [nfs]
     [<ffffffff810c2d92>] clear_inode+0x9e/0xf8
     [<ffffffff810c3028>] dispose_list+0x67/0x10e
     [<ffffffff810c340d>] invalidate_inodes+0x11c/0x13a
     [<ffffffff810b1dc1>] generic_shutdown_super+0x42/0xf4
     [<ffffffff810b1ebe>] kill_anon_super+0x11/0x4f
     [<ffffffffa009893c>] nfs4_kill_super+0x3f/0x72 [nfs]
     [<ffffffff810b25bc>] deactivate_super+0x68/0x80
     [<ffffffff810c6744>] mntput_no_expire+0xbb/0xf8
     [<ffffffff810c681b>] release_mounts+0x9a/0xb0
     [<ffffffff810c689b>] put_mnt_ns+0x6a/0x79
     [<ffffffffa00983a1>] nfs_follow_remote_path+0x5a/0x146 [nfs]
     [<ffffffffa0098334>] ? nfs_do_root_mount+0x82/0x95 [nfs]
     [<ffffffffa00985a9>] nfs4_try_mount+0x75/0xaf [nfs]
     [<ffffffffa0098874>] nfs4_get_sb+0x291/0x31a [nfs]
     [<ffffffff810b2059>] vfs_kern_mount+0xb8/0x177
     [<ffffffff810b2176>] do_kern_mount+0x48/0xe8
     [<ffffffff810c810b>] do_mount+0x782/0x7f9
     [<ffffffff810c8205>] sys_mount+0x83/0xbe
     [<ffffffff81001eeb>] system_call_fastpath+0x16/0x1b
    
    Also on:
    
    fs/nfs/delegation.c:215 invoked rcu_dereference_check() without protection!
     [<ffffffff8105149f>] lockdep_rcu_dereference+0xaa/0xb2
     [<ffffffffa00b4223>] nfs_inode_set_delegation+0xfe/0x219 [nfs]
     [<ffffffffa00a9c6f>] nfs4_opendata_to_nfs4_state+0x2c2/0x30d [nfs]
     [<ffffffffa00aa15d>] nfs4_do_open+0x2a6/0x3a6 [nfs]
     ...
    
    And:
    
    fs/nfs/delegation.c:40 invoked rcu_dereference_check() without protection!
     [<ffffffff8105149f>] lockdep_rcu_dereference+0xaa/0xb2
     [<ffffffffa00b3bef>] nfs_free_delegation+0x3d/0x6e [nfs]
     [<ffffffffa00b3e71>] nfs_do_return_delegation+0x26/0x30 [nfs]
     [<ffffffffa00b406a>] __nfs_inode_return_delegation+0x1ef/0x1fe [nfs]
     [<ffffffffa00b448a>] nfs_client_return_marked_delegations+0xc9/0x124 [nfs]
     ...
    
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 8f649c376254755f2261a693b3d48d09126218dc
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Sat May 1 12:36:18 2010 -0400

    NFSv4: Fix the locking in nfs_inode_reclaim_delegation()
    
    Ensure that we correctly rcu-dereference the delegation itself, and that we
    protect against removal while we're changing the contents.
    
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>



             reply	other threads:[~2010-05-07  2:22 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-07  2:22 Trond Myklebust [this message]
  -- strict thread matches above, loose matches on Subject: below --
2023-01-07 18:09 [GIT PULL] Please pull NFS client bugfixes Trond Myklebust
2023-01-07 18:43 ` pr-tracker-bot
2022-09-12 21:34 Trond Myklebust
2022-09-12 21:57 ` pr-tracker-bot
2021-01-12 14:31 Trond Myklebust
2021-01-12 18:00 ` pr-tracker-bot
2020-09-28 17:27 Trond Myklebust
2020-09-28 18:16 ` pr-tracker-bot
2020-05-15 21:00 Trond Myklebust
2020-05-15 21:10 ` pr-tracker-bot
2020-05-02 13:35 Trond Myklebust
2020-05-02 18:45 ` pr-tracker-bot
2019-08-27 19:26 Trond Myklebust
2019-08-27 20:55 ` pr-tracker-bot
2019-08-08 21:26 Trond Myklebust
2019-08-09  1:30 ` pr-tracker-bot
2019-04-13 14:56 Trond Myklebust
2019-04-13 22:00 ` pr-tracker-bot
2018-12-19 16:49 Trond Myklebust
2018-12-20  2:50 ` pr-tracker-bot
2018-12-20 15:23 ` Geert Uytterhoeven
2018-03-12 17:29 Trond Myklebust
2018-02-25 17:02 Trond Myklebust
2017-01-28 17:04 Trond Myklebust
2017-01-16 20:14 Trond Myklebust
2016-10-21 20:30 Anna Schumaker
2015-10-07  2:52 Trond Myklebust
2015-09-25 15:14 Trond Myklebust
2015-07-28 16:03 Trond Myklebust
2015-03-06  3:46 Trond Myklebust
2015-01-29 21:37 Trond Myklebust
2015-01-16 14:35 Trond Myklebust
2014-11-14 23:04 Trond Myklebust
2014-09-19 19:32 Trond Myklebust
2014-01-31 21:41 Trond Myklebust
2013-12-05 17:20 Trond Myklebust
2013-11-16 21:09 Myklebust, Trond
2013-09-30 22:02 Myklebust, Trond
2013-05-26 19:29 Myklebust, Trond
2013-03-26 18:26 Myklebust, Trond
2013-03-03  0:08 Myklebust, Trond
2013-02-21  3:38 Myklebust, Trond
2013-01-07 15:45 Myklebust, Trond
2012-11-03 19:48 Myklebust, Trond
2012-10-22 17:42 Myklebust, Trond
2012-09-12 19:19 Myklebust, Trond
2012-07-13 15:14 Myklebust, Trond
2012-05-02  3:57 Myklebust, Trond
2012-04-24 20:18 [GIT PULL] please " Myklebust, Trond
2011-12-20  6:15 [GIT PULL] Please " Trond Myklebust
2011-11-22 11:50 Trond Myklebust
2011-08-19  1:05 Trond Myklebust
2011-07-12 23:30 Trond Myklebust
2011-05-13 20:23 Trond Myklebust
2011-04-08 18:40 [GIT PULL] please " Trond Myklebust
2011-03-14 18:09 [GIT PULL] Please " Trond Myklebust
2010-11-26 18:56 Trond Myklebust
2010-05-26 19:42 Trond Myklebust
2010-04-29 16:48 Trond Myklebust
2010-03-23 17:00 Trond Myklebust
2010-03-17 21:55 Trond Myklebust
2010-02-04 19:10 Trond Myklebust
2010-01-07 20:29 Trond Myklebust
2009-05-26 19:06 Trond Myklebust

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1273198963.2661.12.camel@localhost.localdomain \
    --to=trond.myklebust@netapp.com \
    --cc=dhowells@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).