linux-toradex.git/include/linux/module.h, branch v6.0-rc1

kunit: flatten kunit_suite* to kunit_suite in .kunit_test_suites

2022-07-11T23:13:15+00:00

We currently store kunit suites in the .kunit_test_suites ELF section as
a `struct kunit_suite***` (modulo some `const`s).
For every test file, we store a struct kunit_suite** NULL-terminated array.

This adds quite a bit of complexity to the test filtering code in the
executor.

Instead, let's just make the .kunit_test_suites section contain a single
giant array of struct kunit_suite pointers, which can then be directly
manipulated. This array is not NULL-terminated, and so none of the test
filtering code needs to NULL-terminate anything.

Tested-by: Maíra Canal 
Reviewed-by: Brendan Higgins 
Signed-off-by: Daniel Latypov 
Co-developed-by: David Gow 
Signed-off-by: David Gow 
Signed-off-by: Shuah Khan

kunit: unify module and builtin suite definitions

2022-07-11T23:13:09+00:00

Currently, KUnit runs built-in tests and tests loaded from modules
differently. For built-in tests, the kunit_test_suite{,s}() macro adds a
list of suites in the .kunit_test_suites linker section. However, for
kernel modules, a module_init() function is used to run the test suites.

This causes problems if tests are included in a module which already
defines module_init/exit_module functions, as they'll conflict with the
kunit-provided ones.

This change removes the kunit-defined module inits, and instead parses
the kunit tests from their own section in the module. After module init,
we call __kunit_test_suites_init() on the contents of that section,
which prepares and runs the suite.

This essentially unifies the module- and non-module kunit init formats.

Tested-by: Maíra Canal 
Reviewed-by: Brendan Higgins 
Signed-off-by: Jeremy Kerr 
Signed-off-by: Daniel Latypov 
Signed-off-by: David Gow 
Signed-off-by: Shuah Khan

module.h: simplify MODULE_IMPORT_NS

2022-05-12T17:29:41+00:00

