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 <[email protected]> > > > > Acked-by: Roger Pau Monné <[email protected]> > > 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.
