Thanks for the clarification. But in that case, shouldn’t the patch check whether IS_PARKED was already set before calling complete(&self->parked)? Otherwise, the completion count for self->parked could be more than 1 as a result of spurious wakeups, which could make a future call to kthread_park complete prematurely.
Thanks, Junaid On Friday, September 29, 2017 10:28:38 AM Peter Zijlstra wrote: > On Fri, Sep 29, 2017 at 09:59:55AM +0200, Thomas Gleixner wrote: > > On Thu, 28 Sep 2017, Junaid Shahid wrote: > > > > > Hi Peter, > > > > > > It looks like try_cmpxchg is not available on non-x86 archs, but other > > > than > > > that the version that you proposed looks good. > > > > > > One thing that I am a bit curious about is that the original code, before > > > either patch, had a test_and_set_bit for KTHREAD_IS_PARKED rather than > > > just > > > a set_bit. I can't think of any reason why that was needed, since it > > > doesn't look like TASK_PARKED tasks are susceptible to spurious wakeups. > > > Do > > > you by any chance happen to know if there was any specific reason for it? > > > > Everything is susceptible to spurious wakeups and has to deal with it. > > Right, we should code as if they are at all times possible. Currently, > for TASK_PARKED, I don't think they can happen, but I've had patches > that introduce them on purpose (regardless the state) just to stress the > code. > > IIRC only TASK_STOPPED and/or TASK_TRACED hard rely on not getting any.
