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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Mon, Feb 02, 2026 at 04:59:07PM +0100, Jan Beulich wrote:
> 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().

For the array case it could be sorted out in the macro wrapper - for
the pointer case it would need to be sorted at allocation, which makes
this quite weird to deal with.  Anyway, this is better than nothing I
guess.

Thanks, Roger.