This patch is fixing the current the callback handling if a nfs async lock request signaled if fl_lmops is set.
When using `stress-ng --fcntl 32` on the kernel log there are several messages like:
[11185.123533] dlm: dlm_plock_callback: vfs lock error 5d5127 file 000000002dd10f4d fl 000000007d13afae [11185.127135] dlm: dlm_plock_callback: vfs lock error 5d5127 file 000000002dd10f4d fl 00000000a6046fa0 [11185.142668] dlm: dlm_plock_callback: vfs lock error 5d5127 file 000000002dd10f4d fl 000000001d13dfa5
The commit 40595cdc93ed ("nfs: block notification on fs with its own ->lock") removed the FL_SLEEP handling if the filesystem implements its own ->lock. The strategy is now that the most clients polling blocked requests by using trylock functionality.
Before commit 40595cdc93ed ("nfs: block notification on fs with its own ->lock") FL_SLEEP was used even with an own ->lock() callback. The fs implementation needed to handle it to make a difference between a blocking and non-blocking lock request. This was never being implemented in such way in DLM plock handling. Every lock request doesn't matter if it was a blocking request or not was handled as a non-blocking lock request.
This patch fixes the behaviour until commit 40595cdc93ed ("nfs: block notification on fs with its own ->lock"), but it was probably broken long time before.
Fixes: 40595cdc93ed ("nfs: block notification on fs with its own ->lock") Cc: stable@vger.kernel.org Signed-off-by: Alexander Aring aahringo@redhat.com --- changes since v2: - rephrase commit msg - add cc stable
fs/dlm/plock.c | 22 +--------------------- 1 file changed, 1 insertion(+), 21 deletions(-)
diff --git a/fs/dlm/plock.c b/fs/dlm/plock.c index 70a4752ed913..6f0ecb2176b0 100644 --- a/fs/dlm/plock.c +++ b/fs/dlm/plock.c @@ -217,27 +217,7 @@ static int dlm_plock_callback(struct plock_op *op) fl = op_data->fl; notify = op_data->callback;
- if (op->info.rv) { - notify(fl, op->info.rv); - goto out; - } - - /* got fs lock; bookkeep locally as well: */ - flc->fl_flags &= ~FL_SLEEP; - if (posix_lock_file(file, flc, NULL)) { - /* - * This can only happen in the case of kmalloc() failure. - * The filesystem's own lock is the authoritative lock, - * so a failure to get the lock locally is not a disaster. - * As long as the fs cannot reliably cancel locks (especially - * in a low-memory situation), we're better off ignoring - * this failure than trying to recover. - */ - log_print("dlm_plock_callback: vfs lock error %llx file %p fl %p", - (unsigned long long)op->info.number, file, fl); - } - - rv = notify(fl, 0); + rv = notify(fl, op->info.rv); if (rv) { /* XXX: We need to cancel the fs lock here: */ log_print("dlm_plock_callback: lock granted after lock request "