]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
NFSv4: Fix a potential sleep while atomic in nfs4_do_reclaim()
authorTrond Myklebust <trond.myklebust@hammerspace.com>
Sat, 3 Aug 2019 14:11:27 +0000 (10:11 -0400)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 29 Aug 2019 06:26:40 +0000 (08:26 +0200)
commitb6bc6d20e00a0baa357572fb7dd010cb9ffce49e
tree7461147dc5643a94b266960f2733b5910027a330
parent77a6e51271f08e6b10426477afa3b4afa9bfa221
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>
fs/nfs/nfs4_fs.h
fs/nfs/nfs4client.c
fs/nfs/nfs4state.c