diff options
| author | Trond Myklebust <trond.myklebust@hammerspace.com> | 2025-02-01 15:00:09 -0500 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2025-03-07 18:25:27 +0100 |
| commit | 4fe4ae6c2e01d028856b73b6328b12b8945df871 (patch) | |
| tree | 8ecc848e42c58721a7760acc3c5bf9b1142b0f13 /scripts/stackusage | |
| parent | a3ae6a60baf7cce449306a33d46ecdbd40211b37 (diff) | |
| download | linux-4fe4ae6c2e01d028856b73b6328b12b8945df871.tar.gz linux-4fe4ae6c2e01d028856b73b6328b12b8945df871.tar.bz2 linux-4fe4ae6c2e01d028856b73b6328b12b8945df871.zip | |
NFSv4: Fix a deadlock when recovering state on a sillyrenamed file
[ Upstream commit 8f8df955f078e1a023ee55161935000a67651f38 ]
If the file is sillyrenamed, and slated for delete on close, it is
possible for a server reboot to triggeer an open reclaim, with can again
race with the application call to close(). When that happens, the call
to put_nfs_open_context() can trigger a synchronous delegreturn call
which deadlocks because it is not marked as privileged.
Instead, ensure that the call to nfs4_inode_return_delegation_on_close()
catches the delegreturn, and schedules it asynchronously.
Reported-by: Li Lingfeng <lilingfeng3@huawei.com>
Fixes: adb4b42d19ae ("Return the delegation when deleting sillyrenamed files")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Anna Schumaker <anna.schumaker@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'scripts/stackusage')
0 files changed, 0 insertions, 0 deletions