Sparse not supporting kzalloc_obj() and friends

Sparse not supporting kzalloc_obj() and friends

[Ricardo Ribalda]

Hi

In media-ci we use sparse for static analyzing the new changes in the
media subsystem.
Since 7.0rc1 sparse is failing with errors such as the one at the end
of this email.

The culprit seems to be the new kzalloc_obj and friends.

I have been trying to add this as a workaround:

$ git diff predefine.c
diff --git a/predefine.c b/predefine.c
index c6750831..821100a2 100644
--- a/predefine.c
+++ b/predefine.c
@@ -208,6 +208,16 @@ void predefined_macros(void)
        predefine("__extension__", 0, NULL);
        predefine("__pragma__", 0, NULL);

+       add_pre_buffer("#strong_define kzalloc_obj(type)
kzalloc(sizeof(type), GFP_KERNEL)\n");
+       add_pre_buffer("#strong_define kzalloc_objs(type, n)
kzalloc(sizeof(type) * (n), GFP_KERNEL)\n");
+       add_pre_buffer("#strong_define kmalloc_obj(type)
kmalloc(sizeof(type), GFP_KERNEL)\n");
+       add_pre_buffer("#strong_define kvmalloc_obj(type)
kvmalloc(sizeof(type), GFP_KERNEL)\n");
+       add_pre_buffer("#strong_define kmalloc_obj(type, flags)
kmalloc(sizeof(type), flags)\n");
+       add_pre_buffer("#strong_define kmalloc_objs(type, n)
kmalloc(sizeof(type) * (n), flags)\n");
+       add_pre_buffer("#strong_define kvzalloc_objs(type, n)
kvzalloc(sizeof(type) * (n), flags)\n");
+       add_pre_buffer("#strong_define kvzalloc(type)
kvzalloc(sizeof(type), flags)\n");
+       add_pre_buffer("#strong_define kzalloc_flex(type, pos, n,
flags) kzalloc(sizeof(type), flags)\n");
+
        switch (arch_m64) {
        case ARCH_LP32:
                break;

But it is a dirty hack and the fact that the macros support
"polymorphisms" makes it even uglier...

I have been Googling a bit, and I cannot find anyone else complaining
about this... which I find a bit weird.

Am I holding it wrong?

Thanks!

$ make -i W=1 C=1 CHECK="../media-ci/third_party/sparse/sparse"
drivers/media/i2c/tda1997x.o
  CC      scripts/mod/empty.o
  CHECK   scripts/mod/empty.c
  MKELF   scripts/mod/elfconfig.h
  HOSTCC  scripts/mod/modpost.o
  CC      scripts/mod/devicetable-offsets.s
  HOSTCC  scripts/mod/file2alias.o
  HOSTCC  scripts/mod/sumversion.o
  HOSTCC  scripts/mod/symsearch.o
  HOSTLD  scripts/mod/modpost
  CC      kernel/bounds.s
  CC      arch/x86/kernel/asm-offsets.s
  CC      kernel/sched/rq-offsets.s
  CALL    scripts/checksyscalls.sh
  DESCEND objtool
  INSTALL libsubcmd_headers
  CC      drivers/media/i2c/tda1997x.o
  CHECK   drivers/media/i2c/tda1997x.c
drivers/media/i2c/tda1997x.c: note: in included file (through
include/linux/i2c.h):
./include/linux/acpi.h:69:18: error: Expected ) in function call
./include/linux/acpi.h:69:18: error: got ,
./include/linux/acpi.h:69:18: error: Expected ) in function call
./include/linux/acpi.h:69:18: error: got ,
./include/linux/acpi.h:69:18: error: Expected ) in function call
./include/linux/acpi.h:69:18: error: got ,
drivers/media/i2c/tda1997x.c: note: in included file (through
include/media/v4l2-common.h, include/media/v4l2-subdev.h,
include/media/v4l2-device.h):
./include/linux/spi/spi.h:1312:15: error: Expected ) in function call
./include/linux/spi/spi.h:1312:15: error: got __VA_OPT__
./include/linux/spi/spi.h:1312:15: error: Expected ) in function call
./include/linux/spi/spi.h:1312:15: error: got __VA_OPT__
./include/linux/spi/spi.h:1312:15: error: Expected ) in function call
./include/linux/spi/spi.h:1312:15: error: got __VA_OPT__
drivers/media/i2c/tda1997x.c:2541:17: error: Expected ) in function call
drivers/media/i2c/tda1997x.c:2541:17: error: got ,
drivers/media/i2c/tda1997x.c:2541:17: error: Expected ) in function call
drivers/media/i2c/tda1997x.c:2541:17: error: got ,
drivers/media/i2c/tda1997x.c:2541:17: error: Expected ) in function call
drivers/media/i2c/tda1997x.c:2541:17: error: got ,
drivers/media/i2c/tda1997x.c:2541:17: error: undefined identifier '_res'
drivers/media/i2c/tda1997x.c:2541:17: error: undefined identifier '__VA_OPT__'
drivers/media/i2c/tda1997x.c:2541:17: error: undefined identifier '_res'
drivers/media/i2c/tda1997x.c:2541:17: error: undefined identifier '__VA_OPT__'
drivers/media/i2c/tda1997x.c:2541:17: error: undefined identifier '_res'

