Hi Tejun, Any comments about this?
Thanks On 2017/9/27 17:17, tanxiaofei wrote: > > > On 2017/9/25 23:25, Tejun Heo wrote: >> Hello, >> >> On Sat, Sep 23, 2017 at 05:04:24PM +0800, tanxiaofei wrote: >>> Hi Tejun & Jiangshan, >>> >>> I find an null pointer risk in the code of workqueue. Here is description: >>> >>> If draining, __queue_work() will call the function is_chained_work() to do >>> some checks. >>> In is_chained_work(), worker->current_pwq is used directly. It should be >>> not safe. >>> http://elixir.free-electrons.com/linux/latest/source/kernel/workqueue.c#L1384 >>> >>> If you check the thread function of this worker, worker_thread(), you will >>> find worker->current_pwq >>> is null when one work is done or ready to be processed. >>> This issue may happen only if we queue work during executing >>> drain_workqueue(). >>> http://elixir.free-electrons.com/linux/latest/source/kernel/workqueue.c#L2173 >> >> Hmmm? I don't get it. worker->current_pwq is guaranteed to be set >> while a work function is being executed and the chained check can only >> get there iff the the worker is executing a work function. >> > > Hi Tejun, > > Thanks for your quick reply. > Hmm, but i think interrupt preemption could make this happen. > For example, the scenario that all following conditions are met. > 1.The handler of an interrupt call queue_work() to queue some works, and the > workqueue is draining. > 2.An worker thread is interrupted by this interrupt. > 3.The worker thread is being executed, and at the very > moment,worker->current_pwq > is set to null.(This is possible and please check function worker_thread() > carefully). > > Thanks. > > > > > > . >
