clang-22 -Walloc-size in mm/kfence/kfence_test.c in 6.6 and 6.1

[Nathan Chancellor]

Hi kfence folks,

After [1] in clang, I am seeing an instance of this pop up in
mm/kfence/kfence_test.c on linux-6.6.y and linux-6.1.y:

mm/kfence/kfence_test.c:723:8: error: allocation of insufficient size '0' for type 'char' with size '1' [-Werror,-Walloc-size]
723 | buf = krealloc(buf, 0, GFP_KERNEL); /* Free. */
| ^

I do not see this in linux-6.12.y or newer but I wonder if that is just
because the memory allocation profiling adds some indirection that makes
it harder for clang to perform this analysis?

Should this warning just be silenced for this translation unit or is
there some other fix that could be done here?

[1]: https://github.com/llvm/llvm-project/commit/6dc188d4eb15cbe9bdece3d940f03d93b926328c

Cheers,
Nathan

[Matthew Wilcox]

On Tue, Sep 02, 2025 at 05:07:52PM -0700, Nathan Chancellor wrote:
> Hi kfence folks,
>
> After [1] in clang, I am seeing an instance of this pop up in
> mm/kfence/kfence_test.c on linux-6.6.y and linux-6.1.y:
>
> mm/kfence/kfence_test.c:723:8: error: allocation of insufficient size '0' for type 'char' with size '1' [-Werror,-Walloc-size]
> 723 | buf = krealloc(buf, 0, GFP_KERNEL); /* Free. */
> | ^
>
> I do not see this in linux-6.12.y or newer but I wonder if that is just
> because the memory allocation profiling adds some indirection that makes
> it harder for clang to perform this analysis?
>
> Should this warning just be silenced for this translation unit or is
> there some other fix that could be done here?

I mean, it's defined behaviour:

if (unlikely(!new_size)) {
kfree(p);
return ZERO_SIZE_PTR;
}

so we have to have a test which checks that it works.

[Marco Elver]

On Wed, 3 Sept 2025 at 02:07, Nathan Chancellor <nat...@kernel.org> wrote:
>
> Hi kfence folks,
>
> After [1] in clang, I am seeing an instance of this pop up in
> mm/kfence/kfence_test.c on linux-6.6.y and linux-6.1.y:
>
> mm/kfence/kfence_test.c:723:8: error: allocation of insufficient size '0' for type 'char' with size '1' [-Werror,-Walloc-size]
> 723 | buf = krealloc(buf, 0, GFP_KERNEL); /* Free. */
> | ^
>
> I do not see this in linux-6.12.y or newer but I wonder if that is just
> because the memory allocation profiling adds some indirection that makes
> it harder for clang to perform this analysis?

It shouldn't, there's still a direct call:

> void * __must_check krealloc_noprof(const void *objp, size_t new_size,
> gfp_t flags) __realloc_size(2);
> #define krealloc(...)
alloc_hooks(krealloc_noprof(__VA_ARGS__))

> Should this warning just be silenced for this translation unit or is
> there some other fix that could be done here?

It should be silenced. I'm surprised that they'd e.g. warn about
malloc(0), which is well defined, and in the kernel, we also have
0-sized kmalloc (incl krealloc) allocations being well-defined. As
long as the returned pointer isn't used, there's no UB. I guess doing
an explicit 0-sized alloc is not something anyone should do normally I
guess, so the warning ought to prevent that, but in the test case we
explicitly want that.

[Nathan Chancellor]

On Wed, Sep 03, 2025 at 08:00:00AM +0200, Marco Elver wrote:
> It should be silenced. I'm surprised that they'd e.g. warn about
> malloc(0), which is well defined, and in the kernel, we also have
> 0-sized kmalloc (incl krealloc) allocations being well-defined. As
> long as the returned pointer isn't used, there's no UB. I guess doing
> an explicit 0-sized alloc is not something anyone should do normally I
> guess, so the warning ought to prevent that, but in the test case we
> explicitly want that.

Heh, just as I was looking at silencing this, I noticed a change to the
warning yesterday that explicitly silences it for 0-sized allocations
based on other feedback from the original thread, which I should have
noticed.

https://github.com/llvm/llvm-project/commit/5f38548c86c3e7bbfce3a739245d8f999e9946b5

So there is nothing to do here now, thanks for the input regardless!

Cheers,
Nathan