From: Ben Greear <greearb@candelatech.com>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] sunrpc: Fix race between work-queue and rpc_killall_tasks.
Date: Fri, 08 Jul 2011 10:18:30 -0700 [thread overview]
Message-ID: <4E173BE6.9000005@candelatech.com> (raw)
In-Reply-To: <1309995932.5447.6.camel@lade.trondhjem.org>
On 07/06/2011 04:45 PM, Trond Myklebust wrote:
> On Wed, 2011-07-06 at 15:49 -0700, greearb@candelatech.com wrote:
>> From: Ben Greear<greearb@candelatech.com>
>>
>> The rpc_killall_tasks logic is not locked against
>> the work-queue thread, but it still directly modifies
>> function pointers and data in the task objects.
>>
>> This patch changes the killall-tasks logic to set a flag
>> that tells the work-queue thread to terminate the task
>> instead of directly calling the terminate logic.
>>
>> Signed-off-by: Ben Greear<greearb@candelatech.com>
>> ---
>>
>> NOTE: This needs review, as I am still struggling to understand
>> the rpc code, and it's quite possible this patch either doesn't
>> fully fix the problem or actually causes other issues. That said,
>> my nfs stress test seems to run a bit more stable with this patch applied.
>
> Yes, but I don't see why you are adding a new flag, nor do I see why we
> want to keep checking for that flag in the rpc_execute() loop.
> rpc_killall_tasks() is not a frequent operation that we want to optimise
> for.
>
> How about the following instead?
Ok, I looked at your patch closer. I think it can still cause
bad race conditions.
For instance:
Assume that tk_callback is NULL at beginning of while loop in __rpc_execute,
and tk_action is rpc_exit_task.
While do_action(task) is being called, tk_action is set to NULL in rpc_exit_task.
But, right after tk_action is set to NULL in rpc_exit_task, the rpc_killall_tasks
method calls rpc_exit, which sets tk_action back to rpc_exit_task.
I believe this could cause the xprt_release(task) logic to be called in the
work-queue's execution of rpc_exit_task due to tk_action != NULL when
it should not be.
I have no hard evidence this exact scenario is happening in my case, but I
believe the code is still racy with your patch.
For that matter, is it safe to modify the flags in rpc_killall_tasks:
rovr->tk_flags |= RPC_TASK_KILLED;
Is that guaranteed to be atomic with any other modification of flags?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2011-07-08 17:18 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-06 22:49 [RFC] sunrpc: Fix race between work-queue and rpc_killall_tasks greearb
2011-07-06 23:45 ` Trond Myklebust
2011-07-06 23:45 ` Trond Myklebust
2011-07-07 0:07 ` Ben Greear
2011-07-07 0:17 ` Trond Myklebust
2011-07-07 0:35 ` Ben Greear
2011-07-07 20:38 ` Ben Greear
2011-07-08 15:03 ` Ben Greear
2011-07-08 17:18 ` Ben Greear [this message]
2011-07-08 18:11 ` Myklebust, Trond
2011-07-08 18:11 ` Myklebust, Trond
2011-07-08 22:03 ` Ben Greear
2011-07-08 22:14 ` Myklebust, Trond
2011-07-08 22:14 ` Myklebust, Trond
2011-07-09 16:34 ` Ben Greear
2011-07-12 17:14 ` Ben Greear
2011-07-12 17:25 ` Myklebust, Trond
2011-07-12 17:25 ` Myklebust, Trond
2011-07-12 17:30 ` Ben Greear
2011-07-14 16:20 ` Ben Greear
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E173BE6.9000005@candelatech.com \
--to=greearb@candelatech.com \
--cc=Trond.Myklebust@netapp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.