diff options
| author | Trond Myklebust <trond.myklebust@hammerspace.com> | 2019-08-03 10:11:27 -0400 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2019-09-06 10:19:33 +0200 |
| commit | 46888ce5dcac182248ed2e445ef0320c0634964b (patch) | |
| tree | cee80e44daadac89853f3399e4982f7eda605073 /fs/compat.c | |
| parent | 49a4fda42e1ec2a14acb36c5456039dc51b67efa (diff) | |
NFSv4: Fix a potential sleep while atomic in nfs4_do_reclaim()
[ Upstream commit c77e22834ae9a11891cb613bd9a551be1b94f2bc ]
John Hubbard reports seeing the following stack trace:
nfs4_do_reclaim
rcu_read_lock /* we are now in_atomic() and must not sleep */
nfs4_purge_state_owners
nfs4_free_state_owner
nfs4_destroy_seqid_counter
rpc_destroy_wait_queue
cancel_delayed_work_sync
__cancel_work_timer
__flush_work
start_flush_work
might_sleep:
(kernel/workqueue.c:2975: BUG)
The solution is to separate out the freeing of the state owners
from nfs4_purge_state_owners(), and perform that outside the atomic
context.
Reported-by: John Hubbard <jhubbard@nvidia.com>
Fixes: 0aaaf5c424c7f ("NFS: Cache state owners after files are closed")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'fs/compat.c')
0 files changed, 0 insertions, 0 deletions