Re: [PATCH v10 RESEND 01/15] fs/resctrl: Return -EBUSY when per-CLOSID RMIDs are in limbo

[Jinjie Ruan <ruanjinjie@huawei.com>]

在 2026/10/29 5:28, Reinette Chatre 写道:
> Hi Jinjie,
> 
> On 10/20/26 6:42 AM, Jinjie Ruan wrote:
>> resctrl_find_free_rmid() returns ERR_PTR(-ENOSPC) when no matching RMID
>> is found in the free list. On systems where RMIDs depend on CLOSIDs
>> (CONFIG_RESCTRL_RMID_DEPENDS_ON_CLOSID), the target CLOSID may have RMIDs
>> temporarily in limbo rather than permanently exhausted.
>>
>> When userspace attempts to create a new monitoring group, a permanent
>> -ENOSPC failure prevents retry even though the CLOSID's RMIDs may become
>> available once the limbo handler completes.
>>
>> Check closid_num_dirty_rmid[] before returning -ENOSPC. If the target
>> CLOSID has dirty RMIDs, return -EBUSY to signal a retryable condition.
>>
>> Fixes: c4c0376eefe1 ("x86/resctrl: Allow RMID allocation to be scoped by CLOSID")
>> Cc: James Morse <james.morse@arm.com>
>> Cc: Reinette Chatre <reinette.chatre@intel.com>
>> Cc: Babu Moger <babu.moger@amd.com>
>> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
>> ---
>>  fs/resctrl/monitor.c | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/fs/resctrl/monitor.c b/fs/resctrl/monitor.c
>> index 73413cb128ea..da883adc3adc 100644
>> --- a/fs/resctrl/monitor.c
>> +++ b/fs/resctrl/monitor.c
>> @@ -225,6 +225,14 @@ static struct rmid_entry *resctrl_find_free_rmid(u32 closid)
>>  			return itr;
>>  	}
>>  
>> +	/*
>> +	 * If this CLOSID has RMIDs in limbo, return -EBUSY so userspace can
>> +	 * retry. Otherwise, the CLOSID is genuinely out of RMIDs.
>> +	 */
>> +	if (IS_ENABLED(CONFIG_RESCTRL_RMID_DEPENDS_ON_CLOSID) &&
>> +	    closid_num_dirty_rmid[closid])
>> +		return ERR_PTR(-EBUSY);
>> +
>>  	return ERR_PTR(-ENOSPC);
>>  }
>>  
> 
> Does this address all scenarios? Consider for example the first test of 
> resctrl_find_free_rmid():
> 
> 	if (list_empty(&rmid_free_lru))
> 		return rmid_limbo_count ? ERR_PTR(-EBUSY) : ERR_PTR(-ENOSPC);
> 
> If rmid_free_lru is empty but rmid_limbo_count > 0 then it will return -EBUSY
> but it may be that closid_num_dirty_rmid[closid] is zero so no amount of
> waiting on limbo handler will produce a usable RMID.

Yes, you are right, we should defer the check for whether rmid_free_lru
is empty, and first check whether closid_num_dirty_rmid is 0 to
determine whether to return -EBUSY.



> 
> Reinette

-- 
Best regards,
Jinjie