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(). Jan
