lp:kmod

Created by Registry Administrators on 2012-07-04 and last modified on 2019-11-18
Get this branch:
bzr branch lp:kmod

Related bugs

Related blueprints

Branch information

Owner:
Registry Administrators
Project:
kmod
Status:
Development

Import details

Import Status: Reviewed

This branch is an import of the HEAD branch of the Git repository at git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git.

The next import is scheduled to run in 21 minutes.

Last successful import was 5 hours ago.

Import started 5 hours ago on alnitak and finished 5 hours ago taking 20 seconds — see the log
Import started 11 hours ago on izar and finished 11 hours ago taking 15 seconds — see the log
Import started 17 hours ago on alnitak and finished 17 hours ago taking 15 seconds — see the log
Import started 23 hours ago on alnitak and finished 23 hours ago taking 20 seconds — see the log
Import started on 2019-11-18 on izar and finished on 2019-11-18 taking 15 seconds — see the log
Import started on 2019-11-18 on alnitak and finished on 2019-11-18 taking 20 seconds — see the log
Import started on 2019-11-18 on izar and finished on 2019-11-18 taking 15 seconds — see the log
Import started on 2019-11-18 on izar and finished on 2019-11-18 taking 15 seconds — see the log
Import started on 2019-11-17 on izar and finished on 2019-11-17 taking 15 seconds — see the log
Import started on 2019-11-17 on alnitak and finished on 2019-11-17 taking 15 seconds — see the log

Recent revisions

1181. By Fabrice Fontaine <email address hidden> on 2019-11-18

Makefile.am: filter -Wl,--no-undefined

Commit 1d14ef82f4a3be741bcdf6b1c6d51ce9dce43567 does not completely fix
the build with python 3.8 as we still get link failure due to
'-z undefs' being ignored by some versions of ld.

Indeed, -z undefs was added by commit
97a232d7335f3bd0231fd9cd39455bde1d563922 in upstream binutils, and this
commit was first present in binutils 2.30.
So any toolchain using binutils version older than that won't have
-z undefs and will build fail on:

/home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/mips-linux-gnu/5.3.0/../../../../mips-linux-gnu/bin/ld: warning: -z undefs ignored.

/home/naourr/work/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/aarch64_be-linux-gnu/7.3.1/../../../../aarch64_be-linux-gnu/bin/ld: warning: -z undefs ignored.

So filter -Wl,--no-undefined to fix the issue

Fixes:
 - http://autobuild.buildroot.org/results/e9645d9969481b09f507f6e0d0b35faaa283eb60
 - http://autobuild.buildroot.org/results/06a6d865b6b7d8ebd793bde214f4a4c40e0962e1

Signed-off-by: Fabrice Fontaine <email address hidden>

1180. By Lucas De Marchi on 2019-11-07

modprobe: use flags rather than bool args

It's easier to know what the caller is doing when we pass a named
flag rather than a list of bools.

1179. By Lucas De Marchi on 2019-11-07

travis: remove old compiler failing to build kernel module

This is when building the kernel modules for testsuite:

 Makefile:718: Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong not supported by compiler
 gcc: error: unrecognized command line option ‘-fstack-protector-strong’

Just drop gcc 4.8 from running tests. Failure not really related to kmod.

1178. By Lucas De Marchi on 2019-11-07

testsuite: update gitignore

1177. By Yauheni Kaliuta <email address hidden> on 2019-11-07

modprobe: ignore builtin module on recursive removing

If there are built-in dependencies and any of them is built-in in
the kernel, modprobe -r fails with

modprobe: FATAL: Module module_name is builtin.

It makes sense to ignore such dependencies for the case when
removing is called for non-top level module.

Example: cifs module, it declares bunch of softdeps and the first
one fails on some kernel configs:

modprobe: FATAL: Module gcm is builtin.

Signed-off-by: Yauheni Kaliuta <email address hidden>

1176. By Thomas Petazzoni <email address hidden> on 2019-10-25

Do not check for undefined symbols when building the Python modules

kmod's configure.ac uses the -Wl,--no-undefined linker flag to verify
at link time that all symbols of shared libraries are available, and
that there are no undefined symbols.

This make perfect sense for regular shared libraries. However, for
Python extensions, which will be dlopen()ed inside the Python
interpreter, it makes less sense.

Since Python 3.8, there is a change in python-config script and
Python's pkg-config file: it no longer links Python extensions with
the libpython library. See
https://docs.python.org/dev/whatsnew/3.8.html#debug-build-uses-the-same-abi-as-release-build
which states:

  On the other hand, pkg-config python3.8 --libs no longer contains
  -lpython3.8. C extensions must not be linked to libpython (except on
  Android and Cygwin, whose cases are handled by the script); this
  change is backward incompatible on purpose. (Contributed by Victor
  Stinner in bpo-36721.)

So, when linking the kmod Python extensions, it currently fails with
numerous unresolved symbols, that were previously provided by
libpython:

