Mainline: aab1f809d7540def24498e81347740a7239a74d5
From: v6.7-rc3
Severity: Moderate
task: 192231
[ Upstream commit aab1f809d7540def24498e81347740a7239a74d5 ]
For some unknown reason the regular expression for checkstack only matches
three digit numbers starting with the number "3", or any higher
number. Which means that it skips any stack sizes smaller than 304
bytes. This makes the checkstack script a bit less useful than it could be.
Change the script to match any number. To be filtered out stack sizes
can be configured with the min_stack variable, which omits any stack
frame sizes smaller than 100 bytes by default.
Tested-by: Alexander Gordeev <agordeev@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(backported from commit 97774998f8)
K2CI-Arch: None
Signed-off-by: k2ci <kernel-bot@kylinos.cn>
Change-Id: I22ef52d3dc4ced3282be679f5c2d4a4b17d952b8
Reviewed-on: http://gerrit.kylin.com/c/klinux/+/89867
Reviewed-by: Jackie Liu <liuyun01@kylinos.cn>
Mainline: 829649443e78d85db0cff0c37cadb28fbb1a5f6f
From: v6.7-rc6
Severity: Moderate
task: 192231
[ Upstream commit 829649443e78d85db0cff0c37cadb28fbb1a5f6f ]
There are some wrong return values check in sign-file when call OpenSSL
API. The ERR() check cond is wrong because of the program only check the
return value is < 0 which ignored the return val is 0. For example:
1. CMS_final() return 1 for success or 0 for failure.
2. i2d_CMS_bio_stream() returns 1 for success or 0 for failure.
3. i2d_TYPEbio() return 1 for success and 0 for failure.
4. BIO_free() return 1 for success and 0 for failure.
Link: https://www.openssl.org/docs/manmaster/man3/
Fixes: e5a2e3c847 ("scripts/sign-file.c: Add support for signing with a raw signature")
Signed-off-by: Yusong Gao <a869920004@gmail.com>
Reviewed-by: Juerg Haefliger <juerg.haefliger@canonical.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://lore.kernel.org/r/20231213024405.624692-1-a869920004@gmail.com/ # v5
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(backported from commit f18ac4bae1)
K2CI-Arch: None
Signed-off-by: k2ci <kernel-bot@kylinos.cn>
Change-Id: I1c14af8eab0d11eeb3cf5c50bf18d3175e98032a
Reviewed-on: http://gerrit.kylin.com/c/klinux/+/89800
Reviewed-by: Jackie Liu <liuyun01@kylinos.cn>
Mainline: d71f22365a9caca82d424f3a33445de46567e198
From: v6.7-rc4
Severity: Moderate
task: 189525
commit d71f22365a9caca82d424f3a33445de46567e198 upstream.
Update code comment to clarify that the only element whose layout is
not randomized is a proper C99 flexible-array member. This update is
complementary to commit 1ee60356c2dc ("gcc-plugins: randstruct: Only
warn about true flexible arrays")
Signed-off-by: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/ZWJr2MWDjXLHE8ap@work
Fixes: 1ee60356c2dc ("gcc-plugins: randstruct: Only warn about true flexible arrays")
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(backported from commit b79210fa10)
K2CI-Arch: None
Signed-off-by: k2ci <kernel-bot@kylinos.cn>
Change-Id: Ide609cac193e18620fc5c93ece1ed005053c6d35
Reviewed-on: http://gerrit.kylin.com/c/klinux/+/88548
Reviewed-by: Jackie Liu <liuyun01@kylinos.cn>
Mainline: ee34db3f271cea4d4252048617919c2caafe698b
From: v6.7-rc5
Severity: Moderate
task: 189525
commit ee34db3f271cea4d4252048617919c2caafe698b upstream.
All addresses printed by checkstack have an extra incorrect 0 appended at
the end.
This was introduced with commit 677f1410e0 ("scripts/checkstack.pl: don't
display $dre as different entity"): since then the address is taken from
the line which contains the function name, instead of the line which
contains stack consumption. E.g. on s390:
0000000000100a30 <do_one_initcall>:
...
100a44: e3 f0 ff 70 ff 71 lay %r15,-144(%r15)
So the used regex which matches spaces and hexadecimal numbers to extract
an address now matches a different substring. Subsequently replacing spaces
with 0 appends a zero at the and, instead of replacing leading spaces.
Fix this by using the proper regex, and simplify the code a bit.
Link: https://lkml.kernel.org/r/20231120183719.2188479-2-hca@linux.ibm.com
Fixes: 677f1410e0 ("scripts/checkstack.pl: don't display $dre as different entity")
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Cc: Maninder Singh <maninder1.s@samsung.com>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Vaneet Narang <v.narang@samsung.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(backported from commit f8f32f9126)
K2CI-Arch: None
Signed-off-by: k2ci <kernel-bot@kylinos.cn>
Change-Id: Iaeddff763c0946aee2a43a02504a3c432ec56cfe
Reviewed-on: http://gerrit.kylin.com/c/klinux/+/88460
Reviewed-by: Jackie Liu <liuyun01@kylinos.cn>
Mainline: 8f51593cdcab82fb23ef2e1a0010b2e6f99aae02
From: v6.7-rc5
Severity: Moderate
task: 189525
[ Upstream commit 8f51593cdcab82fb23ef2e1a0010b2e6f99aae02 ]
The iglob function, which we use to find C source files in the kernel
tree, always follows symbolic links. This can cause unintentional
recursions whenever a symbolic link points to a parent directory. A
common scenario is building the kernel with the output set to a
directory inside the kernel tree, which will contain such a symlink.
Instead of using the iglob function, use os.walk to traverse the
directory tree, which by default doesn't follow symbolic links. fnmatch
is then used to match the glob on the filename, as well as ignore hidden
files (which were ignored by default with iglob).
This approach runs just as fast as using iglob.
Fixes: b6acf80735 ("dt: Add a check for undocumented compatible strings in kernel")
Reported-by: Aishwarya TCV <aishwarya.tcv@arm.com>
Closes: https://lore.kernel.org/all/e90cb52f-d55b-d3ba-3933-6cc7b43fcfbc@arm.com
Signed-off-by: "Nícolas F. R. A. Prado" <nfraprado@collabora.com>
Link: https://lore.kernel.org/r/20231107225624.9811-1-nfraprado@collabora.com
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(backported from commit 7cb7001ecd)
K2CI-Arch: None
Signed-off-by: k2ci <kernel-bot@kylinos.cn>
Change-Id: I3367aae119105f6b5eb8c92cc9e87665f3e26eea
Reviewed-on: http://gerrit.kylin.com/c/klinux/+/88331
Reviewed-by: Jackie Liu <liuyun01@kylinos.cn>
Mainline: ae1eff0349f2e908fc083630e8441ea6dc434dc0
From: v6.7-rc2
Severity: Moderate
task: 189525
[ Upstream commit ae1eff0349f2e908fc083630e8441ea6dc434dc0 ]
Currently, sym_validate_range() duplicates the range string using
xstrdup(), which is overwritten by a subsequent sym_calc_value() call.
It results in a memory leak.
Instead, only the pointer should be copied.
Below is a test case, with a summary from Valgrind.
[Test Kconfig]
config FOO
int "foo"
range 10 20
[Test .config]
CONFIG_FOO=0
[Before]
LEAK SUMMARY:
definitely lost: 3 bytes in 1 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 0 bytes in 0 blocks
still reachable: 17,465 bytes in 21 blocks
suppressed: 0 bytes in 0 blocks
[After]
LEAK SUMMARY:
definitely lost: 0 bytes in 0 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 0 bytes in 0 blocks
still reachable: 17,462 bytes in 20 blocks
suppressed: 0 bytes in 0 blocks
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(backported from commit b97debd07a)
K2CI-Arch: None
Signed-off-by: k2ci <kernel-bot@kylinos.cn>
Change-Id: I55a3be904fc1d1e9e3cbe40b2bdd39955843721c
Reviewed-on: http://gerrit.kylin.com/c/klinux/+/88320
Reviewed-by: Jackie Liu <liuyun01@kylinos.cn>
Mainline: 1c4a7587d1bbee0fd53b63af60e4244a62775f57
From: v6.7-rc2
Severity: Moderate
task: 189525
[ Upstream commit 1c4a7587d1bbee0fd53b63af60e4244a62775f57 ]
The section mismatch check prints a bogus symbol name on some
architectures.
[test code]
#include <linux/init.h>
int __initdata foo;
int get_foo(void) { return foo; }
If you compile it with GCC for riscv or loongarch, modpost will show an
incorrect symbol name:
WARNING: modpost: vmlinux: section mismatch in reference: get_foo+0x8 (section: .text) -> done (section: .init.data)
To get the correct symbol address, the st_value must be added.
This issue has never been noticed since commit 93684d3b80 ("kbuild:
include symbol names in section mismatch warnings") presumably because
st_value becomes zero on most architectures when the referenced symbol
is looked up. It is not true for riscv or loongarch, at least.
With this fix, modpost will show the correct symbol name:
WARNING: modpost: vmlinux: section mismatch in reference: get_foo+0x8 (section: .text) -> foo (section: .init.data)
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(backported from commit b1205cc72b)
K2CI-Arch: None
Signed-off-by: k2ci <kernel-bot@kylinos.cn>
Change-Id: Iff7ddefdb70bc259c78766ac0b1a582e9df96876
Reviewed-on: http://gerrit.kylin.com/c/klinux/+/88319
Reviewed-by: Jackie Liu <liuyun01@kylinos.cn>
Mainline: 6620999f0d41e4fd6f047727936a964c3399d249
From: v6.7-rc1
Severity: Moderate
task: 186574
commit 6620999f0d41e4fd6f047727936a964c3399d249 upstream.
vmap_area does not exist on no-MMU, therefore the GDB scripts fail to
load:
Traceback (most recent call last):
File "<...>/vmlinux-gdb.py", line 51, in <module>
import linux.vmalloc
File "<...>/scripts/gdb/linux/vmalloc.py", line 14, in <module>
vmap_area_ptr_type = vmap_area_type.get_type().pointer()
^^^^^^^^^^^^^^^^^^^^^^^^^
File "<...>/scripts/gdb/linux/utils.py", line 28, in get_type
self._type = gdb.lookup_type(self._name)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
gdb.error: No struct type named vmap_area.
To fix this, disable the command and add an informative error message if
CONFIG_MMU is not defined, following the example of lx-slabinfo.
Link: https://lkml.kernel.org/r/20231031202235.2655333-2-ben.wolsieffer@hefring.com
Fixes: 852622bf36 ("scripts/gdb/vmalloc: add vmallocinfo support")
Signed-off-by: Ben Wolsieffer <ben.wolsieffer@hefring.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Kieran Bingham <kbingham@kernel.org>
Cc: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(backported from commit 08c52a25fa)
K2CI-Arch: None
Signed-off-by: k2ci <kernel-bot@kylinos.cn>
Change-Id: Id603a83e627de19abfb50b6821d9ab535100ed68
Reviewed-on: http://gerrit.kylin.com/c/klinux/+/85668
Reviewed-by: Jackie Liu <liuyun01@kylinos.cn>
Mainline: 2d7ce49f58dc95495b3e22e45d2be7de909b2c63
From: v6.7-rc1
Severity: Moderate
task: 186574
[ Upstream commit 2d7ce49f58dc95495b3e22e45d2be7de909b2c63 ]
Enabling CONFIG_KCSAN leads to unconverted, default return thunks to
remain after patching.
As David Kaplan describes in his debugging of the issue, it is caused by
a couple of KCSAN-generated constructors which aren't processed by
objtool:
"When KCSAN is enabled, GCC generates lots of constructor functions
named _sub_I_00099_0 which call __tsan_init and then return. The
returns in these are generally annotated normally by objtool and fixed
up at runtime. But objtool runs on vmlinux.o and vmlinux.o does not
include a couple of object files that are in vmlinux, like
init/version-timestamp.o and .vmlinux.export.o, both of which contain
_sub_I_00099_0 functions. As a result, the returns in these functions
are not annotated, and the panic occurs when we call one of them in
do_ctors and it uses the default return thunk.
This difference can be seen by counting the number of these functions in the object files:
$ objdump -d vmlinux.o|grep -c "<_sub_I_00099_0>:"
2601
$ objdump -d vmlinux|grep -c "<_sub_I_00099_0>:"
2603
If these functions are only run during kernel boot, there is no
speculation concern."
Fix it by disabling KCSAN on version-timestamp.o and .vmlinux.export.o
so the extra functions don't get generated. KASAN and GCOV are already
disabled for those files.
[ bp: Massage commit message. ]
Closes: https://lore.kernel.org/lkml/20231016214810.GA3942238@dev-arch.thelio-3990X/
Reported-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Acked-by: Marco Elver <elver@google.com>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20231017165946.v4i2d4exyqwqq3bx@treble
Signed-off-by: Sasha Levin <sashal@kernel.org>
(backported from commit e2d8abf5af)
K2CI-Arch: None
Signed-off-by: k2ci <kernel-bot@kylinos.cn>
Change-Id: If188f5be8e5e8101865df1edd317685cdd79f662
Reviewed-on: http://gerrit.kylin.com/c/klinux/+/85309
Reviewed-by: Jackie Liu <liuyun01@kylinos.cn>
Mainline: KYLIN-only
Severity: Low
The current search logic only allows commits carrying the Mainline field
to be searched. In fact, the correct logic should be to convert to
Upstream if a Mainline is found. If there is no Mainline, just use the
given commit id directly.
K2CI-Arch: None
Signed-off-by: Jackie Liu <liuyun01@kylinos.cn>
Change-Id: I06a4f39b01625d2598b6579b47f5b500b912848f
Reviewed-on: http://gerrit.kylin.com/c/klinux/+/84149
Tested-by: k2ci <kernel-bot@kylinos.cn>
Mainline: ac96a15a0f0c8812a3aaa587b871cd5527f6d736
From: v6.7-rc1
Severity: Low
[ Upstream commit ac96a15a0f0c8812a3aaa587b871cd5527f6d736 ]
When MODULE_DEVICE_TABLE(ishtp, ) is built on a host with a different
endianness from the target architecture, it results in an incorrect
MODULE_ALIAS().
For example, see a case where drivers/platform/x86/intel/ishtp_eclite.c
is built as a module for x86.
If you build it on a little-endian host, you will get the correct
MODULE_ALIAS:
$ grep MODULE_ALIAS drivers/platform/x86/intel/ishtp_eclite.mod.c
MODULE_ALIAS("ishtp:{6A19CC4B-D760-4DE3-B14D-F25EBD0FBCD9}");
However, if you build it on a big-endian host, you will get a wrong
MODULE_ALIAS:
$ grep MODULE_ALIAS drivers/platform/x86/intel/ishtp_eclite.mod.c
MODULE_ALIAS("ishtp:{BD0FBCD9-F25E-B14D-4DE3-D7606A19CC4B}");
This issue has been unnoticed because the x86 kernel is most likely built
natively on an x86 host.
The guid field must not be reversed because guid_t is an array of __u8.
Fixes: fa443bc3c1 ("HID: intel-ish-hid: add support for MODULE_DEVICE_TABLE()")
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Thomas Weißschuh <linux@weissschuh.net>
Tested-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(backported from commit 106a1f3abb)
Signed-off-by: Jackie Liu <liuyun01@kylinos.cn>
Change-Id: I7b3dd04be10cc5d6f7fb43953e7575067765e1f3
Reviewed-on: http://gerrit.kylin.com/c/klinux/+/83964
Tested-by: k2ci <kernel-bot@kylinos.cn>
Mainline: 7f54e00e5842663c2cea501bbbdfa572c94348a3
From: v6.7-rc1
Severity: Low
[ Upstream commit 7f54e00e5842663c2cea501bbbdfa572c94348a3 ]
When MODULE_DEVICE_TABLE(tee, ) is built on a host with a different
endianness from the target architecture, it results in an incorrect
MODULE_ALIAS().
For example, see a case where drivers/char/hw_random/optee-rng.c
is built as a module for ARM little-endian.
If you build it on a little-endian host, you will get the correct
MODULE_ALIAS:
$ grep MODULE_ALIAS drivers/char/hw_random/optee-rng.mod.c
MODULE_ALIAS("tee:ab7a617c-b8e7-4d8f-8301-d09b61036b64*");
However, if you build it on a big-endian host, you will get a wrong
MODULE_ALIAS:
$ grep MODULE_ALIAS drivers/char/hw_random/optee-rng.mod.c
MODULE_ALIAS("tee:646b0361-9bd0-0183-8f4d-e7b87c617aab*");
The same problem also occurs when you enable CONFIG_CPU_BIG_ENDIAN,
and build it on a little-endian host.
This issue has been unnoticed because the ARM kernel is configured for
little-endian by default, and most likely built on a little-endian host
(cross-build on x86 or native-build on ARM).
The uuid field must not be reversed because uuid_t is an array of __u8.
Fixes: 0fc1db9d10 ("tee: add bus driver framework for TEE based devices")
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(backported from commit a073f26af7)
Signed-off-by: Jackie Liu <liuyun01@kylinos.cn>
Change-Id: I2d2aa4b4589a124138c98cdf207d3cd21774d533
Reviewed-on: http://gerrit.kylin.com/c/klinux/+/83963
Tested-by: k2ci <kernel-bot@kylinos.cn>
Mainline: 16501630bdeb107141a0139ddc33f92ab5582c6f
From: v6.7-rc1
Severity: Low
[ Upstream commit 16501630bdeb107141a0139ddc33f92ab5582c6f ]
MOD_TEXT is only defined if CONFIG_MODULES=y which lead to loading failure
of the gdb scripts when kernel is built without CONFIG_MODULES=y:
Reading symbols from vmlinux...
Traceback (most recent call last):
File "/foo/vmlinux-gdb.py", line 25, in <module>
import linux.constants
File "/foo/scripts/gdb/linux/constants.py", line 14, in <module>
LX_MOD_TEXT = gdb.parse_and_eval("MOD_TEXT")
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
gdb.error: No symbol "MOD_TEXT" in current context.
Add a conditional check on CONFIG_MODULES to fix this error.
Link: https://lkml.kernel.org/r/20231031134848.119391-1-da.gomez@samsung.com
Fixes: b4aff7513d ("scripts/gdb: use mem instead of core_layout to get the module address")
Signed-off-by: Clément Léger <cleger@rivosinc.com>
Tested-by: Daniel Gomez <da.gomez@samsung.com>
Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Kieran Bingham <kbingham@kernel.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: Pankaj Raghav <p.raghav@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(backported from commit 8762d2512f)
Signed-off-by: Jackie Liu <liuyun01@kylinos.cn>
Change-Id: I5a0215c21d24321ec7851b1ad38b778774d79d09
Reviewed-on: http://gerrit.kylin.com/c/klinux/+/83915
Tested-by: k2ci <kernel-bot@kylinos.cn>
Mainline: KYLIN-only
Severity: Low
Kylin’s kernel rules are a bit different from the upstream’s working
mode, so there is a slight difference in the code format, to suppress
these error or warning messages.
K2CI-Arch: None
Signed-off-by: Jackie Liu <liuyun01@kylinos.cn>
Change-Id: Ifebf8292a1ebf6524708f3009545a1d4841f5624
Reviewed-on: http://gerrit.kylin.com/c/klinux/+/82356
Tested-by: k2ci <kernel-bot@kylinos.cn>
Mainline: KYLIN-only
Severity: Low
Providing a set of tools for backport upstream patches can easily help
developers quickly merge kernel patches, which can reduce the probability
of errors to a certain extent and ensure consistent styles.
K2CI-Arch: None
Signed-off-by: Jackie Liu <liuyun01@kylinos.cn>
Change-Id: I4a929dce619dcb9fd2fe371eaaac38a292518ba1
Reviewed-on: http://gerrit.kylin.com/c/klinux/+/81671
Since commit d8131c2965 ("kbuild: remove $(MODLIB)/source symlink"),
modules_install does not create the 'source' symlink.
Remove the stale code from builddeb and kernel.spec.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Drivers must not reference functions marked with __exit as these likely
are not available when the code is built-in.
There are few creative offenders uncovered for example in ARCH=amd64
allmodconfig builds. So only trigger the section mismatch warning for
W=1 builds.
The dual rule that drivers must not reference .init.* is implemented
since commit 0db2524523 ("modpost: don't allow *driver to reference
.init.*") which however missed that .exit.* should be handled in the
same way.
Thanks to Masahiro Yamada and Arnd Bergmann who gave valuable hints to
find this improvement.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Without this 'else' statement, an "usb" name goes into two handlers:
the first/previous 'if' statement _AND_ the for-loop over 'devtable',
but the latter is useless as it has no 'usb' device_id entry anyway.
Tested with allmodconfig before/after patch; no changes to *.mod.c:
git checkout v6.6-rc3
make -j$(nproc) allmodconfig
make -j$(nproc) olddefconfig
make -j$(nproc)
find . -name '*.mod.c' | cpio -pd /tmp/before
# apply patch
make -j$(nproc)
find . -name '*.mod.c' | cpio -pd /tmp/after
diff -r /tmp/before/ /tmp/after/
# no difference
Fixes: acbef7b766 ("modpost: fix module autoloading for OF devices with generic compatible property")
Signed-off-by: Mauricio Faria de Oliveira <mfo@canonical.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Kmod is now (since kmod commit 09c9f8c5df04 ("libkmod: Use kernel
decompression when available")) using the kernel decompressor, when
loading compressed modules.
However, the kernel XZ decompressor is XZ Embedded, which doesn't
handle CRC64 and dictionaries larger than 1MiB.
Use CRC32 and 1MiB dictionary when XZ compressing and installing
kernel modules.
Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050582
Signed-off-by: Martin Nybo Andersen <tweek@tweek.dk>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
