From: Herton R. Krzesinski on gitlab.com Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/3700 Our packaging for some time has shipped modules compressed with xz. These are decompressed by modprobe/kmod on userspace, then provided to the kernel. However, the kernel for some time now supports in-kernel decompression since the change b1ae6dc41eaa ("module: add in-kernel support for decompressing"). Doing in kernel decompression is better as pointed out by Andrew Zaborowski in RHEL-79278: it allows kmod to use the finit_module() syscall, which allows the kernel to better detect concurrent loading of modules preventing spikes in usage of memory/vmalloc memory. The prevention of memory spikes/usage in concurrent module loading was handled by Linus in commit 9b9879fc0327 ("modules: catch concurrent module loads, treat them as idempotent"). But we are not able to take advantage of this fix if we don't have in kernel decompression of modules enabled, since kmod will not use finit_module() as the module is compressed and it fallbacks to init_module(). Thus, make sure we enable in-kernel decompression of modules, which requires to enable MODULE_COMPRESS: the key here is to keep MODULE_COMPRESS_ALL disabled, which allows us to keep our current build infra-structure/spec file untouched, since we build and compress the modules by ourselves and in the proper order required due module signing. At the same time, it should allow external modules to continue to be built without interference of enabling compress/decompress. Signed-off-by: Herton R. Krzesinski <herton@xxxxxxxxxx> --- redhat/configs/common/generic/CONFIG_MODULE_COMPRESS | 2 +- redhat/configs/common/generic/CONFIG_MODULE_COMPRESS_ALL | 1 + redhat/configs/common/generic/CONFIG_MODULE_COMPRESS_NONE | 1 - redhat/configs/common/generic/CONFIG_MODULE_COMPRESS_XZ | 2 +- redhat/configs/common/generic/CONFIG_MODULE_DECOMPRESS | 1 + redhat/kernel.spec.template | 2 +- 6 files changed, 5 insertions(+), 4 deletions(-) -- _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
