On Mon, Aug 3, 2020 at 4:01 AM Zhihao Cheng <chengzhih...@huawei.com> wrote: > > Hmm, I see the problem but I fear this patch does not cure the race > > completely. > > It just lowers the chance to hit it. > > What if KTHREAD_SHOULD_STOP is set right after you checked for it? > > The patch can handle this case. ubi_thread will exit at > kthread_should_stop() in next iteration.
How can it reach the next iteration? Maybe I didn't fully get your explanation. As far as I understand the problem correctly, the following happens: 1. ubi_thread is running and the program counter is somewhere between "if (kthread_should_stop())" and schedule() 2. While detaching kthread_stop() is called 3. Since the program counter in the thread is right before schedule(), it does not check KTHREAD_SHOULD_STOP and blindly calls into schedule() 4. The thread goes to sleep and nothing wakes it anymore -> endless wait. Is this correct so far? Your solution is putting another check for KTHREAD_SHOULD_STOP before schedule(). I argue that this will just reduce the chance to hit the race window because it can still happen that kthread_stop() is being called right after the second check and again before schedule(). Then we end up with the same situation. -- Thanks, //richard
