[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <534F059C.9020905@cn.fujitsu.com>
Date: Thu, 17 Apr 2014 06:35:08 +0800
From: Lai Jiangshan <laijs@...fujitsu.com>
To: Tejun Heo <tj@...nel.org>
CC: LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V2] workqueue: fix possible race condition when rescuer
VS pwq-release
On 04/17/2014 12:50 AM, Tejun Heo wrote:
> Hello, Lai.
>
> On Thu, Apr 17, 2014 at 12:21:21AM +0800, Lai Jiangshan wrote:
>> OK. It is better to use get_pwq(). I will also change the above comments to:
>>
>> The base ref and the possible ref from rerscuer(stopped) are never
>> dropped on per-cpu pwqs.
>> Directly free the pwqs and wq.
>
> Hmmm, why does that matter? The base ref is the business of
> create/destroy path and as long as base ref is never put other refs
> just don't matter.
>
>> The reason I quickly dropped V1 and wrote the V2 is that I saw this comment.
>> "The base ref" is precise after I used get_pwq() in V1.
>>
>> Or to avoid to change to this comments.
>> I can also move the following code down to the bottom of the rescuer_thread().
>>
>> if (kthread_should_stop()) {
>> __set_current_state(TASK_RUNNING);
>> rescuer->task->flags &= ~PF_WQ_WORKER;
>> return 0;
>> }
>>
>> (I reply this email on browser, never mind the syntax).
>> Maybe the second choice are better.
>
> Hmmm... yeah, regardlesss of the above, it's a bit nasty that rescuer
> may exit with non-empty mayday list.
>
+ * The wq->maydays list maybe still have some pwqs linked,
+ * but it is safe to free them all together since the rescuer
+ * is stopped.
I just comment it without fix. It has no harm before, but it harms after I added a get_pwq().
Sorry.
Lai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists