NeilBrown e90402fb06 nfsd: don't call locks_release_private() twice concurrently
[ Upstream commit 05eda6e75773592760285e10ac86c56d683be17f ]

It is possible for free_blocked_lock() to be called twice concurrently,
once from nfsd4_lock() and once from nfsd4_release_lockowner() calling
remove_blocked_locks().  This is why a kref was added.

It is perfectly safe for locks_delete_block() and kref_put() to be
called in parallel as they use locking or atomicity respectively as
protection.  However locks_release_private() has no locking.  It is
safe for it to be called twice sequentially, but not concurrently.

This patch moves that call from free_blocked_lock() where it could race
with itself, to free_nbl() where it cannot.  This will slightly delay
the freeing of private info or release of the owner - but not by much.
It is arguably more natural for this freeing to happen in free_nbl()
where the structure itself is freed.

This bug was found by code inspection - it has not been seen in practice.

Fixes: 47446d74f170 ("nfsd4: add refcount for nfsd4_blocked_lock")
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2024-04-10 16:19:29 +02:00
..
2024-04-10 16:18:38 +02:00
2024-02-23 08:54:51 +01:00
2024-04-10 16:19:29 +02:00
2021-12-29 12:28:59 +01:00
2024-03-01 13:21:47 +01:00
2023-09-19 12:22:53 +02:00
2024-03-01 13:21:43 +01:00
2023-09-23 11:10:01 +02:00
2023-12-08 08:48:04 +01:00
2023-08-30 16:18:19 +02:00
2024-04-10 16:19:01 +02:00
2022-12-14 11:37:31 +01:00
2023-01-12 11:58:47 +01:00
2022-07-02 16:41:17 +02:00
2022-07-12 16:35:08 +02:00
2021-12-14 10:57:15 +01:00