Re: [PATCH mm] tracing: incorrect gfp_t conversion

Joe Perches
2022-05-08T20:52:07Z

On Sat, 2022-05-07 at 15:48 -0700, Andrew Morton wrote:
> On Sun, 8 May 2022 01:28:58 +0300 Vasily Averin <vvs@openvz.org> wrote:
>
> > On 5/7/22 22:37, Andrew Morton wrote:
> > > On Sat, 7 May 2022 22:02:05 +0300 Vasily Averin <vvs@openvz.org> wrote:
> > > > + {(__force unsigned long)GFP_KERNEL, "GFP_KERNEL"}, \
> > > > + {(__force unsigned long)GFP_NOFS, "GFP_NOFS"}, \
> > >
> > > This got all repetitive, line-wrappy and ugly :(
> > >
> > > What do we think of something silly like this?
> >
> > > --- a/include/trace/events/mmflags.h~tracing-incorrect-gfp_t-conversion-fix
> > > +++ a/include/trace/events/mmflags.h
> > > @@ -13,53 +13,57 @@
> > > * Thus most bits set go first.
> > > */
> > >
> > > +#define FUL __force unsigned long
> > > +
> > > #define __def_gfpflag_names \
> > > - {(__force unsigned long)GFP_TRANSHUGE, "GFP_TRANSHUGE"}, \
> > > - {(__force unsigned long)GFP_TRANSHUGE_LIGHT, "GFP_TRANSHUGE_LIGHT"}, \
> > ...
> > > + {(FUL)GFP_TRANSHUGE, "GFP_TRANSHUGE"}, \
> > > + {(FUL)GFP_TRANSHUGE_LIGHT, "GFP_TRANSHUGE_LIGHT"}, \
> >
> >
> > I think it's a good idea, and I regret it was your idea and not mine.
>
> heh
>
> > Should I resend my patch with these changes or would you prefer
> > to keep your patch as a separate one?
>
> I did the below. I'll squash them together later.

Very repetitive indeed.

Why not use another stringifying macro?

Maybe something like:

#define gfpflag_string(GFP) \
{(__force unsigned long)GFP, #GFP)}

#define __def_gfpflag_names \
gfp_flag_string(GFP_TRANSHUGE), \
etc...