Messages in this thread | | | Date | Wed, 23 Nov 2022 08:45:41 -0800 | Subject | Re: [PATCH v3 1/2] x86/resctrl: IPI all CPUs for group updates | From | Reinette Chatre <> |
| |
Hi Peter,
On 11/23/2022 3:09 AM, Peter Newman wrote: > On Mon, Nov 21, 2022 at 10:53 PM Reinette Chatre > <reinette.chatre@intel.com> wrote: >> On 11/15/2022 6:19 AM, Peter Newman wrote:
...
>>> search the entire tasklist for group members which could be running on >>> that CPU. This needs to be done while blocking updates to the tasklist >>> to avoid leaving newly-created child tasks assigned to the old >>> CLOSID/RMID. >> >> This is not clear to me. rdt_move_group_tasks() obtains a read lock, >> read_lock(&tasklist_lock), so concurrent modifications to the tasklist >> are indeed possible. Should this perhaps be write_lock() instead? >> It sounds like the scenario you are describing may be a concern. That is, >> if a task belonging to a group that is being removed happens to >> call fork()/clone() during the move then the child may end up being >> created with old closid. > > Shouldn't read_lock(&tasklist_lock) cause write_lock(&tasklist_lock) to > block?
Apologies, yes, you are right. I was focusing too much on the detail of task_struct::tasks being a RCU list and lost sight of the actual lock obtained (rcu_read_lock() vs read_lock()) in this instance.
Reinette
| |