On 14.03.2025 18:24, Alejandro Vallejo wrote:
> As it is, it's incredibly easy for a buggy call to XENMEMF_node() to
> unintentionally overflow into bit 17 and beyond. Prevent it by masking,
> just like MEMF_* does.

Yet then ...

> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -32,8 +32,9 @@
>  #define XENMEMF_address_bits(x)     (x)
>  #define XENMEMF_get_address_bits(x) ((x) & 0xffu)
>  /* NUMA node to allocate from. */
> -#define XENMEMF_node(x)     (((x) + 1) << 8)
> -#define XENMEMF_get_node(x) ((((x) >> 8) - 1) & 0xffu)
> +#define XENMEMF_node_mask   (0xffu)
> +#define XENMEMF_node(n)     ((((n) + 1) & XENMEMF_node_mask) << 8)

... this still won't have the intended effect: Rather than spilling into
higher bits (with a certain chance of causing an error) you now truncate
the node number, thus making the misbehavior almost certainly silent.
Further, if you do this for the node, why not also for the address bits?
(Rhetorical question; I don't really want you to do that.)

Jan

> +#define XENMEMF_get_node(f) ((((f) >> 8) - 1) & XENMEMF_node_mask)
>  /* Flag to populate physmap with populate-on-demand entries */
>  #define XENMEMF_populate_on_demand (1<<16)
>  /* Flag to request allocation only from the node specified */


Reply via email to