On 16/12/20 18:26, Reinette Chatre wrote: > Hi Valentin, >> So that's part paranoia and part nonsense from my end - the contents of >> smp_call() shouldn't matter here. >> >> If we distill the code to: >> >> tsk->closid = x; >> >> if (task_curr(tsk)) >> smp_call(...); >> >> It is somewhat far fetched, but AFAICT this can be compiled as: >> >> if (task_curr(tsk)) >> tsk->closid = x; >> smp_call(...); >> else >> tsk->closid = x; >> >> IOW, there could be a sequence where the closid write is ordered *after* >> the task_curr() read. > > Could you please elaborate why it would be an issue is the closid write > is ordered after the task_curr() read? task_curr() does not depend on > the closid. > IMO the 'task_curr()' check only makes sense if it happens *after* the write, the logic being: 'closid/rmid has been written to, does the task now need interrupting?' In the above 'else' clause, task_curr() would need to be re-evaluated after the write: the task wasn't current *before* the write, but nothing guarantees this still holds *after* the write. >> With >> >> tsk->closid = x; >> >> barrier(); >> >> if (task_curr(tsk)) >> smp_call(...); >> >> that explicitely cannot happen. >> > > > Reinette
