| commit | 1dfd89af8697a299e7982ae740d4695ecd917eef | |
| author | Trond Myklebust <Trond.Myklebust@netapp.com> | |
| Sun, 21 Apr 2013 22:01:06 +0000 (21 18:01 -0400) | ||
| committer | Trond Myklebust <Trond.Myklebust@netapp.com> | |
| Sun, 21 Apr 2013 22:08:42 +0000 (21 18:08 -0400) | ||
| tree | 5aa23c37416e71ef28c593bcf83bdaca9fdd0b7a | treesnapshot (tar.gz zip) |
| parent | 8e472f33b5ba742f9bfcf16f0328f5a7842b32d1 | commitdiff |
LOCKD: Ensure that nlmclnt_block resets block->b_status after a server reboot
After a server reboot, the reclaimer thread will recover all the existing
locks. For locks that are blocked, however, it will change the value
of block->b_status to nlm_lck_denied_grace_period in order to signal that
they need to wake up and resend the original blocking lock request.
Due to a bug, however, the block->b_status never gets reset after the
blocked locks have been woken up, and so the process goes into an
infinite loop of resends until the blocked lock is satisfied.
Reported-by: Marc Eshel <eshel@us.ibm.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: stable@vger.kernel.org
After a server reboot, the reclaimer thread will recover all the existing
locks. For locks that are blocked, however, it will change the value
of block->b_status to nlm_lck_denied_grace_period in order to signal that
they need to wake up and resend the original blocking lock request.
Due to a bug, however, the block->b_status never gets reset after the
blocked locks have been woken up, and so the process goes into an
infinite loop of resends until the blocked lock is satisfied.
Reported-by: Marc Eshel <eshel@us.ibm.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: stable@vger.kernel.org
| fs/lockd/clntlock.c | diffblobblamehistory | |
| fs/lockd/clntproc.c | diffblobblamehistory |