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
