Messages in this thread | | | Date | Tue, 10 May 2022 07:22:02 +0300 | Subject | Re: [PATCH] percpu: improve percpu_alloc_percpu event trace | From | Vasily Averin <> |
| |
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
| |