[Cluster-devel] [PATCHv2 dlm/next] fs: dlm: fix nfs async lock callback handling

[Cluster-devel] [PATCHv2 dlm/next] fs: dlm: fix nfs async lock callback handling

[Alexander Aring]

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 at 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 "
-- 
2.31.1

[Cluster-devel] [PATCHv2 dlm/next] fs: dlm: fix nfs async lock callback handling

[Alexander Aring]

Hi,

On Thu, Jun 8, 2023 at 6:58?AM Alexander Aring <aahringo@redhat.com> wrote:
>
> 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.
>

mhhh, this patch only removes the book keeping of "cat /proc/locks"
and when I am observing it I don't see fcntl() locks when using nfs
with gfs2 under locks there and this is the issue here.

I need to investigate more into this.

- Alex