Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <1b130af3-65fa-5a1c-cd07-5d2acacbd26a@intel.com>
Date:   Wed, 23 Nov 2022 08:45:41 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Firefox/102.0 Thunderbird/102.5.0
Subject: Re: [PATCH v3 1/2] x86/resctrl: IPI all CPUs for group updates
Content-Language: en-US
To:     Peter Newman <peternewman@google.com>
CC:     <fenghua.yu@intel.com>, <bp@alien8.de>, <derkling@google.com>,
        <eranian@google.com>, <hpa@zytor.com>, <james.morse@arm.com>,
        <jannh@google.com>, <kpsingh@google.com>,
        <linux-kernel@vger.kernel.org>, <mingo@redhat.com>,
        <tglx@linutronix.de>, <x86@kernel.org>
References: <20221115141953.816851-1-peternewman@google.com>
 <20221115141953.816851-2-peternewman@google.com>
 <54e50a9b-268f-2020-f54c-d38312489e2f@intel.com>
 <CALPaoCh9e5PB+fx2k6qBfOjduA01Rr2ZxdJFg4oocJtJ0aSYjQ@mail.gmail.com>
From:   Reinette Chatre <reinette.chatre@intel.com>
In-Reply-To: <CALPaoCh9e5PB+fx2k6qBfOjduA01Rr2ZxdJFg4oocJtJ0aSYjQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VHpncUV0RjRvdkdna3ZOVGZ6UmxlSHRGTWpLZk9YOG1zTVJnQjF0YWk2SlFt?=
 =?utf-8?B?OXZ4MHROLzB1UmI2V1VEWkc2bWdHdCtjc0R6aWdqbGx3MHNQczRsS0dPSkxw?=
 =?utf-8?B?czNrdzJuSGVHOUlFb3hqaXBwTW92UFVsS0NYOVRmaHNHeWZTODFGQmdSSXJa?=
 =?utf-8?B?YlArVkM5QmdZZktteXlaTDFGQ2hYZGEyRkE5RkRZYjh3QlFaVnVUSWJjUUFN?=
 =?utf-8?B?UTFCOGNTR0x0cUtkeFNEUVA3MEppQ1pReVBmMnBrSDRmQ0N0QXF4cVZQeWcz?=
 =?utf-8?B?RXg2N0J4VlNicjFmRy9HUUQ5ZFUzTCtZYUNHU0tCMnFFMndBalpkRkFwdGVz?=
 =?utf-8?B?b0ZkbW1QeWt0b2N0Q1NaUzhObTBvKys2c0IrZElEdVIzbXVDMDdYM25ORGQw?=
 =?utf-8?B?R1dmKytNWG5CSVQwczBONE80ckd1OWx2bWVWQ2o5Z0tZeTJ0WFRkSmFhNlhi?=
 =?utf-8?B?REFKYnRPUk1IYnpvakRzYkZHTkRDTERXVjlZdFNtdjVFU2d1RTNTdTkyYW85?=
 =?utf-8?B?RW5GelZyc0ZMODVTOVNvVFdEU3RkS0lRdTN0cmk2RnRaQkxoWWUwRFp5cHVq?=
 =?utf-8?B?N3Mxa1I5SXZEVGNuTnArdHdZZVVGMTFrYjcrY3Y5UGVId1pKdlh0TFlTR05K?=
 =?utf-8?B?c3NXNTB5MDFIalhlUTFjTzc5Z0tBc2FnTTg5Wkp3SUhzU3lUTWdwcFV2Mjk0?=
 =?utf-8?B?bUNRWkpGaVdybE5uSEhwZGJkaHlZMDBsQnVVdHFOdmY2UlNLamx3Z0Naa1VH?=
 =?utf-8?B?UXhuaFpzN08rZU1XYjlxbi9IZlJtMlY0VG1jZWJKQ3l4WDFTN3NXWnVNOEV4?=
 =?utf-8?B?RWdGNzQ3THlJaDl6Y0Y5S2haSEMwSUVOTmFhNG5wMEkxRTduTWxnbEVSTFBj?=
 =?utf-8?B?Y0VHUnpNOVB5TmZjSlljcENOQ08vY2UzK0VuMmRhMzR5QUdZaWF6dDIrTUpu?=
 =?utf-8?B?UFpxSW0ycUhKWDB6ZjJBNjJBS2ovOUhvTUc4RVFvRytQTmNZWFh3ajY5R2Uv?=
 =?utf-8?B?NHdYc3JXakZ6SGM4Qit6MFUrZ1lnc0YrOVVOMWpvdHNOSFZ4dEo1VHlmVzJK?=
 =?utf-8?B?R2RaY3cwR29xSHJaRFdJc3VaQnFKSHJlUGp6M1ArN3VldlhmdG1QZmR2Nms5?=
 =?utf-8?B?THBQa28xaDJ5cjQyWVdVRFlURnZ4c0hQbU15RUtrUkJSaEk3T0UzWmhxRVJj?=
 =?utf-8?B?dHRha2RjTFRpdWd2ZDRLQXpkblU0Z2VEbmpxc2hnNDBlbnU0TmdnWHFtZWN6?=
 =?utf-8?B?bGsyUTNOQW8ySUtsMjhRRzZYNFB2Smw4OVBkbU1GMzNCTmVXMTVwc29pcWYv?=
 =?utf-8?B?RTB4UHVETFp4K0xBTkprUTE2T1oza2RnL0pqRmZpVWsyT0NQNzhReS9KNzRF?=
 =?utf-8?B?Q0VaWkMxRXUyVjhhUkVINXZYV0JsNzRsQnVwa0Nic0EreXVJQlpSQk9rVHRL?=
 =?utf-8?B?MVhVQVRjVXBlY2U3NHI4dFc4endIRUpxRXJscVJBNWZwVTBkWmxXaW1yWlRC?=
 =?utf-8?B?YVRNcXVwVExUNVBTR0x5dTJ5cU9aZlRERUxvTndPSWZsMTJ5Sm1qUGIwZDRu?=
 =?utf-8?B?b2x3WHJsZnd0MWk3TFhpSGxueTdBUVdwejVNeUpSUXdlZlI0YnhQQ1B4T25K?=
 =?utf-8?B?Z2lHMEZZRjUwVyszUkFYOEtGRDNWUlVZc2JLV2hQZU1acFNYQnJTM1R6UTNU?=
 =?utf-8?B?Y25ldFNLS2k2YURZZUQyWCtRM3pXTEZIVHY0bVowZEdMYWxPZU9FeC9wM3NP?=
 =?utf-8?B?YnFEYmcxVkkxbGtHREtXODlrVVBaNU83TzBjYjVRYll3UnQrRk9RRTg4aG54?=
 =?utf-8?B?eUtTcmxLa2FwS0hCNEhTdXBLT1M2Ynk4amRaYTRUWWUzcjEzTHFyN3BnZHJV?=
 =?utf-8?B?QlI0WjhKNndKYzBOZ2hZWloyTXUvYTJyNko0Wk5xSEg5NzJndVkrRytRaTdh?=
 =?utf-8?B?clA3a2ZSK05jRkdqblRaeFR6ZmM2Sk5PcndORGxDM0JFWWFMaHdyQ0ozWHRp?=
 =?utf-8?B?MkxvYkcra3o1UGZoNERpS0FjcUZiNXI2YXozMVRPUGs0K1hTbzZBdTBQWjRq?=
 =?utf-8?B?MEJoWWFFWmU5ZjNWZFZUdEpMUm1PSUNYSXhLYWhhVWFPTlhEdFFUMGN5VGxX?=
 =?utf-8?B?alBybkFWN3FudTZHaW5lNzNYWi9JU0tNZStKMkhXaVl2VGU1ZUhuMUk5Nnk3?=
 =?utf-8?B?UVE9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: dd7db666-787a-4ebd-ff51-08dacd72299e
X-MS-Exchange-CrossTenant-AuthSource: CY4PR11MB1862.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Nov 2022 16:45:45.1628
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: olo1zkuj49m+qlEVo+R8BtS8ecfyNVYe+7ak8Mj++qr3EaOUZtUCdMBXjx0SHu3MqsI/OMc3txf8xWPF5th4AMVZsMX5J9S3t7jHoUTjLBM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB6120
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,
        RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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