On Mon, Aug 3, 2020 at 4:01 AM Zhihao Cheng <chengzhihao1@xxxxxxxxxx> wrote:Oh, you're thinking about influence by schedule(), I get it. But I think it still works. Because the ubi_thread is still on runqueue, it will be scheduled to execute later anyway.
How can it reach the next iteration?Hmm, I see the problem but I fear this patch does not cure the race completely.The patch can handle this case. ubi_thread will exit at
It just lowers the chance to hit it.
What if KTHREAD_SHOULD_STOP is set right after you checked for it?
kthread_should_stop() in 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.