* [Cluster-devel] [PATCH dlm/next] fs: dlm: fix nfs async lock callback handling
@ 2023-06-06 21:56 Alexander Aring
2023-06-06 21:58 ` Alexander Aring
2023-06-07 7:35 ` Greg KH
0 siblings, 2 replies; 3+ messages in thread
From: Alexander Aring @ 2023-06-06 21:56 UTC (permalink / raw
To: cluster-devel.redhat.com
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 <aahringo@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
^ permalink raw reply related [flat|nested] 3+ messages in thread
* [Cluster-devel] [PATCH dlm/next] fs: dlm: fix nfs async lock callback handling
2023-06-06 21:56 [Cluster-devel] [PATCH dlm/next] fs: dlm: fix nfs async lock callback handling Alexander Aring
@ 2023-06-06 21:58 ` Alexander Aring
2023-06-07 7:35 ` Greg KH
1 sibling, 0 replies; 3+ messages in thread
From: Alexander Aring @ 2023-06-06 21:58 UTC (permalink / raw
To: cluster-devel.redhat.com
Hi,
On Tue, Jun 6, 2023 at 5:56?PM Alexander Aring <aahringo@redhat.com> wrote:
>
> 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.
>
sorry, I will rephrase that.
- Alex
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Cluster-devel] [PATCH dlm/next] fs: dlm: fix nfs async lock callback handling
2023-06-06 21:56 [Cluster-devel] [PATCH dlm/next] fs: dlm: fix nfs async lock callback handling Alexander Aring
2023-06-06 21:58 ` Alexander Aring
@ 2023-06-07 7:35 ` Greg KH
1 sibling, 0 replies; 3+ messages in thread
From: Greg KH @ 2023-06-07 7:35 UTC (permalink / raw
To: cluster-devel.redhat.com
On Tue, Jun 06, 2023 at 05:56:26PM -0400, Alexander Aring wrote:
> 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 <aahringo@redhat.com>
> ---
> fs/dlm/plock.c | 22 +---------------------
> 1 file changed, 1 insertion(+), 21 deletions(-)
>
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
</formletter>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2023-06-07 7:35 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-06-06 21:56 [Cluster-devel] [PATCH dlm/next] fs: dlm: fix nfs async lock callback handling Alexander Aring
2023-06-06 21:58 ` Alexander Aring
2023-06-07 7:35 ` Greg KH
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).