Hi Reinette,
On 03/12/20 23:25, Reinette Chatre wrote:
> Valentin's series in [2] ends by adding memory barriers to support the
> updating of the task_struct from one CPU and the usage of the task_struct data
> from another CPU. This work is still needed and as discussed with Valentin in
> that thread the work would be re-evaluated by him after seeing how this series
> turns out.
>
So the "problematic" pattern is still there: a context switch can happen
concurrently with a write to the switching-to-tasks's {closid, rmid}.
Accesses to these fields would thus need to be wrapped by READ_ONCE() &
WRITE_ONCE().
Thinking a bit more (too much?) about it, we could limit ourselves to
wrapping only reads not protected by the rdtgroup_mutex: the only two
task_struct {closid, rmid} writers are
- rdtgroup_move_task()
- rdt_move_group_tasks()
and they are both invoked while holding said mutex. Thus, a reader holding
the mutex cannot race with a write, so load tearing ought to be safe.
> [1]:
> https://lore.kernel.org/lkml/calvzod7e9zzhwenzf7objzgksdbmvwtgej0npgs0lufu3sn...@mail.gmail.com/
> [2]:
> https://lore.kernel.org/lkml/[email protected]
>
> Fenghua Yu (3):
> x86/resctrl: Move setting task's active CPU in a mask into helpers
> x86/resctrl: Update PQR_ASSOC MSR synchronously when moving task to
> resource group
> x86/resctrl: Don't move a task to the same resource group
>
> arch/x86/kernel/cpu/resctrl/rdtgroup.c | 159 +++++++++++++------------
> 1 file changed, 82 insertions(+), 77 deletions(-)
>
>
> base-commit: b65054597872ce3aefbc6a666385eabdf9e288da
