[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wh-k04MsoEC0SGKff2Snm6bBF_e+0pHOKwaWv4umZ_SnQ@mail.gmail.com>
Date: Sun, 6 Apr 2025 09:50:05 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Damian Tometzki <damian@...cv-rocks.de>, Masahiro Yamada <masahiroy@...nel.org>,
Jeff Johnson <jeff.johnson@....qualcomm.com>, Vlastimil Babka <vbabka@...e.cz>
Cc: Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] Kbuild updates for v6.15-rc1
On Sat, 5 Apr 2025 at 22:43, Damian Tometzki <damian@...cv-rocks.de> wrote:
>
> i got the following error after this pull request.
>
> MODPOST Module.symvers
> ERROR: modpost: missing MODULE_DESCRIPTION() in lib/tests/slub_kunit.o
> make[3]: *** [/home/damian/kernel/linux/scripts/Makefile.modpost:147: Module.symvers] Error 1
> make[2]: *** [/home/damian/kernel/linux/Makefile:1956: modpost] Error 2
> make[1]: *** [/home/damian/kernel/linux/Makefile:248: __sub-make] Error 2
> make[1]: Leaving directory '/home/damian/kernel/build'
> make: *** [Makefile:248: __sub-make] Error 2
Bah. And the reason it doesn't show up in my normal build tests is
that my 'allmodconfig' tests end up picking up SLUB_TINY - which
disables a lot of slub cases, including this test.
And my normal non-allmodconfig tests don't enable SLUB_KUNIT_TEST.
That said, I'm not sure if making it a hard error was a good idea in
the first place. It *used* to be just a warning, and it used to be
enabled only with 'extra_warn'.
So switching it on to always warn was probably a good idea, but then
also making it a hard error may have been a bit excessive.
In related news - I also wonder whether SLUB_TINY should just be
turned off for COMPILE_TEST. It's not a very interesting config option
to test for, and it disables much more code than it enables [*].
Testing this without SLUB_TINY, I see that it *also* triggers this one:
ERROR: modpost: missing MODULE_DESCRIPTION() in mm/kasan/kasan_test.o
so the claim in commit 6c6c1fc09de3 ("modpost: require a
MODULE_DESCRIPTION()") that "all known instances of this issue have
been fixed" is clearly wrong.
For all we know, there are lots of other cases like this that just
never got tested with W=1 at all.
I think I'll downgrade the error() to a warn() again, and make
SLUB_TINY depend on !COMPILE_TEST.
And I'm not even convinced we should require module descriptions for
silly test modules, but whatever.
We'll see if something else pops up, but making the lack of a module
description a fatal error was clearly not right as-is.
Linus
[*] In fact, I'm not convinced SLUB_TINYT ever makes sense at all, but
that may be too unrelated to this to worry about.
Powered by blists - more mailing lists