Re: mm/kfence/kfence_test.c:287 test_alloc() warn: use 'gfp' here instead of GFP_KERNEL?

[Dan Carpenter]

On Thu, Jul 27, 2023 at 07:23:23AM +0200, Helge Deller wrote:
> > bc8fbc5f305aec Marco Elver     2021-02-25  282  			alloc = kmalloc(size, gfp);
> >                                                                                                ^^^
> > 
> > bc8fbc5f305aec Marco Elver     2021-02-25  283
> > bc8fbc5f305aec Marco Elver     2021-02-25  284  		if (is_kfence_address(alloc)) {
> > 8dae0cfed57357 Vlastimil Babka 2021-11-03  285  			struct slab *slab = virt_to_slab(alloc);
> > 588c7fa022d7b2 Hyeonggon Yoo   2021-06-28  286  			struct kmem_cache *s = test_cache ?:
> > 588c7fa022d7b2 Hyeonggon Yoo   2021-06-28 @287  					kmalloc_caches[kmalloc_type(GFP_KERNEL)][__kmalloc_index(size, false)];
> >                                                                                                                      ^^^^^^^^^^
> > I feel like using gfp might be correct but I'm not sure?  This code
> > is from prior to this commit.  Let's add Marco to the CC.
> 
> Since this is a test program, I assume that "GFP_KERNEL" is used intentionally
> instead of "gfp" here to check if the "kmalloc(size, gfp)" above gets the right kmalloc_caches[].
> If so, is there a way to silence the smatch warning ("mm/kfence/kfence_test.c:287 test_alloc() warn: use 'gfp' here instead of GFP_KERNEL?") ?
> But I'm not sure either, so adding Hyeonggon to the CC too...

Instead of silencing warnings, I prefer to just look at them one time
and move on.

Old warnings are included in the emails if someone touches the code
again.  The other double free warnings are an example of this.  (Except
that I never have forwarded them before because they're intentional as
part of testing kfence.)

regards,
dan carpenter