Bug#494144: Checking versions of the symbols in modules
Jordi Pujol
Version: 2.6.26-1-686
Severity: normal
Hello,
I have a problem with kernel version 2.6.26, that I consider that could be a
bug.
summary:
In a kernel already compiled, we install new modules, some of that depend of
the others.
after starting that kernel, the module who has the dependencies can not find
the symbols that uses from the first module, and does not load.
Full description:
In a kernel already compiled, we install new modules, some of them depending
from the others.
In this case the modules are lzma and squashfs-lzma
after loading the module lzma we verify in /proc/kallsyms that the symbols
have been exported and correctly noted.
When we try to load the module squashfs that depends on the symbols of sqlzma,
the kernel responds:
no symbol version for sqlzma_init
Unknown symbol sqlzma_init
no symbol version for sqlzma_un
Unknown symbol sqlzma_un
no symbol version for sqlzma_fin
Unknown symbol sqlzma_fin
workaround:
my first solution was to compile a kernel with MODULE_FORCE_LOADING enabled,
and forcing modprobe to do that. That works,
in this case is a recompilation to enable MODULE_FORCE_LOADING.
Linux version 2.6.26.1-686-jp2 (root@pcjordi) (gcc version 4.3.1 (Debian
4.3.1-2) ) #1 SMP PREEMPT Tue Aug 5 11:34:33 CEST 2008
a good solution is done modifying the kernel source,
inspecting the source "module.c", can be appreciated differences with the
version 2.6.25 in the routine "check_version", so that previously has
returned "1=OK" when the version for a symbol was not found, but in this
routine, version 2.6.26 returns "0=error".
Works well after modifying some lines of module.c
Attached is proposed a patch to module.c
P.D. lzma is from the sid repository of Debian, and squashfs-lzma is my own
development, based in previous versions of squashfs with lzma support,
Thanks,
Jordi Pujol
Bastian Blank
> In a kernel already compiled, we install new modules, some of that depend of
> the others.
> after starting that kernel, the module who has the dependencies can not find
> the symbols that uses from the first module, and does not load.
Yes, you don't provide the correct set of symbol versions for the build
of the second module. You even should get a warning from modpost.
> a good solution is done modifying the kernel source,
No.
If you want a real solution, please start with linux-modules-extra-2.6
and add support to save the Module.symvers somewhere in the package and
use them to get correct versions in dependant packages.
Bastian
--
Four thousand throats may be cut in one night by a running man.
-- Klingon Soldier, "Day of the Dove", stardate unknown
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jordi Pujol
> If you want a real solution, please start with linux-modules-extra-2.6
> and add support to save the Module.symvers somewhere in the package and
> use them to get correct versions in dependant packages.
thanks, I will try that,
nevertheless consider activating the config option to force loading of
modules, so that the Debian kernel complies with the guidelines of operation
following:
Modules without symbol version information can only be loaded on the
exact kernel version for which they were compiled. Modules with symbol
version information can be loaded into more recent kernels as long as
none of the symbols exported by the kernel have changed. This provides
a reasonable level of confidence but does not guarantee that the module
will work.
Authors: Linus Torvalds <torv...@transmeta.com>
Jordi,
Bastian Blank
> nevertheless consider activating the config option to force loading of
> modules,
Yeah, looks like the easiest solution.
> so that the Debian kernel complies with the guidelines of operation
> following:
This is not longer true after 826e4506a0acb6487910a5ebafe839f708a00e1c
and a5dd69707424a35d2d2cc094e870f595ad61e916.
Bastian
--
We do not colonize. We conquer. We rule. There is no other way for us.
-- Rojan, "By Any Other Name", stardate 4657.5