Jeff Layton <jlayton@xxxxxxxxxx> writes:
> On Tue, 28 May 2013 04:49:53 +0100
> Ben Hutchings <ben@xxxxxxxxxxxxxxx> wrote:
>
>> 3.2.46-rc1 review patch. If anyone has any objections, please let me know.
>>
>> ------------------
>>
>> From: Jeff Layton <jlayton@xxxxxxxxxx>
>>
>> commit 506026c3ec270e18402f0c9d33fee37482c23861 upstream.
>>
>> rpc_make_runnable is not generally called with the queue lock held, unless
>> it's waking up a task that has been sitting on a waitqueue. This is safe
>> when the task has not entered the FSM yet, but the comments don't really
>> spell this out.
>>
>> Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx>
>> Signed-off-by: Trond Myklebust <Trond.Myklebust@xxxxxxxxxx>
>> Signed-off-by: Ben Hutchings <ben@xxxxxxxxxxxxxxx>
>> ---
>> net/sunrpc/sched.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> --- a/net/sunrpc/sched.c
>> +++ b/net/sunrpc/sched.c
>> @@ -296,8 +296,9 @@ EXPORT_SYMBOL_GPL(__rpc_wait_for_complet
>> /*
>> * Make an RPC task runnable.
>> *
>> - * Note: If the task is ASYNC, this must be called with
>> - * the spinlock held to protect the wait queue operation.
>> + * Note: If the task is ASYNC, and is being made runnable after sitting on an
>> + * rpc_wait_queue, this must be called with the queue spinlock held to protect
>> + * the wait queue operation.
>> */
>> static void rpc_make_runnable(struct rpc_task *task)
>> {
>>
>
> Just a comment patch, so this is harmless and I have no objection but
> why pull it into stable? I had always thought stable-kernel-rules.txt
> discouraged taking patches that don't fix real bugs...
I believe the reason Ben took this patch is actually to provide the
correct context for the next one:
a3c3cac5d31879cd9ae2de7874dc6544ca704aec, "SUNRPC: Prevent an rpc_task wakeup race"
So that this is a clean cherry-pick.
(At least this was the reason I picked it for the 3.5 kernel.)
Cheers,
--
Luis
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html