-- 
Ricardo Ribalda

Re: Sparse not supporting kzalloc_obj() and friends

[Linus Torvalds]

On Mon, 23 Feb 2026 at 02:52, Ricardo Ribalda <ribalda@chromium.org> wrote:
>
> The culprit seems to be the new kzalloc_obj and friends.

Argh. The culprit is the use of __VA_OPT__, which apparently sparse
never got taught.

We already use __VA_OPT__ elsewhere in the kernel, but it's fairly
rare, so it apparently hasn't been noticed much. For example, btrfs
uses it, but apparently only under CONFIG_BTRFS_ASSERT

The btrfs use has a comment about _why_ the use of __VA_OPT__ is
actually needed:

 * As ##__VA_ARGS__ cannot be at the beginning of the macro the
__VA_OPT__ is needed
 * and supported since GCC 8 and Clang 12.

and that's why I used it in the new alloc_obj helpers too - not only
is it the more modern "standard C"  model, it's actually a bit more
user friendly than the traditional ## gcc trick.

Ho humm. I guess I should look at the sparse pre-processor code,
unless somebody already implemented __VA_OPT__ somewhere?

             Linus

Re: Sparse not supporting kzalloc_obj() and friends

[Linus Torvalds]

On Mon, 23 Feb 2026 at 08:19, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Argh. The culprit is the use of __VA_OPT__, which apparently sparse
> never got taught.
>    [...]
> Ho humm. I guess I should look at the sparse pre-processor code,
> unless somebody already implemented __VA_OPT__ somewhere?

Actually, it looks like Al at least *looked* at doing __VA_OPT__ back
at the end of last year. In fact, just a couple of months ago I said
"I'm not sure it buys us much", but that was when I thought it was
just a standard versions of the gcc ## thing, and before I realized
how much more convenient it actually is to use.

Al? You know the pre-process.c file a *lot* better than I do, even
ignoring the fact that it's been fifteen years since I touched it. And
you presumably already had some thoughts on doing __VA_OPT__?

That said, I can also just make default_gfp() use ## after all. I
_had_ grepped for __VA_OPT__ in the kernel and decided "we already use
it", but clearly it's causing some issues.

So instead of <linux/gfp.h> doing

  #define __default_gfp(a,...) a
  #define default_gfp(...) __default_gfp(__VA_ARGS__ __VA_OPT__(,) GFP_KERNEL)

which I think is fairly straightforward and the "natural" way to do
things, the kernel can just do

  #define __default_gfp(a,b,...) b
  #define default_gfp(...) __default_gfp(,##__VA_ARGS__,GFP_KERNEL)

instead, with a dummy empty argument to make the gcc ## trick work.
It's smaller and denser, so it's actually superior in that sense, even
if it feels a bit less natural than the __VA_OPT__ model.

Ricardo, can you verify that that trick works for you?

Al, comments?

             Linus

Re: Sparse not supporting kzalloc_obj() and friends

[Ricardo Ribalda]

Hi Linus

