Re: [PATCH] percpu: improve percpu_alloc_percpu event trace

Vasily Averin
2022-05-10T04:28:21Z

On 5/10/22 00:06, Steven Rostedt wrote:
> I'm curious as to where the gfp_t to unsigned long is happening in the
> macros?

original ___GFP_* flags are usual defines

/* Plain integer GFP bitmasks. Do not use this directly. */
#define ___GFP_DMA 0x01u
#define ___GFP_HIGHMEM 0x02u
#define ___GFP_DMA32 0x04u

... but __GFP_* flags used elsewhere are declared as 'forced to gfp_t'

#define __GFP_DMA ((__force gfp_t)___GFP_DMA)
#define __GFP_HIGHMEM ((__force gfp_t)___GFP_HIGHMEM)
#define __GFP_DMA32 ((__force gfp_t)___GFP_DMA32)
...
#define GFP_DMA __GFP_DMA
#define GFP_DMA32 __GFP_DMA32

... and when __def_gfpflag_names() traslates them to unsigned long

{(unsigned long)GFP_DMA, "GFP_DMA"}, \
{(unsigned long)__GFP_HIGHMEM, "__GFP_HIGHMEM"}, \
{(unsigned long)GFP_DMA32, "GFP_DMA32"}, \

... it leads to sparse warnings bacuse type gfp_t was declared as 'bitwise'
From mas sparse

-Wbitwise
Warn about unsupported operations or type mismatches with
restricted integer types.

Sparse supports an extended attribute,
__attribute__((bitwise)), which creates a new restricted
integer type from a base integer type, distinct from the
base integer type and from any other restricted integer
type not declared in the same declaration or typedef.

__bitwise is for *unique types* that cannot be mixed with
other types, and that you'd never want to just use as a
random integer (the integer 0 is special, though, and gets
silently accepted iirc - it's kind of like "NULL" for
pointers). So "gfp_t" or the "safe endianness" types would
be __bitwise: you can only operate on them by doing
specific operations that know about *that* particular
type.

Sparse issues these warnings by default.

Thank you,
Vasily Averin