[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20210531130650.179734331@linuxfoundation.org>
Date: Mon, 31 May 2021 15:13:43 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-kernel@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
stable@...r.kernel.org, zhouchuangao <zhouchuangao@...o.com>,
Trond Myklebust <trond.myklebust@...merspace.com>
Subject: [PATCH 5.4 066/177] fs/nfs: Use fatal_signal_pending instead of signal_pending
From: zhouchuangao <zhouchuangao@...o.com>
commit bb002388901151fe35b6697ab116f6ed0721a9ed upstream.
We set the state of the current process to TASK_KILLABLE via
prepare_to_wait(). Should we use fatal_signal_pending() to detect
the signal here?
Fixes: b4868b44c562 ("NFSv4: Wait for stateid updates after CLOSE/OPEN_DOWNGRADE")
Signed-off-by: zhouchuangao <zhouchuangao@...o.com>
Signed-off-by: Trond Myklebust <trond.myklebust@...merspace.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
---
fs/nfs/nfs4proc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -1647,7 +1647,7 @@ static void nfs_set_open_stateid_locked(
rcu_read_unlock();
trace_nfs4_open_stateid_update_wait(state->inode, stateid, 0);
- if (!signal_pending(current)) {
+ if (!fatal_signal_pending(current)) {
if (schedule_timeout(5*HZ) == 0)
status = -EAGAIN;
else
@@ -3416,7 +3416,7 @@ static bool nfs4_refresh_open_old_statei
write_sequnlock(&state->seqlock);
trace_nfs4_close_stateid_update_wait(state->inode, dst, 0);
- if (signal_pending(current))
+ if (fatal_signal_pending(current))
status = -EINTR;
else
if (schedule_timeout(5*HZ) != 0)
Powered by blists - more mailing lists