diff options
author | Trond Myklebust <Trond.Myklebust@netapp.com> | 2013-02-04 20:17:49 -0500 |
---|---|---|
committer | Trond Myklebust <Trond.Myklebust@netapp.com> | 2013-02-11 15:33:12 -0500 |
commit | 9a99af494bd7141d567d00b5ef94b141821e158c (patch) | |
tree | 1ca9c1ea6536b5384012e50d889eeb7753460244 /fs/nfs/delegation.h | |
parent | c137afabe330f64eddcd4dd281258807e27fd430 (diff) | |
download | linux-stable-9a99af494bd7141d567d00b5ef94b141821e158c.tar.gz linux-stable-9a99af494bd7141d567d00b5ef94b141821e158c.tar.bz2 linux-stable-9a99af494bd7141d567d00b5ef94b141821e158c.zip |
NFSv4.1: Prevent deadlocks between state recovery and file locking
We currently have a deadlock in which the state recovery thread
ends up blocking due to one of the locks which it is trying to
recover holding the nfs_inode->rwsem.
The situation is as follows: the state recovery thread is
scheduled in order to recover from a reboot. It immediately
drains the session, forcing all ordinary NFSv4.1 calls to
nfs41_setup_sequence() to be put to sleep. This includes the
file locking process that holds the nfs_inode->rwsem.
When the thread gets to nfs4_reclaim_locks(), it tries to
grab a write lock on nfs_inode->rwsem, and boom...
Fix is to have the lock drop the nfs_inode->rwsem while it is
doing RPC calls. We use a sequence lock in order to signal to
the locking process whether or not a state recovery thread has
run on that inode, in which case it should retry the lock.
Reported-by: Andy Adamson <andros@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Diffstat (limited to 'fs/nfs/delegation.h')
0 files changed, 0 insertions, 0 deletions