Message-ID: <CAJ-ks9ntXroeNjUft9DNbhtU3NMnDxX-UDoV+O6818c0o1+ujw@mail.gmail.com>
Date: Fri, 16 Jan 2026 11:26:22 -0500
From: Tamir Duberstein <tamird@...nel.org>
To: Petr Mladek <pmladek@...e.com>
Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, Steven Rostedt <rostedt@...dmis.org>, 
	Rasmus Villemoes <linux@...musvillemoes.dk>, Sergey Senozhatsky <senozhatsky@...omium.org>, 
	Kees Cook <kees@...nel.org>, linux-kernel@...r.kernel.org, 
	oe-kbuild-all@...ts.linux.dev, kernel test robot <lkp@...el.com>
Subject: Re: [PATCH] printf: add __printf attribute

On Fri, Jan 16, 2026 at 4:32 AM Petr Mladek <pmladek@...e.com> wrote:
>
> On Thu 2026-01-15 09:53:37, Tamir Duberstein wrote:
> > On Tue, Dec 16, 2025 at 5:13 AM Petr Mladek <pmladek@...e.com> wrote:
> > >
> > > On Mon 2025-12-08 16:07:28, Tamir Duberstein wrote:
> > > > On Mon, Dec 8, 2025 at 9:06 AM Petr Mladek <pmladek@...e.com> wrote:
> > > > >
> > > > > On Mon 2025-12-08 15:30:53, Andy Shevchenko wrote:
> > > > > > On Sun, Dec 07, 2025 at 08:32:53PM -0500, Tamir Duberstein wrote:
> > > > > > > On Sat, Dec 6, 2025 at 4:45 PM Andy Shevchenko
> > > > > > > <andriy.shevchenko@...ux.intel.com> wrote:
> > > > > > > > On Sat, Dec 06, 2025 at 02:57:48PM -0500, Tamir Duberstein wrote:
> > > > > > > > > On Sat, Dec 6, 2025 at 2:43 PM Andy Shevchenko
> > > > > > > > > <andriy.shevchenko@...ux.intel.com> wrote:
> > > > > > > > > > On Sat, Dec 06, 2025 at 12:52:53PM -0500, Tamir Duberstein wrote:
> > > > > > > > > > > On Sat, Dec 6, 2025 at 12:49 PM Andy Shevchenko
> > > > > > > > > > > <andriy.shevchenko@...ux.intel.com> wrote:
> > > > > > > > > > > > On Sat, Dec 06, 2025 at 12:13:34PM -0500, Tamir Duberstein wrote:
> > > > > > > > > > > > > On Sat, Dec 6, 2025 at 11:11 AM Andy Shevchenko
> > > > > > > > > > > > > <andriy.shevchenko@...ux.intel.com> wrote:
> > > > > > > > > > > > > > On Sat, Dec 06, 2025 at 08:19:09AM -0500, Tamir Duberstein wrote:
> > > > > >
> > > > > > ...
> > > > > >
> > > > > > > > > > > > > > > -static void
> > > > > > > > > > > > > > > +static void __printf(2, 3)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 3?!
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I think it should be (2, 0). Yes, the both users call it with "%p..." in format
> > > > > > > > > > > > > > string, but the second parameter tells compiler to check the variadic
> > > > > > > > > > > > > > arguments, which are absent here. Changing 'const void *p' to '...' will align
> > > > > > > > > > > > > > it with the given __printf() attribute, but I don't know if this what we want.
> > > > > > > > > > > > >
> > > > > > > > > > > > > The second parameter is the first-to-check, it is not specific to
> > > > > > > > > > > > > variadic arguments. Using 0 means that no arguments are checkable, so
> > > > > > > > > > > > > the compiler only validates the format string itself and won’t
> > > > > > > > > > > > > diagnose mismatches with `p`. This works whether or not we later
> > > > > > > > > > > > > change `const void *p` to `...`.
> > > > > > > > > > > >
> > > > > > > > > > > > Yes, but this is fragile. As I explained it works only because we supply
> > > > > > > > > > > > the format string stuck to "%p", anything else will require reconsidering
> > > > > > > > > > > > the function prototypes. So, strictly speaking this should be (2, 0) if
> > > > > > > > > > > > we leave const void *p as is.
> > > > > > > > > > > >
> > > > > > > > > > > I believe this is not correct. As I said, 0 means "do not check
> > > > > > > > > > > arguments" so only the format string will be checked. See the existing
> > > > > > > > > > > uses of this annotation in this file:
> > > > > > > > > > >
> > > > > > > > > > > static void __printf(7, 0)
> > > > > > > > > > > do_test(struct kunit *kunittest, const char *file, const int line, int
> > > > > > > > > > > bufsize, const char *expect,
> > > > > > > > > > > int elen, const char *fmt, va_list ap)
> > > > > > > > > > >
> > > > > > > > > > > and
> > > > > > > > > > >
> > > > > > > > > > > static void __printf(6, 7)
> > > > > > > > > > > __test(struct kunit *kunittest, const char *file, const int line,
> > > > > > > > > > > const char *expect, int elen,
> > > > > > > > > > > const char *fmt, ...)
> > > > > > > >
> > > > > > > Since it doesn't make much sense to make this function variadic, I
> > > > > > > think the best we can do is a macro wrapper that combines this
> > > > > > > function with `no_printk`. Something like
> > > > > > >
> > > > > > > #define test_hashed(kunittest, fmt, p) \
> > > > > > > do { \
> > > > > > > if (0) \
> > > > > > > no_printk(fmt, p); \
> > > > > > > __test_hashed(kunittest, fmt, p);\
> > > > > > > } while (0)
> > > > > >
> > > > >
> > > > > IMHO, this is is not worth it. test_hashed(kunittest, fmt, p) calls
> > > > > test(buf, fmt, p). It goes down to __test() which does the format
> > > > > check:
> > > > >
> > > > > static void __printf(6, 7)
> > > > > __test(struct kunit *kunittest, const char *file, const int line, const char *expect, int elen,
> > > > >         const char *fmt, ...)
> > > > >
> > > > >
> > > > > > > That would give us better diagnostics, but is more complex (and more
> > > > > > > lines of code than just repeating this function's body twice, which
> > > > > > > would also give good diagnostics). I think the best thing to do is just
> > > > > > > to ignore the report that prompted me to look into this. Please let me
> > > > > > > know if you disagree.
> > > > > >
> > > > > > I think we may not ignore the report as it breaks builds in some cases.
> > > > > > As I said
> > > > > >
> > > > > > - __printf(2, 0) for now
> > > > > >
> > > > > > - and perhaps a comment on top to explain the clang approach that may cope
> > > > > > with fixed-argument functions for -Wformat (you can even put a link to that
> > > > > > LLVM discussion about the feature).
> > > > >
> > > > > I personally prefer this way. We just need to calm down the warning.
> > > > > The proper check is done by the nested test()...
> > > >
> > > > The nested `__test()` call cannot do the proper check because it cannot
> > > > see the format string. Right?
> > >
> > > IMHO, it does see the format string. It is defined the following way:
> > >
> > > static void __printf(6, 7)
> > > __test(struct kunit *kunittest, const char *file, const int line, const char *expect, int elen,
> > >         const char *fmt, ...)
> > >
> > > #define test(expect, fmt, ...)                                  \
> > >         __test(kunittest, __FILE__, __LINE__, expect, strlen(expect), fmt, ##__VA_ARGS__)
> > >
> > > static void
> > > test_hashed(struct kunit *kunittest, const char *fmt, const void *p)
> > > {
> > >         char buf[PLAIN_BUF_SIZE];
> > >
> > >         plain_hash_to_buffer(kunittest, p, buf, PLAIN_BUF_SIZE);
> > >
> > >         test(buf, fmt, p);
> > > }
> > >
> > >
> > > Now, let's get for example:
> > >
> > >         test_hashed(kunittest, "%p", PTR_INVALID);
> > >
> > > it calls:
> > >
> > >         test(buf, "%p", PTR_INVALID);
> > >
> > > which is exapnded to:
> > >
> > >         __test(kunittest, file, line, buf, strlen(buf), "%p", PTR_INVALID)
> > >
> > > so, it gets the same printf arguments as the original test_hashed,
> > > namely:
> > >
> > >         %p, PTR_INVALID
> > >
> > > Or do I miss anything, please?
> >
> > the problem is that test_hashed is a function, not a macro, so it is
> > not correct to say that
> >
> > test_hashed(kunittest, "%p", PTR_INVALID)
> >
> > is expanded to
> >
> > __test(kunittest, file, line, buf, strlen(buf), "%p", PTR_INVALID)
> >
> > thus the compiler cannot perform any meaningful checking of the
> > test_hashed call.
> >
> > We could make test_hashed a macro, though.
>
> I am sorry but I still think that it is not worth it.
> The proposed changes add more complexity or weird stuff for a little gain.
>
> > > You might argue that it works by chance and that it might change in the
> > > future. But I have hard times to imagine it. test_hashed() is just
> > > a wrapper around "test()". The only purpose is to fill "buf" with
> > > the expected outcome.
> > >
> > > If any refactoring is needed in the future. The __printf() macros
> > > would need some refactoring as well.
>
> IMHO, the above is still valid.

I don't follow this reasoning. Having said that, you're the ultimate
decider on whether this is worth addressing.

I will send v2 with the macro solution so we have it on the list, you
can then decide whether to take it.

The next version will come from my @kernel.org address.

Cheers.
Tamir

Powered by blists - more mailing lists