[GIT PULL] Modules changes for v6.17-rc1

[GIT PULL] Modules changes for v6.17-rc1

[Daniel Gomez]

The following changes since commit 260f6f4fda93c8485c8037865c941b42b9cba5d2:

  Merge tag 'drm-next-2025-07-30' of https://gitlab.freedesktop.org/drm/kernel (2025-07-30 19:26:49 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/modules/linux.git/ tags/modules-6.17-rc1

for you to fetch changes up to 40a826bd6c82ae45cfd3a19cd2a60a10f56b74c0:

  module: Rename MAX_PARAM_PREFIX_LEN to __MODULE_NAME_LEN (2025-07-31 13:57:47 +0200)

----------------------------------------------------------------
This is a small set of changes for modules, primarily to extend module users
to use the module data structures in combination with the already no-op stub
module functions, even when support for modules is disabled in the kernel
configuration. This change follows the kernel's coding style for conditional
compilation and allows kunit code to drop all CONFIG_MODULES ifdefs, which is
also part of the changes. This should allow others part of the kernel to do the
same cleanup.

Note that this had a conflict with sysctl changes [1] but should be fixed now as I
rebased on top.

The remaining changes include a fix for module name length handling which could
potentially lead to the removal of an incorrect module, and various cleanups.

The module name fix and related cleanup has been in linux-next since Thursday
(July 31) while the rest of the changes for a bit more than 3 weeks.

Note that this currently has conflicts in next with kbuild's tree [2].

Link: https://lore.kernel.org/all/20250714175916.774e6d79@canb.auug.org.au/ [1]
Link: https://lore.kernel.org/all/20250801132941.6815d93d@canb.auug.org.au/ [2]

----------------------------------------------------------------
Petr Pavlu (5):
      module: Prevent silent truncation of module name in delete_module(2)
      module: Remove unnecessary +1 from last_unloaded_module::name size
      module: Restore the moduleparam prefix length check
      tracing: Replace MAX_PARAM_PREFIX_LEN with MODULE_NAME_LEN
      module: Rename MAX_PARAM_PREFIX_LEN to __MODULE_NAME_LEN

Thomas Weißschuh (3):
      module: move 'struct module_use' to internal.h
      module: make structure definitions always visible
      kunit: test: Drop CONFIG_MODULE ifdeffery

 include/linux/module.h      | 29 +++++++++++------------------
 include/linux/moduleparam.h | 15 +++++++++------
 kernel/module/internal.h    |  7 +++++++
 kernel/module/main.c        | 12 +++++++-----
 kernel/trace/trace.c        |  2 +-
 lib/kunit/test.c            |  8 --------
 6 files changed, 35 insertions(+), 38 deletions(-)

Re: [GIT PULL] Modules changes for v6.17-rc1

[Linus Torvalds]

On Sun, 3 Aug 2025 at 06:18, Daniel Gomez <da.gomez@kernel.org> wrote:
>
> Note that this had a conflict with sysctl changes [1] but should be fixed now as I
> rebased on top.

Christ people.

Read the documentation and *years* of me sending out emails about what
maintainers should do. Conflicts are *not* a reason to rebase.

See

   Documentation/maintainer/rebasing-and-merging.rst

and read it. Read it twice. Then read it again until you really *UNDERSTAND* it.

I deal with conflicts all the time, and that was a particularly
_trivial_ one. I'd *much* rather see a conflict and know that "yeah,
we had people working in the same area this time around" than have it
hidden by a rebase that also invalidates all the testing it got
pre-rebase.

And yes, that "invalidates all the testing" is not just some
theoretical thing. We've literally had situations where tested code
became "oops, now it doesn't work because we rebased it on top of a
tree that had different assumptions".

Is that common? No. But it's just one - of many - reasons not to
rebase, and "it had a conflict" is *NOT* a big enough reason to then
think that rebasing is better.

So "it has a conflict" is real information about the development
process, and shouldn't be hidden.

Yes, there are conflicts that are *so* painful that rebasing things is
worth it. This was not it.

And this rebase was particularly bad. You did *everything* wrong. Not
only was there not a good reason for it, you picked a starting point
that is KNOWN BUGGY AND BOOTS TO A BLACK SCREEN ON MY MACHINE. So now
your new work is basically built on top of something known broken, and
as a result, all *your*  commits are known broken too, even if that
breakage isn't due to those commits themselves.

So your rebased state is all built on a base of sand, instead of
something good and stable. And if somebody ends up having to bisect
this because of something it introduces (or even just happens to
bisect into this area for some *unrelated* reason), you picking that
random - and bad - base means that now that bisection is potentially
much more painful than it needed to be.

And yes, this is also talked about in the documentation:

  "If you must reparent a repository, do not pick some random kernel commit
   as the new base.  The kernel is often in a relatively unstable state
   between release points; basing development on one of those points
   increases the chances of running into surprising bugs.  When a patch
   series must move to a new base, pick a stable point (such as one of
   the -rc releases) to move to"

I've pulled this, because I'm flying out tomorrow, and it otherwise
looks fairly simple and straightforward.

But dammit. DO NOT MINDLESSLY REBASE YOUR TREES!

               Linus

Re: [GIT PULL] Modules changes for v6.17-rc1

[pr-tracker-bot]

The pull request you sent on Sun,  3 Aug 2025 15:18:07 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/modules/linux.git/ tags/modules-6.17-rc1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8877fcb70fd7ae0a4d5ac73d250dc255f7ff5a2c

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html