net/sunrpc/clnt.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
Commit 39494194f93b("SUNRPC: Fix races with rpc_killall_tasks()") adds
rpc_task_set_rpc_status before setting RPC_TASK_SIGNALLED in
rpc_signal_task, ensuring that rpc_status is definitely set when
RPC_TASK_SIGNALLED is set.
Therefore, it seems unnecessary to set rpc_status again after detecting
RPC_TASK_SIGNALLED in rpc_check_timeout.
However, in some exceptional cases, invalid and endlessly looping
rpc_tasks may be generated. The rpc_call_rpcerror in rpc_check_timeout can
timely terminate such rpc_tasks. Removing rpc_call_rpcerror may cause the
rpc_task to fall into an infinite loop.
For example, in the following situation:
nfs4_close_done
// get err from server
nfs4_async_handle_exception
// goto out_restart
// umount -f
nfs_umount_begin
rpc_killall_tasks
rpc_signal_task
rpc_task_set_rpc_status
task->tk_rpc_status = -ERESTARTSYS
set_bit
// set RPC_TASK_SIGNALLED to tk_runstate
rpc_restart_call_prepare
__rpc_restart_call
task->tk_rpc_status = 0
// clear tk_rpc_status
...
rpc_prepare_task
nfs4_close_prepare
nfs4_setup_sequence
rpc_call_start
task->tk_action = call_start
At this point, an rpc_task with RPC_TASK_SIGNALLED set but tk_rpc_status
as 0 will be generated. This rpc_task will fall into the following loop:
call_encode --> call_transmit --> call_transmit_status --> call_status
--> call_encode.
Since RPC_TASK_SIGNALLED is set, no request will be sent in call_transmit.
Similarly, since RPC_TASK_SIGNALLED is set, rq_majortimeo will not be
updated in call_status --> rpc_check_timeout, which will cause -ETIMEDOUT
to be directly set to tk_status in call_transmit_status -->
xprt_request_wait_receive --> xprt_wait_for_reply_request_def -->
rpc_sleep_on_timeout --> __rpc_sleep_on_priority_timeout.
Here is the state and loop process of the rpc_task:
tk_runstate:
RPC_TASK_RUNNING RPC_TASK_ACTIVE RPC_TASK_NEED_RECV RPC_TASK_SIGNALLED
tk_xprt->state:
XPRT_CONNECTED XPRT_BOUND
tk_flags
RPC_TASK_ASYNC RPC_TASK_MOVEABLE RPC_TASK_DYNAMIC RPC_TASK_SOFT
RPC_TASK_NO_RETRANS_TIMEOUT RPC_TASK_CRED_NOREF
call_encode
xprt_request_enqueue_transmit
set_bit // RPC_TASK_NEED_XMIT
task->tk_action = call_transmit
call_transmit
task->tk_action = call_transmit_status
xprt_transmit
xprt_request_transmit
// check RPC_TASK_SIGNALLED and goto out_dequeue
xprt_request_dequeue_transmit
xprt_request_dequeue_transmit_locked
test_and_clear_bit // RPC_TASK_NEED_XMIT
call_transmit_status
task->tk_action = call_status
xprt_request_wait_receive
xprt_wait_for_reply_request_def
xprt_request_timeout // get timeout
req->rq_majortimeo // rq_majortimeo will not be updated
rpc_sleep_on_timeout
__rpc_sleep_on_priority_timeout
task->tk_status = -ETIMEDOUT // set ETIMEDOUT
call_status
task->tk_action = call_encode
rpc_check_timeout
// check RPC_TASK_SIGNALLED and skip xprt_reset_majortimeo
Fix it by adding rpc_call_rpcerror back.
Fixes: 39494194f93b ("SUNRPC: Fix races with rpc_killall_tasks()")
Signed-off-by: Li Lingfeng <lilingfeng3@huawei.com>
---
net/sunrpc/clnt.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
index 0090162ee8c3..0acdff19a37c 100644
--- a/net/sunrpc/clnt.c
+++ b/net/sunrpc/clnt.c
@@ -2509,8 +2509,10 @@ rpc_check_timeout(struct rpc_task *task)
{
struct rpc_clnt *clnt = task->tk_client;
- if (RPC_SIGNALLED(task))
+ if (RPC_SIGNALLED(task)) {
+ rpc_call_rpcerror(task, -ERESTARTSYS);
return;
+ }
if (xprt_adjust_timeout(task->tk_rqstp) == 0)
return;
--
2.31.1Hi,
Thanks for the patch.
Before 39494194f93b("SUNRPC: Fix races with rpc_killall_tasks()", every
time we set RPC_TASK_SIGNALLED, when we go through __rpc_execute, this
rpc_task will immediate break and exist.
However after that, __rpc_execute won't judge RPC_TASK_SIGNNALED, so for
the case like you point out below, even after your commit
rpc_check_timeout will help break and exist eventually, but this
rpc_task has already do some work. I prefer reintroduce judging
RPC_TASK_SIGNNALED in __rpc_execute to help exist immediatly.
在 2025/1/14 22:41, Li Lingfeng 写道:
> Commit 39494194f93b("SUNRPC: Fix races with rpc_killall_tasks()") adds
> rpc_task_set_rpc_status before setting RPC_TASK_SIGNALLED in
> rpc_signal_task, ensuring that rpc_status is definitely set when
> RPC_TASK_SIGNALLED is set.
> Therefore, it seems unnecessary to set rpc_status again after detecting
> RPC_TASK_SIGNALLED in rpc_check_timeout.
>
> However, in some exceptional cases, invalid and endlessly looping
> rpc_tasks may be generated. The rpc_call_rpcerror in rpc_check_timeout can
> timely terminate such rpc_tasks. Removing rpc_call_rpcerror may cause the
> rpc_task to fall into an infinite loop.
>
> For example, in the following situation:
> nfs4_close_done
> // get err from server
> nfs4_async_handle_exception
> // goto out_restart
> // umount -f
> nfs_umount_begin
> rpc_killall_tasks
> rpc_signal_task
> rpc_task_set_rpc_status
> task->tk_rpc_status = -ERESTARTSYS
> set_bit
> // set RPC_TASK_SIGNALLED to tk_runstate
> rpc_restart_call_prepare
> __rpc_restart_call
> task->tk_rpc_status = 0
> // clear tk_rpc_status
> ...
> rpc_prepare_task
> nfs4_close_prepare
> nfs4_setup_sequence
> rpc_call_start
> task->tk_action = call_start
>
> At this point, an rpc_task with RPC_TASK_SIGNALLED set but tk_rpc_status
> as 0 will be generated. This rpc_task will fall into the following loop:
> call_encode --> call_transmit --> call_transmit_status --> call_status
> --> call_encode.
>
> Since RPC_TASK_SIGNALLED is set, no request will be sent in call_transmit.
> Similarly, since RPC_TASK_SIGNALLED is set, rq_majortimeo will not be
> updated in call_status --> rpc_check_timeout, which will cause -ETIMEDOUT
> to be directly set to tk_status in call_transmit_status -->
> xprt_request_wait_receive --> xprt_wait_for_reply_request_def -->
> rpc_sleep_on_timeout --> __rpc_sleep_on_priority_timeout.
>
> Here is the state and loop process of the rpc_task:
> tk_runstate:
> RPC_TASK_RUNNING RPC_TASK_ACTIVE RPC_TASK_NEED_RECV RPC_TASK_SIGNALLED
> tk_xprt->state:
> XPRT_CONNECTED XPRT_BOUND
> tk_flags
> RPC_TASK_ASYNC RPC_TASK_MOVEABLE RPC_TASK_DYNAMIC RPC_TASK_SOFT
> RPC_TASK_NO_RETRANS_TIMEOUT RPC_TASK_CRED_NOREF
>
> call_encode
> xprt_request_enqueue_transmit
> set_bit // RPC_TASK_NEED_XMIT
> task->tk_action = call_transmit
>
> call_transmit
> task->tk_action = call_transmit_status
> xprt_transmit
> xprt_request_transmit
> // check RPC_TASK_SIGNALLED and goto out_dequeue
> xprt_request_dequeue_transmit
> xprt_request_dequeue_transmit_locked
> test_and_clear_bit // RPC_TASK_NEED_XMIT
>
> call_transmit_status
> task->tk_action = call_status
> xprt_request_wait_receive
> xprt_wait_for_reply_request_def
> xprt_request_timeout // get timeout
> req->rq_majortimeo // rq_majortimeo will not be updated
> rpc_sleep_on_timeout
> __rpc_sleep_on_priority_timeout
> task->tk_status = -ETIMEDOUT // set ETIMEDOUT
>
> call_status
> task->tk_action = call_encode
> rpc_check_timeout
> // check RPC_TASK_SIGNALLED and skip xprt_reset_majortimeo
>
> Fix it by adding rpc_call_rpcerror back.
>
> Fixes: 39494194f93b ("SUNRPC: Fix races with rpc_killall_tasks()")
> Signed-off-by: Li Lingfeng <lilingfeng3@huawei.com>
> ---
> net/sunrpc/clnt.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
> index 0090162ee8c3..0acdff19a37c 100644
> --- a/net/sunrpc/clnt.c
> +++ b/net/sunrpc/clnt.c
> @@ -2509,8 +2509,10 @@ rpc_check_timeout(struct rpc_task *task)
> {
> struct rpc_clnt *clnt = task->tk_client;
>
> - if (RPC_SIGNALLED(task))
> + if (RPC_SIGNALLED(task)) {
> + rpc_call_rpcerror(task, -ERESTARTSYS);
> return;
> + }
>
> if (xprt_adjust_timeout(task->tk_rqstp) == 0)
> return;
On Thu, 2025-01-16 at 19:43 +0800, yangerkun wrote:
> Hi,
>
> Thanks for the patch.
>
> Before 39494194f93b("SUNRPC: Fix races with rpc_killall_tasks()",
> every
> time we set RPC_TASK_SIGNALLED, when we go through __rpc_execute,
> this
> rpc_task will immediate break and exist.
>
> However after that, __rpc_execute won't judge RPC_TASK_SIGNNALED, so
> for
> the case like you point out below, even after your commit
> rpc_check_timeout will help break and exist eventually, but this
> rpc_task has already do some work. I prefer reintroduce judging
> RPC_TASK_SIGNNALED in __rpc_execute to help exist immediatly.
>
Better yet... Let's get rid of the RPC_TASK_SIGNALLED flag altogether
and just replace
#define RPC_TASK_SIGNALLED(task) (READ_ONCE(task->tk_rpc_status) == -ERESTARTSYS)
There is no good reason to try to maintain two completely separate
sources of truth to describe the same task state.
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com
在 2025/1/17 4:52, Trond Myklebust 写道:
> On Thu, 2025-01-16 at 19:43 +0800, yangerkun wrote:
>> Hi,
>>
>> Thanks for the patch.
>>
>> Before 39494194f93b("SUNRPC: Fix races with rpc_killall_tasks()",
>> every
>> time we set RPC_TASK_SIGNALLED, when we go through __rpc_execute,
>> this
>> rpc_task will immediate break and exist.
>>
>> However after that, __rpc_execute won't judge RPC_TASK_SIGNNALED, so
>> for
>> the case like you point out below, even after your commit
>> rpc_check_timeout will help break and exist eventually, but this
>> rpc_task has already do some work. I prefer reintroduce judging
>> RPC_TASK_SIGNNALED in __rpc_execute to help exist immediatly.
>>
>
> Better yet... Let's get rid of the RPC_TASK_SIGNALLED flag altogether
> and just replace
>
> #define RPC_TASK_SIGNALLED(task) (READ_ONCE(task->tk_rpc_status) == -ERESTARTSYS)
Hi,
Thanks for your reply! Yeah, if all the places where tk_rpc_status is
updated are by calling rpc_task_set_rpc_status, we can use
task->tk_rpc_status == -ERESTARTSYS to determine whether rpc_task is
RPC_TASK_SIGNALLED. But for the case like Li has provided,
__rpc_restart_call won't do this, and will overwrite tk_rpc_status
unconditionally. This won't be a stable solution. Maybe it's better to
change __rpc_restart_call calling rpc_task_set_rpc_status too? And
__rpc_execute will be enough to help solve this case.
>
> There is no good reason to try to maintain two completely separate
> sources of truth to describe the same task state.
>
On Fri, 2025-01-17 at 10:29 +0800, yangerkun wrote:
>
>
> 在 2025/1/17 4:52, Trond Myklebust 写道:
> > On Thu, 2025-01-16 at 19:43 +0800, yangerkun wrote:
> > > Hi,
> > >
> > > Thanks for the patch.
> > >
> > > Before 39494194f93b("SUNRPC: Fix races with rpc_killall_tasks()",
> > > every
> > > time we set RPC_TASK_SIGNALLED, when we go through __rpc_execute,
> > > this
> > > rpc_task will immediate break and exist.
> > >
> > > However after that, __rpc_execute won't judge RPC_TASK_SIGNNALED,
> > > so
> > > for
> > > the case like you point out below, even after your commit
> > > rpc_check_timeout will help break and exist eventually, but this
> > > rpc_task has already do some work. I prefer reintroduce judging
> > > RPC_TASK_SIGNNALED in __rpc_execute to help exist immediatly.
> > >
> >
> > Better yet... Let's get rid of the RPC_TASK_SIGNALLED flag
> > altogether
> > and just replace
> >
> > #define RPC_TASK_SIGNALLED(task) (READ_ONCE(task->tk_rpc_status) ==
> > -ERESTARTSYS)
>
> Hi,
>
> Thanks for your reply! Yeah, if all the places where tk_rpc_status is
> updated are by calling rpc_task_set_rpc_status, we can use
> task->tk_rpc_status == -ERESTARTSYS to determine whether rpc_task is
> RPC_TASK_SIGNALLED. But for the case like Li has provided,
> __rpc_restart_call won't do this, and will overwrite tk_rpc_status
> unconditionally. This won't be a stable solution. Maybe it's better
> to
> change __rpc_restart_call calling rpc_task_set_rpc_status too? And
> __rpc_execute will be enough to help solve this case.
>
>
That would break __rpc_restart_call() to the point of rendering it
completely useless.
The whole purpose of that call is to give the NFS layer a chance to
handle errors in the exit callback, and then kick off a fresh call.
Your suggestion would mean that any RPC level error sticks around, and
causes the new call to immediately fail.
I see no point in doing anything more than fixing the looping
behaviour. Eliminating the redundant flag will do that.
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com
在 2025/1/17 11:15, Trond Myklebust 写道:
> On Fri, 2025-01-17 at 10:29 +0800, yangerkun wrote:
>>
>> 在 2025/1/17 4:52, Trond Myklebust 写道:
>>> On Thu, 2025-01-16 at 19:43 +0800, yangerkun wrote:
>>>> Hi,
>>>>
>>>> Thanks for the patch.
>>>>
>>>> Before 39494194f93b("SUNRPC: Fix races with rpc_killall_tasks()",
>>>> every
>>>> time we set RPC_TASK_SIGNALLED, when we go through __rpc_execute,
>>>> this
>>>> rpc_task will immediate break and exist.
>>>>
>>>> However after that, __rpc_execute won't judge RPC_TASK_SIGNNALED,
>>>> so
>>>> for
>>>> the case like you point out below, even after your commit
>>>> rpc_check_timeout will help break and exist eventually, but this
>>>> rpc_task has already do some work. I prefer reintroduce judging
>>>> RPC_TASK_SIGNNALED in __rpc_execute to help exist immediatly.
>>>>
>>> Better yet... Let's get rid of the RPC_TASK_SIGNALLED flag
>>> altogether
>>> and just replace
>>>
>>> #define RPC_TASK_SIGNALLED(task) (READ_ONCE(task->tk_rpc_status) ==
>>> -ERESTARTSYS)
Hi,
I'm not quite clear on how this can resolve the issue.
If we remove the RPC_TASK_SIGNALLED flag and replace setting tk_runstate
to RPC_TASK_SIGNALLED with setting tk_rpc_status to -ERESTARTSYS in
rpc_signal_task, wouldn't setting tk_rpc_status back to 0 in
__rpc_restart_call still lead to an infinite loop in the rpc_task?
Could you please provide a more detailed explanation?
Thanks.
>> Hi,
>>
>> Thanks for your reply! Yeah, if all the places where tk_rpc_status is
>> updated are by calling rpc_task_set_rpc_status, we can use
>> task->tk_rpc_status == -ERESTARTSYS to determine whether rpc_task is
>> RPC_TASK_SIGNALLED. But for the case like Li has provided,
>> __rpc_restart_call won't do this, and will overwrite tk_rpc_status
>> unconditionally. This won't be a stable solution. Maybe it's better
>> to
>> change __rpc_restart_call calling rpc_task_set_rpc_status too? And
>> __rpc_execute will be enough to help solve this case.
>>
>>
> That would break __rpc_restart_call() to the point of rendering it
> completely useless.
> The whole purpose of that call is to give the NFS layer a chance to
> handle errors in the exit callback, and then kick off a fresh call.
> Your suggestion would mean that any RPC level error sticks around, and
> causes the new call to immediately fail.
>
> I see no point in doing anything more than fixing the looping
> behaviour. Eliminating the redundant flag will do that.
>
在 2025/1/17 11:15, Trond Myklebust 写道:
> On Fri, 2025-01-17 at 10:29 +0800, yangerkun wrote:
>>
>>
>> 在 2025/1/17 4:52, Trond Myklebust 写道:
>>> On Thu, 2025-01-16 at 19:43 +0800, yangerkun wrote:
>>>> Hi,
>>>>
>>>> Thanks for the patch.
>>>>
>>>> Before 39494194f93b("SUNRPC: Fix races with rpc_killall_tasks()",
>>>> every
>>>> time we set RPC_TASK_SIGNALLED, when we go through __rpc_execute,
>>>> this
>>>> rpc_task will immediate break and exist.
>>>>
>>>> However after that, __rpc_execute won't judge RPC_TASK_SIGNNALED,
>>>> so
>>>> for
>>>> the case like you point out below, even after your commit
>>>> rpc_check_timeout will help break and exist eventually, but this
>>>> rpc_task has already do some work. I prefer reintroduce judging
>>>> RPC_TASK_SIGNNALED in __rpc_execute to help exist immediatly.
>>>>
>>>
>>> Better yet... Let's get rid of the RPC_TASK_SIGNALLED flag
>>> altogether
>>> and just replace
>>>
>>> #define RPC_TASK_SIGNALLED(task) (READ_ONCE(task->tk_rpc_status) ==
>>> -ERESTARTSYS)
>>
>> Hi,
>>
>> Thanks for your reply! Yeah, if all the places where tk_rpc_status is
>> updated are by calling rpc_task_set_rpc_status, we can use
>> task->tk_rpc_status == -ERESTARTSYS to determine whether rpc_task is
>> RPC_TASK_SIGNALLED. But for the case like Li has provided,
>> __rpc_restart_call won't do this, and will overwrite tk_rpc_status
>> unconditionally. This won't be a stable solution. Maybe it's better
>> to
>> change __rpc_restart_call calling rpc_task_set_rpc_status too? And
>> __rpc_execute will be enough to help solve this case.
>>
>>
>
> That would break __rpc_restart_call() to the point of rendering it
> completely useless.
Aha, agree with you. There maybe case tk_rpc_status != 0 but
rpc_restart_call can also rerun this rpc_task.
The only case we should consider is when we call rpc_signal_task, we
should break this rpc_task unconditionally. Fixing it within
__rpc_execute is enough.
> The whole purpose of that call is to give the NFS layer a chance to
> handle errors in the exit callback, and then kick off a fresh call.
> Your suggestion would mean that any RPC level error sticks around, and
> causes the new call to immediately fail.
>
> I see no point in doing anything more than fixing the looping
> behaviour. Eliminating the redundant flag will do that.
>
在 2025/1/16 19:43, yangerkun 写道:
> Hi,
>
> Thanks for the patch.
>
> Before 39494194f93b("SUNRPC: Fix races with rpc_killall_tasks()", every
> time we set RPC_TASK_SIGNALLED, when we go through __rpc_execute, this
> rpc_task will immediate break and exist.
>
> However after that, __rpc_execute won't judge RPC_TASK_SIGNNALED, so for
> the case like you point out below, even after your commit
> rpc_check_timeout will help break and exist eventually, but this
> rpc_task has already do some work. I prefer reintroduce judging
> RPC_TASK_SIGNNALED in __rpc_execute to help exist immediatly.
Thanks for your advice, I will send v2 soon.
>
> 在 2025/1/14 22:41, Li Lingfeng 写道:
>> Commit 39494194f93b("SUNRPC: Fix races with rpc_killall_tasks()") adds
>> rpc_task_set_rpc_status before setting RPC_TASK_SIGNALLED in
>> rpc_signal_task, ensuring that rpc_status is definitely set when
>> RPC_TASK_SIGNALLED is set.
>> Therefore, it seems unnecessary to set rpc_status again after detecting
>> RPC_TASK_SIGNALLED in rpc_check_timeout.
>>
>> However, in some exceptional cases, invalid and endlessly looping
>> rpc_tasks may be generated. The rpc_call_rpcerror in
>> rpc_check_timeout can
>> timely terminate such rpc_tasks. Removing rpc_call_rpcerror may cause
>> the
>> rpc_task to fall into an infinite loop.
>>
>> For example, in the following situation:
>> nfs4_close_done
>> // get err from server
>> nfs4_async_handle_exception
>> // goto out_restart
>> // umount -f
>> nfs_umount_begin
>> rpc_killall_tasks
>> rpc_signal_task
>> rpc_task_set_rpc_status
>> task->tk_rpc_status = -ERESTARTSYS
>> set_bit
>> // set RPC_TASK_SIGNALLED to
>> tk_runstate
>> rpc_restart_call_prepare
>> __rpc_restart_call
>> task->tk_rpc_status = 0
>> // clear tk_rpc_status
>> ...
>> rpc_prepare_task
>> nfs4_close_prepare
>> nfs4_setup_sequence
>> rpc_call_start
>> task->tk_action = call_start
>>
>> At this point, an rpc_task with RPC_TASK_SIGNALLED set but tk_rpc_status
>> as 0 will be generated. This rpc_task will fall into the following loop:
>> call_encode --> call_transmit --> call_transmit_status --> call_status
>> --> call_encode.
>>
>> Since RPC_TASK_SIGNALLED is set, no request will be sent in
>> call_transmit.
>> Similarly, since RPC_TASK_SIGNALLED is set, rq_majortimeo will not be
>> updated in call_status --> rpc_check_timeout, which will cause
>> -ETIMEDOUT
>> to be directly set to tk_status in call_transmit_status -->
>> xprt_request_wait_receive --> xprt_wait_for_reply_request_def -->
>> rpc_sleep_on_timeout --> __rpc_sleep_on_priority_timeout.
>>
>> Here is the state and loop process of the rpc_task:
>> tk_runstate:
>> RPC_TASK_RUNNING RPC_TASK_ACTIVE RPC_TASK_NEED_RECV RPC_TASK_SIGNALLED
>> tk_xprt->state:
>> XPRT_CONNECTED XPRT_BOUND
>> tk_flags
>> RPC_TASK_ASYNC RPC_TASK_MOVEABLE RPC_TASK_DYNAMIC RPC_TASK_SOFT
>> RPC_TASK_NO_RETRANS_TIMEOUT RPC_TASK_CRED_NOREF
>>
>> call_encode
>> xprt_request_enqueue_transmit
>> set_bit // RPC_TASK_NEED_XMIT
>> task->tk_action = call_transmit
>>
>> call_transmit
>> task->tk_action = call_transmit_status
>> xprt_transmit
>> xprt_request_transmit
>> // check RPC_TASK_SIGNALLED and goto out_dequeue
>> xprt_request_dequeue_transmit
>> xprt_request_dequeue_transmit_locked
>> test_and_clear_bit // RPC_TASK_NEED_XMIT
>>
>> call_transmit_status
>> task->tk_action = call_status
>> xprt_request_wait_receive
>> xprt_wait_for_reply_request_def
>> xprt_request_timeout // get timeout
>> req->rq_majortimeo // rq_majortimeo will not be updated
>> rpc_sleep_on_timeout
>> __rpc_sleep_on_priority_timeout
>> task->tk_status = -ETIMEDOUT // set ETIMEDOUT
>>
>> call_status
>> task->tk_action = call_encode
>> rpc_check_timeout
>> // check RPC_TASK_SIGNALLED and skip xprt_reset_majortimeo
>>
>> Fix it by adding rpc_call_rpcerror back.
>>
>> Fixes: 39494194f93b ("SUNRPC: Fix races with rpc_killall_tasks()")
>> Signed-off-by: Li Lingfeng <lilingfeng3@huawei.com>
>> ---
>> net/sunrpc/clnt.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
>> index 0090162ee8c3..0acdff19a37c 100644
>> --- a/net/sunrpc/clnt.c
>> +++ b/net/sunrpc/clnt.c
>> @@ -2509,8 +2509,10 @@ rpc_check_timeout(struct rpc_task *task)
>> {
>> struct rpc_clnt *clnt = task->tk_client;
>> - if (RPC_SIGNALLED(task))
>> + if (RPC_SIGNALLED(task)) {
>> + rpc_call_rpcerror(task, -ERESTARTSYS);
>> return;
>> + }
>> if (xprt_adjust_timeout(task->tk_rqstp) == 0)
>> return;
© 2016 - 2025 Red Hat, Inc.