This patch is fixing the current the callback handling if it's 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") using only trylocks in an asynchronous polling behaviour. The
behaviour before was however differently by evaluating F_SETLKW or F_SETLK
and evaluating FL_SLEEP which was the case before commit 40595cdc93ed
("nfs: block notification on fs with its own ->lock"). This behaviour
seems to be broken before. This patch will fix the behaviour for the
special nfs case before commit 40595cdc93ed ("nfs: block notification on
fs with its own ->lock").

There is still a TODO of solving the case when an nfs locking request
got interrupted.

Fixes: 40595cdc93ed ("nfs: block notification on fs with its own ->lock")
Signed-off-by: Alexander Aring <aahri...@redhat.com>
---
 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 "
-- 
2.31.1

Reply via email to