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]>

> ---
> 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.

Thanks, Roger.

Reply via email to