| Message ID | 20180114144236.28213-3-colyli@suse.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 01/14/2018 03:42 PM, Coly Li wrote: > Kernel thread routine bch_writeback_thread() has the following code block, > > 447 down_write(&dc->writeback_lock); > 448~450 if (check conditions) { > 451 up_write(&dc->writeback_lock); > 452 set_current_state(TASK_INTERRUPTIBLE); > 453 > 454 if (kthread_should_stop()) > 455 return 0; > 456 > 457 schedule(); > 458 continue; > 459 } > > If condition check is true, its task state is set to TASK_INTERRUPTIBLE > and call schedule() to wait for others to wake up it. > > There are 2 issues in current code, > 1, Task state is set to TASK_INTERRUPTIBLE after the condition checks, if > another process changes the condition and call wake_up_process(dc-> > writeback_thread), then at line 452 task state is set back to > TASK_INTERRUPTIBLE, the writeback kernel thread will lose a chance to be > waken up. > 2, At line 454 if kthread_should_stop() is true, writeback kernel thread > will return to kernel/kthread.c:kthread() with TASK_INTERRUPTIBLE and > call do_exit(). It is not good to enter do_exit() with task state > TASK_INTERRUPTIBLE, in following code path might_sleep() is called and a > warning message is reported by __might_sleep(): "WARNING: do not call > blocking ops when !TASK_RUNNING; state=1 set at [xxxx]". > > For the first issue, task state should be set before condition checks. > Ineed because dc->writeback_lock is required when modifying all the > conditions, calling set_current_state() inside code block where dc-> > writeback_lock is hold is safe. But this is quite implicit, so I still move > set_current_state() before all the condition checks. > > For the second issue, frankley speaking it does not hurt when kernel thread > exits with TASK_INTERRUPTIBLE state, but this warning message scares users, > makes them feel there might be something risky with bcache and hurt their > data. Setting task state to TASK_RUNNING before returning fixes this > problem. > > Changelog: > v2: fix the race issue in v1 patch. > v1: initial buggy fix. > > Signed-off-by: Coly Li <colyli@suse.de> > Cc: Michael Lyle <mlyle@lyle.org> > Cc: Hannes Reinecke <hare@suse.de> > Cc: Junhui Tang <tang.junhui@zte.com.cn> > --- > drivers/md/bcache/writeback.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > Reviewed-by: Hannes Reinecke <hare@suse.com> Cheers, Hannes
diff --git a/drivers/md/bcache/writeback.c b/drivers/md/bcache/writeback.c index 0ade883b6316..f1d2fc15abcc 100644 --- a/drivers/md/bcache/writeback.c +++ b/drivers/md/bcache/writeback.c @@ -564,18 +564,21 @@ static int bch_writeback_thread(void *arg) while (!kthread_should_stop()) { down_write(&dc->writeback_lock); + set_current_state(TASK_INTERRUPTIBLE); if (!atomic_read(&dc->has_dirty) || (!test_bit(BCACHE_DEV_DETACHING, &dc->disk.flags) && !dc->writeback_running)) { up_write(&dc->writeback_lock); - set_current_state(TASK_INTERRUPTIBLE); - if (kthread_should_stop()) + if (kthread_should_stop()) { + set_current_state(TASK_RUNNING); return 0; + } schedule(); continue; } + set_current_state(TASK_RUNNING); searched_full_index = refill_dirty(dc);
Kernel thread routine bch_writeback_thread() has the following code block, 447 down_write(&dc->writeback_lock); 448~450 if (check conditions) { 451 up_write(&dc->writeback_lock); 452 set_current_state(TASK_INTERRUPTIBLE); 453 454 if (kthread_should_stop()) 455 return 0; 456 457 schedule(); 458 continue; 459 } If condition check is true, its task state is set to TASK_INTERRUPTIBLE and call schedule() to wait for others to wake up it. There are 2 issues in current code, 1, Task state is set to TASK_INTERRUPTIBLE after the condition checks, if another process changes the condition and call wake_up_process(dc-> writeback_thread), then at line 452 task state is set back to TASK_INTERRUPTIBLE, the writeback kernel thread will lose a chance to be waken up. 2, At line 454 if kthread_should_stop() is true, writeback kernel thread will return to kernel/kthread.c:kthread() with TASK_INTERRUPTIBLE and call do_exit(). It is not good to enter do_exit() with task state TASK_INTERRUPTIBLE, in following code path might_sleep() is called and a warning message is reported by __might_sleep(): "WARNING: do not call blocking ops when !TASK_RUNNING; state=1 set at [xxxx]". For the first issue, task state should be set before condition checks. Ineed because dc->writeback_lock is required when modifying all the conditions, calling set_current_state() inside code block where dc-> writeback_lock is hold is safe. But this is quite implicit, so I still move set_current_state() before all the condition checks. For the second issue, frankley speaking it does not hurt when kernel thread exits with TASK_INTERRUPTIBLE state, but this warning message scares users, makes them feel there might be something risky with bcache and hurt their data. Setting task state to TASK_RUNNING before returning fixes this problem. Changelog: v2: fix the race issue in v1 patch. v1: initial buggy fix. Signed-off-by: Coly Li <colyli@suse.de> Cc: Michael Lyle <mlyle@lyle.org> Cc: Hannes Reinecke <hare@suse.de> Cc: Junhui Tang <tang.junhui@zte.com.cn> --- drivers/md/bcache/writeback.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)