Re: [PATCH v8 11/11] arm_mpam: detect and enable MPAM-Fb PCC support

[Lee Trager]

On 8/4/26 3:06 AM, Andre Przywara wrote:

>   /*
>    * Number of MSCs that have been probed. Once all MSCs have been probed MPAM
>    * can be enabled.
> @@ -2275,6 +2362,8 @@ static void mpam_msc_drv_remove(struct platform_device *pdev)
>   {
>   	struct mpam_msc *msc = platform_get_drvdata(pdev);
>   
> +	mpam_pcc_chan_put(msc->pcc_chan);
> +
>   	mutex_lock(&mpam_list_lock);
>   	mpam_msc_destroy(msc);
>   	mutex_unlock(&mpam_list_lock);

I think the PCC channel lifetime needs to follow the MSC's deferred 
lifetime.


mpam_msc_drv_remove() currently drops the PCC channel reference before 
removing the MSC from SRCU-protected lists. If this is the final 
reference, an existing SRCU reader can still enter 
mpam_fb_send_request() through the retained MSC and access the freed 
channel. A new reader could also find the MSC before list_del_rcu().


Moving mpam_pcc_chan_put() after mpam_free_garbage() is not sufficient 
because the garbage list is global and can be drained concurrently. e.g

1. One caller queues the MSC.

2. Another caller claims it with llist_del_all() and waits in 
synchronize_srcu()

3. The first caller finds the garbage list empty and returns without 
performing a grace period.

4. The first caller releases the channel while the reader blocking the 
other collector can still be using it.


Would it make sense to associate an optional release callback for each 
garbage entry? An MSC entry could use that callback to drop its PCC 
reference after the collector that claimed the entry completes 
synchronize_srcu(), but before the MSC is freed. This would keep the 
grace period and channel release under the ownership of the same 
collector. This would also handle mpam_disable(), which currently 
destroys and frees PCC-backed MSCs without dropping their PCC channel 
references.