Hi,
On Thu, Jun 8, 2023 at 6:58 AM Alexander Aring <aahringo@xxxxxxxxxx> 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
