On Wed, Jul 03, 2024 at 04:02:35PM +0100, Richard Fitzgerald wrote:
> As far as I can tell from the limited commit message and comments, the
> purpose of commit 6a74b670 ("Refactor and add new functions tested by
> check_kvmalloc_array_zero()") is to suggest that uses of __GFP_ZERO are
> replaced by the appropriate zeroing allocator, like kzalloc.
>
> But this warning is being reported on the function
> cs_dsp_coeff_read_ctrl_raw() in drivers/firmware/cirrus/cs_dsp.c
>
> That function does not have a __GFP_ZERO, the kmalloc is:
>
> scratch = kmalloc(len, GFP_KERNEL | GFP_DMA);
>
> and it is intentional to use kmalloc because the entire buffer is
> then overwritten, so it's inefficient to zero-fill it first.
Sorry about that. To be honest, I don't look at those results because
it's a style issue and I tend to ignore those. So I didn't see the
results were all wrong now.
The issue is that they redifined __GFP_ flags to be much more
complicated macros instead of just 0x001000 or whatever it was.
I've been meaning to fix this. I'll disable the check_kvmalloc_array_zero()
check until it's fixed. But really I need to fix this because I need to
know when GFP_ATOMIC is set.
Thanks for the bug report.
regards,
dan carpenter
