Re: [PATCH] CPU: abstract read-mostly-ness for per-CPU cpumask_var_t variables

[Jan Beulich <jbeulich@xxxxxxxx>]

On 02.02.2026 16:50, Roger Pau Monné wrote:
> On Wed, Nov 12, 2025 at 04:53:27PM +0100, Jan Beulich wrote:
>> cpumask_var_t can resolve to a pointer or to an array. While the pointer
>> typically is allocated once for a CPU and then only read (i.e. wants to be
>> marked read-mostly), the same isn't necessarily true for the array case.
>> There things depend on how the variable is actually used. cpu_core_mask
>> and cpu_sibling_mask (which all architectures have inherited from x86,
>> which in turn is possibly wrong) are altered only as CPUs are brought up
>> or down, so may remain uniformly read-mostly. Other (x86-only) instances
>> want to change, to avoid disturbing adjacent read-mostly data.
>>
>> While doing the x86 adjustment, also do one in the opposite direction,
>> i.e. where there was no read-mostly annotation when it is applicable in
>> the "pointer" case.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> Acked-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

Thanks.

>> ---
>> Really in the pointer case it would be nice if the allocations could then
>> also come from "read-mostly" space.
> 
> Hm, I guess for some of them yes, it would make sense to come from
> __read_mostly space, but would require passing an extra parameter to
> the DEFINE_ helper? Or introduce another variant.

Whether this could be sorted purely at the macro wrapper layer I'm not
sure. It's the actual allocation (which alloc_cpumask_var() et al do)
which would need to be more sophisticated than a simple _x[mz]alloc().

Jan