In commit ca321ec74322 ("module.h: allow #define strings to work with
MODULE_IMPORT_NS") I fixed up the MODULE_IMPORT_NS() macro to allow
defined strings to work with it.  Unfortunatly I did it in a two-stage
process, when it could just be done with the __stringify() macro as
pointed out by Masahiro Yamada.

Clean this up to only be one macro instead of two steps to achieve the
same end result.

Fixes: ca321ec74322 ("module.h: allow #define strings to work with MODULE_IMPORT_NS")
Reported-by: Masahiro Yamada 
Cc: Luis Chamberlain 
Cc: Jessica Yu 
Cc: Matthias Maennich 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Luis Chamberlain

module: Add CONFIG_ARCH_WANTS_MODULES_DATA_IN_VMALLOC

2022-04-05T15:43:05+00:00

Add CONFIG_ARCH_WANTS_MODULES_DATA_IN_VMALLOC to allow architectures
to request having modules data in vmalloc area instead of module area.

This is required on powerpc book3s/32 in order to set data non
executable, because it is not possible to set executability on page
basis, this is done per 256 Mbytes segments. The module area has exec
right, vmalloc area has noexec.

This can also be useful on other powerpc/32 in order to maximize the
chance of code being close enough to kernel core to avoid branch
trampolines.

Cc: Jason Wessel 
Acked-by: Daniel Thompson 
Cc: Douglas Anderson 
Signed-off-by: Christophe Leroy 
[mcgrof: rebased in light of kernel/module/kdb.c move]
Signed-off-by: Luis Chamberlain

module: Move extra signature support out of core code

2022-04-05T15:43:04+00:00

No functional change.

This patch migrates additional module signature check
code from core module code into kernel/module/signing.c.

Reviewed-by: Christophe Leroy 
Signed-off-by: Aaron Tomlin 
Signed-off-by: Luis Chamberlain

module: Move livepatch support to a separate file

2022-04-05T15:43:04+00:00

No functional change.

This patch migrates livepatch support (i.e. used during module
add/or load and remove/or deletion) from core module code into
kernel/module/livepatch.c. At the moment it contains code to
persist Elf information about a given livepatch module, only.
The new file was added to MAINTAINERS.

Reviewed-by: Petr Mladek 
Tested-by: Petr Mladek 
Signed-off-by: Aaron Tomlin 
Signed-off-by: Luis Chamberlain

Merge branch 'modules-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux

2022-01-17T05:32:51+00:00

Pull module updates from Luis Chamberlain:
 "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.

  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."

* 'modules-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux:
  module: fix signature check failures when using in-kernel decompression
  kernel: Fix spelling mistake "compresser" -> "compressor"
  MAINTAINERS: add mailing lists for kmod and modules
  module.h: allow #define strings to work with MODULE_IMPORT_NS
  module: add in-kernel support for decompressing
  MAINTAINERS: Remove myself as modules maintainer
  module: Remove outdated comment

module.h: allow #define strings to work with MODULE_IMPORT_NS

2022-01-12T03:11:09+00:00

The MODULE_IMPORT_NS() macro does not allow defined strings to work
properly with it, so add a layer of indirection to allow this to happen.

Cc: Luis Chamberlain 
Cc: Jessica Yu 
Cc: Matthias Maennich 
Signed-off-by: Greg Kroah-Hartman 
Reviewed-by: Matthias Maennich 
Signed-off-by: Luis Chamberlain

exit: Rename module_put_and_exit to module_put_and_kthread_exit

2021-12-13T18:04:45+00:00

Update module_put_and_exit to call kthread_exit instead of do_exit.

Change the name to reflect this change in functionality.  All of the
users of module_put_and_exit are causing the current kthread to exit
so this change makes it clear what is happening.  There is no
functional change.

Signed-off-by: "Eric W. Biederman"

printk: Userspace format indexing support

2021-07-19T09:57:48+00:00

We have a number of systems industry-wide that have a subset of their
functionality that works as follows:

1. Receive a message from local kmsg, serial console, or netconsole;
2. Apply a set of rules to classify the message;
3. Do something based on this classification (like scheduling a
   remediation for the machine), rinse, and repeat.

As a couple of examples of places we have this implemented just inside
Facebook, although this isn't a Facebook-specific problem, we have this
inside our netconsole processing (for alarm classification), and as part
of our machine health checking. We use these messages to determine
fairly important metrics around production health, and it's important
that we get them right.

While for some kinds of issues we have counters, tracepoints, or metrics
with a stable interface which can reliably indicate the issue, in order
to react to production issues quickly we need to work with the interface
which most kernel developers naturally use when developing: printk.

Most production issues come from unexpected phenomena, and as such
usually the code in question doesn't have easily usable tracepoints or
other counters available for the specific problem being mitigated. We
have a number of lines of monitoring defence against problems in
production (host metrics, process metrics, service metrics, etc), and
where it's not feasible to reliably monitor at another level, this kind
of pragmatic netconsole monitoring is essential.

As one would expect, monitoring using printk is rather brittle for a
number of reasons -- most notably that the message might disappear
entirely in a new version of the kernel, or that the message may change
in some way that the regex or other classification methods start to
silently fail.

One factor that makes this even harder is that, under normal operation,
many of these messages are never expected to be hit. For example, there
may be a rare hardware bug which one wants to detect if it was to ever
happen again, but its recurrence is not likely or anticipated. This
precludes using something like checking whether the printk in question
was printed somewhere fleetwide recently to determine whether the
message in question is still present or not, since we don't anticipate
that it should be printed anywhere, but still need to monitor for its
future presence in the long-term.

This class of issue has happened on a number of occasions, causing
unhealthy machines with hardware issues to remain in production for
longer than ideal. As a recent example, some monitoring around
blk_update_request fell out of date and caused semi-broken machines to
remain in production for longer than would be desirable.

Searching through the codebase to find the message is also extremely
fragile, because many of the messages are further constructed beyond
their callsite (eg. btrfs_printk and other module-specific wrappers,
each with their own functionality). Even if they aren't, guessing the
format and formulation of the underlying message based on the aesthetics
of the message emitted is not a recipe for success at scale, and our
previous issues with fleetwide machine health checking demonstrate as
much.

This provides a solution to the issue of silently changed or deleted
printks: we record pointers to all printk format strings known at
compile time into a new .printk_index section, both in vmlinux and
modules. At runtime, this can then be iterated by looking at
/printk/index/, which emits the following format, both
readable by humans and able to be parsed by machines:

    $ head -1 vmlinux; shuf -n 5 vmlinux
    #  filename:line function "format"
    <5> block/blk-settings.c:661 disk_stack_limits "%s: Warning: Device %s is misaligned\n"
    <4> kernel/trace/trace.c:8296 trace_create_file "Could not create tracefs '%s' entry\n"
    <6> arch/x86/kernel/hpet.c:144 _hpet_print_config "hpet: %s(%d):\n"
    <6> init/do_mounts.c:605 prepare_namespace "Waiting for root device %s...\n"
    <6> drivers/acpi/osl.c:1410 acpi_no_auto_serialize_setup "ACPI: auto-serialization disabled\n"

This mitigates the majority of cases where we have a highly-specific
printk which we want to match on, as we can now enumerate and check
whether the format changed or the printk callsite disappeared entirely
in userspace. This allows us to catch changes to printks we monitor
earlier and decide what to do about it before it becomes problematic.

There is no additional runtime cost for printk callers or printk itself,
and the assembly generated is exactly the same.

Signed-off-by: Chris Down 
Cc: Petr Mladek 
Cc: Jessica Yu 
Cc: Sergey Senozhatsky 
Cc: John Ogness 
Cc: Steven Rostedt 
Cc: Greg Kroah-Hartman 
Cc: Johannes Weiner 
Cc: Kees Cook 
Reviewed-by: Petr Mladek 
Tested-by: Petr Mladek 
Reported-by: kernel test robot 
Acked-by: Andy Shevchenko 
Acked-by: Jessica Yu  # for module.{c,h}
Signed-off-by: Petr Mladek 
Link: https://lore.kernel.org/r/e42070983637ac5e384f17fbdbe86d19c7b212a5.1623775748.git.chris@chrisdown.name