Messages in this thread | | | From | Valentin Schneider <> | Subject | Re: [PATCH 2/3] x86/resctrl: Update PQR_ASSOC MSR synchronously when moving task to resource group | Date | Thu, 17 Dec 2020 10:39:43 +0000 |
| |
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
| |