/home/test/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/powerpc64-buildroot-linux-gnu/7.4.0/../../../../powerpc64-buildroot-linux-gnu/bin/ld: libkmod/python/kmod/.libs/list_la-list.o: in function `__Pyx_PyObject_GetAttrStr':
list.c:(.text.__Pyx_PyObject_GetAttrStr+0x48): undefined reference to `PyObject_GetAttr'
/home/test/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/powerpc64-buildroot-linux-gnu/7.4.0/../../../../powerpc64-buildroot-linux-gnu/bin/ld: libkmod/python/kmod/.libs/list_la-list.o: in function `__pyx_tp_dealloc_4kmod_4list_ModListItem':
list.c:(.text.__pyx_tp_dealloc_4kmod_4list_ModListItem+0x78): undefined reference to `PyObject_CallFinalizerFromDealloc'
/home/test/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/powerpc64-buildroot-linux-gnu/7.4.0/../../../../powerpc64-buildroot-linux-gnu/bin/ld: libkmod/python/kmod/.libs/list_la-list.o: in function `__pyx_tp_dealloc_4kmod_4list_ModList':
list.c:(.text.__pyx_tp_dealloc_4kmod_4list_ModList+0x30): undefined reference to `PyErr_Fetch'

[Complete log at http://autobuild.buildroot.net/results/79a/79a5a0398723e8cfea0d0aa3dec5f7649aee4c63/build-end.log]

Linking with libpython is no longer recommended: those symbols should
remain unresolved in the Python extensions, as they wil be properly
resolved when the Python extension gets loaded into the Python
interpreter.

Since we want to keep -Wl,--no-undefined globally in kmod, we leave
the configure.ac file unchanged, and instead, specifically in the
LDFLAGS used to build the Python extensions, we override
-Wl,--no-undefined with -Wl,-z,undefs. Ideally, -Wl,--no-undefined is
the same as -Wl,-z,defs, and the effect of these options can be
canceled on the linker command line by a following -Wl,-z,undefs (see
the ld man page for details).

Signed-off-by: Thomas Petazzoni <email address hidden>
Cc: Victor Stinner <email address hidden>

1175. By Stefan Strogin <email address hidden> on 2019-05-28

libkmod-signature: use PKCS#7 instead of CMS

Linux uses either PKCS #7 or CMS for signing modules (see
scripts/sign-file.c). CMS is not supported by LibreSSL or older OpenSSL,
so PKCS #7 is used on systems with these libcrypto providers.

CMS and PKCS #7 formats are very similar. CMS is newer but is as much as
possible backward compatible with PKCS #7 [1]. PKCS #7 is supported in
the latest OpenSSL as well as CMS. The fields used for signing kernel
modules are supported both in PKCS #7 and CMS.

For now modinfo uses CMS with no alternative requiring OpenSSL 1.1.0 or
newer.

Use PKCS #7 for parsing module signature information, so that modinfo
could be used both with OpenSSL and LibreSSL.

[1] https://tools.ietf.org/html/rfc5652#section-1.1

Changes v1->v2:
- Don't use ifdefs for keeping redundant CMS code, just use PKCS #7 both
with OpenSSL and LibreSSL.

Signed-off-by: Stefan Strogin <email address hidden>

1174. By Ezequiel Garcia <email address hidden> on 2019-03-08

tools: Print a message if refcnt attribute is missing

Currently, check_module_inuse returns a wrong user message
if the kernel is built without module unloading support.

Fix it by returning a more specific error, in case 'refcnt'
attribute is missing.

1173. By Adrian Bunk on 2019-02-20

build: Stop using dolt

This does regress "make -12" from 0.7s to 0.9s on my
Coffee Lake machine, but even on slower hardware this
will not amount to a noticable slowdown.

On the other hand using dolt can create problems for
people doing cross-compilation, e.g. Yocto has two
hacks just for dolt in kmod:
https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-kernel/kmod/kmod.inc?id=a17abae00785c76cfffe5381a22fb2c86b982e82

(Lucas: remove leftover entry in Makefile and reformat commit message)

1172. By Dave Reisner <email address hidden> on 2019-02-13

Link against libcrypto, not all of openssl

In the previous build setup, libkmod.so would link to not just
libcrypto.so, but also libssl.so:

$ readelf -d /lib/libkmod.so | grep NEEDED
 0x0000000000000001 (NEEDED) Shared library: [liblzma.so.5]
 0x0000000000000001 (NEEDED) Shared library: [libz.so.1]
 0x0000000000000001 (NEEDED) Shared library: [libssl.so.1.1]
 0x0000000000000001 (NEEDED) Shared library: [libcrypto.so.1.1]
 0x0000000000000001 (NEEDED) Shared library: [libc.so.6]

We don't need any symbols from libssl, though. This patch ensures that
we pass 'libcrypto' to pkgconfig rather than 'openssl', getting only the
library that we need:

$ readelf -d ./libkmod/.libs/libkmod.so.2.3.4 | grep NEEDED
 0x0000000000000001 (NEEDED) Shared library: [liblzma.so.5]
 0x0000000000000001 (NEEDED) Shared library: [libz.so.1]
 0x0000000000000001 (NEEDED) Shared library: [libcrypto.so.1.1]
 0x0000000000000001 (NEEDED) Shared library: [libc.so.6]

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
This branch contains Public information 
Everyone can see this information.