Modules updates for v5.17-rc1

Modules updates for v5.17-rc1

[Luis Chamberlain]

Hi Linus,

Here are the modules changes for v5.17-rc1. This is my second pull
request to you, the first one was for v5.16-rc1. Hopefully this time
around this all looks good now, otherwise please let me know and I'll
be sure to tidy up more.

The following changes since commit daadb3bd0e8d3e317e36bc2c1542e86c528665e5:

  Merge tag 'locking_core_for_v5.17_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (2022-01-11 17:24:45 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git modules-next

for you to fetch changes up to a97ac8cb24a3c3ad74794adb83717ef1605d1b47:

  module: fix signature check failures when using in-kernel decompression (2022-01-14 09:40:49 -0800)

----------------------------------------------------------------
Colin Ian King (1):
      kernel: Fix spelling mistake "compresser" -> "compressor"

Dmitry Torokhov (2):
      module: add in-kernel support for decompressing
      module: fix signature check failures when using in-kernel decompression

Greg Kroah-Hartman (1):
      module.h: allow #define strings to work with MODULE_IMPORT_NS

Jessica Yu (1):
      MAINTAINERS: Remove myself as modules maintainer

Luis Chamberlain (1):
      MAINTAINERS: add mailing lists for kmod and modules

Yu Chen (1):
      module: Remove outdated comment

 MAINTAINERS                 |   6 +-
 include/linux/module.h      |   3 +-
 include/uapi/linux/module.h |   1 +
 init/Kconfig                |  13 +++
 kernel/Makefile             |   1 +
 kernel/module-internal.h    |  19 ++++
 kernel/module.c             |  45 +++++---
 kernel/module_decompress.c  | 271 ++++++++++++++++++++++++++++++++++++++++++++
 8 files changed, 340 insertions(+), 19 deletions(-)
 create mode 100644 kernel/module_decompress.c

----------------------------------------------------------------

modules changes for v5.17-rc1

The biggest change here is in-kernel support for module decompression.
This change is being made to help support LSMs like LoadPin as otherwise
it loses link between the source of kernel module on the disk and binary
blob that is being loaded into the kernel.

kmod decompression is still done by userspace even with this is done,
both because there are no measurable gains in not doing so and as it
adds a secondary extra check for validating the module before loading it
into the kernel.

Although this change was only merged on January 11th, the patches have
been being reviewed since early december. There was at least one fix
already found for it and merged.

The rest of the changes are minor, the only other change worth mentionin
there is Jessica Yu is now bowing out of maintenance of modules as she's
taking a break from work.

While there were other changes posted for modules, those have not yet
received much review of testing so I'm not yet comfortable in merging
any of those changes yet.

Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>

  Luis

Re: Modules updates for v5.17-rc1

[Linus Torvalds]

On Sat, Jan 15, 2022 at 2:20 AM Luis Chamberlain <mcgrof@kernel.org> wrote:
>
> Although this change was only merged on January 11th, the patches have
> been being reviewed since early december. There was at least one fix
> already found for it and merged.

Grr..

And that's exactly why it matters not about "being reviewed", but when
they were in linux-next etc.

I've pulled this, but consider this a complaint. Things should not be
"reviewed" before the merge window. They should be ready and merged
and have actually seen some testing.

Review is good. But nothing beats actually being out there and
actually seeing real-life testing (of course, linux-next probably
mostly gets build-testing, but what testing it gets is still better
than not being there).

               Linus

Re: Modules updates for v5.17-rc1

[Luis Chamberlain]

On Mon, Jan 17, 2022 at 07:38:25AM +0200, Linus Torvalds wrote:
> On Sat, Jan 15, 2022 at 2:20 AM Luis Chamberlain <mcgrof@kernel.org> wrote:
> >
> > Although this change was only merged on January 11th, the patches have
> > been being reviewed since early december. There was at least one fix
> > already found for it and merged.
> 
> Grr..
> 
> And that's exactly why it matters not about "being reviewed", but when
> they were in linux-next etc.
> 
> I've pulled this, but consider this a complaint. Things should not be
> "reviewed" before the merge window. They should be ready and merged
> and have actually seen some testing.
> 
> Review is good. But nothing beats actually being out there and
> actually seeing real-life testing (of course, linux-next probably
> mostly gets build-testing, but what testing it gets is still better
> than not being there).

Understood, that gives me a better ballpark idea of when to defer
things for a next release. Thanks for the feedback.

  Luis