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 "
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
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>
linux-stable-mirror@lists.linaro.org