On Mon, 23 Feb 2026 at 17:36, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Mon, 23 Feb 2026 at 08:19, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > Argh. The culprit is the use of __VA_OPT__, which apparently sparse
> > never got taught.
> >    [...]
> > Ho humm. I guess I should look at the sparse pre-processor code,
> > unless somebody already implemented __VA_OPT__ somewhere?
>
> Actually, it looks like Al at least *looked* at doing __VA_OPT__ back
> at the end of last year. In fact, just a couple of months ago I said
> "I'm not sure it buys us much", but that was when I thought it was
> just a standard versions of the gcc ## thing, and before I realized
> how much more convenient it actually is to use.
>
> Al? You know the pre-process.c file a *lot* better than I do, even
> ignoring the fact that it's been fifteen years since I touched it. And
> you presumably already had some thoughts on doing __VA_OPT__?
>
> That said, I can also just make default_gfp() use ## after all. I
> _had_ grepped for __VA_OPT__ in the kernel and decided "we already use
> it", but clearly it's causing some issues.
>
> So instead of <linux/gfp.h> doing
>
>   #define __default_gfp(a,...) a
>   #define default_gfp(...) __default_gfp(__VA_ARGS__ __VA_OPT__(,) GFP_KERNEL)
>
> which I think is fairly straightforward and the "natural" way to do
> things, the kernel can just do
>
>   #define __default_gfp(a,b,...) b
>   #define default_gfp(...) __default_gfp(,##__VA_ARGS__,GFP_KERNEL)
>
> instead, with a dummy empty argument to make the gcc ## trick work.
> It's smaller and denser, so it's actually superior in that sense, even
> if it feels a bit less natural than the __VA_OPT__ model.
>
> Ricardo, can you verify that that trick works for you?

I tried both smatch and sparse and both work fine with your trick.

I also tried to boot it with virtme... That also worked :)

I will try to retrofit your hack into media-ci until it lands in rc.

Thanks


>
> Al, comments?
>
>              Linus



-- 
Ricardo Ribalda

Re: Sparse not supporting kzalloc_obj() and friends

[Linus Torvalds]

On Mon, 23 Feb 2026 at 09:21, Ricardo Ribalda <ribalda@chromium.org> wrote:
>
> I tried both smatch and sparse and both work fine with your trick.
>
> I also tried to boot it with virtme... That also worked :)

Ok, I'll commit it.

What I actually wanted to do originally was the much simpler

  #define default_gfp(...) (GFP_KERNEL,##__VA_ARGS__)

but sadly it causes an endless stream of

    error: left-hand operand of comma expression has no effect
[-Werror=unused-value]

and the tricks to avoid that make the "simple" trick anything but
simple. This would seem to work:

  static inline gfp_t __attribute__((unused)) GFP_DEFAULT(void)
  { return GFP_KERNEL; }
  #define default_gfp(...) (GFP_DEFAULT(),##__VA_ARGS__)

but at that point the existing __default_gfp() macro is simpler, I feel.

Oh well. That "has not effect" was very much the *point* of that
really simple comma operator trick, but I do understand why the
warning exists.

               Linus

Re: Sparse not supporting kzalloc_obj() and friends

[Al Viro]

On Mon, Feb 23, 2026 at 08:35:40AM -0800, Linus Torvalds wrote:

> instead, with a dummy empty argument to make the gcc ## trick work.
> It's smaller and denser, so it's actually superior in that sense, even
> if it feels a bit less natural than the __VA_OPT__ model.
> 
> Ricardo, can you verify that that trick works for you?
> 
> Al, comments?

I'll resurrect that branch and post it - hopefully would get something
usable by the weekend.  The main stumbling point had been getting
the interplay with side effects of expansion right - both the __COUNTER__
mess (gccism, with nothing resembling a clear semantics) *and*
the possibility of failure in expansion that had been attempted for no
reason.  Example of the latter:

#define A(X) X
#define B A(
#define Z(X,...) __VA_OPT__(X)
Z(B)

Use of Z obviously has empty vararg (not just after expansion - there's
nothing to expand).  So that __VA_OPT__(X) in its body should be
expanded to an empty token list, _without_ ever expanding the token
list (X) under __VA_OPT__.

Attempt to expand it would fail - it gets to A(, i.e. to use of
a function-like macro with unterminated argument list.

C23 is pretty clear about *not* trying to expand X in that example;
clang handles it correctly, gcc fails.  Reported to gcc bugzilla,
got pretty much no response, then got sidetracked ;-/