diff options
| author | Zhihao Cheng <chengzhihao1@huawei.com> | 2020-06-01 11:12:31 +0200 |
|---|---|---|
| committer | Richard Weinberger <richard@nod.at> | 2020-09-17 22:55:59 +0200 |
| commit | d005f8c6588efcfbe88099b6edafc6f58c84a9c1 (patch) | |
| tree | c3e63aef96f76c25486a0f2094f6678320222fc6 /fs/ubifs/journal.c | |
| parent | ubifs: dent: Fix some potential memory leaks while iterating entries (diff) | |
| download | linux-d005f8c6588efcfbe88099b6edafc6f58c84a9c1.tar.xz linux-d005f8c6588efcfbe88099b6edafc6f58c84a9c1.zip | |
ubi: check kthread_should_stop() after the setting of task state
A detach hung is possible when a race occurs between the detach process
and the ubi background thread. The following sequences outline the race:
ubi thread: if (list_empty(&ubi->works)...
ubi detach: set_bit(KTHREAD_SHOULD_STOP, &kthread->flags)
=> by kthread_stop()
wake_up_process()
=> ubi thread is still running, so 0 is returned
ubi thread: set_current_state(TASK_INTERRUPTIBLE)
schedule()
=> ubi thread will never be scheduled again
ubi detach: wait_for_completion()
=> hung task!
To fix that, we need to check kthread_should_stop() after we set the
task state, so the ubi thread will either see the stop bit and exit or
the task state is reset to runnable such that it isn't scheduled out
indefinitely.
Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
Cc: <stable@vger.kernel.org>
Fixes: 801c135ce73d5df1ca ("UBI: Unsorted Block Images")
Reported-by: syzbot+853639d0cb16c31c7a14@syzkaller.appspotmail.com
Signed-off-by: Richard Weinberger <richard@nod.at>
Diffstat (limited to 'fs/ubifs/journal.c')
0 files changed, 0 insertions, 0 deletions