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