archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <>
To: Guenter Roeck <>,
	Shuah Khan <>,
	 David Gow <>,
	Brendan Higgins <>,
	 Rae Moar <>
Cc: "Linux Kernel Mailing List" <>,
	"Matthew Auld" <>,
	"Arunpravin Paneer Selvam" <>,
	"Christian König" <>,
	"kselftest list" <>,
	"KUnit Development" <>
Subject: Re: Linux 6.8-rc5
Date: Tue, 20 Feb 2024 12:16:01 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Tue, 20 Feb 2024 at 11:57, Linus Torvalds
<> wrote:
> It turns out that that commit is buggy for another reason, but it's
> hidden by the fact that apparently KUNIT_ASSERT_FALSE_MSG() doesn't
> check the format string.

The fix for that is this:

  --- a/include/kunit/test.h
  +++ b/include/kunit/test.h
  @@ -579,7 +579,7 @@ void __printf(2, 3) kunit_log_append(struct
string_stream *log, const char *fmt,

   void __noreturn __kunit_abort(struct kunit *test);

  -void __kunit_do_failed_assertion(struct kunit *test,
  +void __printf(6,7) __kunit_do_failed_assertion(struct kunit *test,
                                 const struct kunit_loc *loc,
                                 enum kunit_assert_type type,
                                 const struct kunit_assert *assert,

but that causes a *lot* of noise (not just in drm_buddy_test.c), so
I'm not going to apply that fix as-is. Clearly there's a lot of
incorrect format parameters that have never been checked.

Instead adding Shuah and the KUnit people to the participants, and
hoping that they will fix this up and we can get the format fixes for
KUnit in the 6.9 timeframe.

Side note: when I apply the above patch, the suggestions gcc spews out
look invalid. Gcc seems to suggest turning a a format string of '%d"
to "%ld" for a size_t variable. That's wrong. It should be "%zu".

A 'size_t' can in fact be 'unsigned int' on some platforms (not just
in theory), so %ld is really incorrect not just from a sign

Anyway, I guess I will commit the immediate drm_buddy_test.c fix to
get rid of the build issue, but the KUnit message format string issue
will have to be a "let's get this fixed up _later_" issue.


  reply	other threads:[~2024-02-20 20:16 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-18 21:13 Linux 6.8-rc5 Linus Torvalds
2024-02-19  8:07 ` Build regressions/improvements in v6.8-rc5 Geert Uytterhoeven
2024-02-19  9:54   ` Geert Uytterhoeven
2024-02-19  8:12 ` Geert Uytterhoeven
2024-02-20 19:08 ` Linux 6.8-rc5 Guenter Roeck
2024-02-20 19:57   ` Linus Torvalds
2024-02-20 20:16     ` Linus Torvalds [this message]
2024-02-20 23:07       ` Shuah Khan
2024-02-20 20:37     ` Linus Torvalds
2024-02-20 20:51     ` Geert Uytterhoeven
2024-02-20 21:48     ` Guenter Roeck
2024-02-20 22:02       ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).