Subject: Re: Bug in ksyms, kern/21526
To: Quentin Garnier <firstname.lastname@example.org>
From: None <email@example.com>
Date: 11/16/2003 12:13:57
> I would like to commit the attached patch, which actually solves the
> problems outlined in kern/21256.
I assume you mean 21526 :-) Oh, that was an old one. I haven't seen
it before (maybe therefore I haven't taken any care of it :-)
> Currently, when support for /dev/ksyms is compiled in, ksyms_addsym will
> shift every symbol value to make the symbol tables appear as one when
> reading from /dev/ksyms. But this makes the value of the symbol invalid
> when used in the kernel, and lead to crashes when loading a LKM module
> that uses modules from other LKMs. The fact that the kernel's symbol
> table appears as the first one means the kernel symbols values are not
> shifted, otherwise loading any LKM would crash.
Yeah, you discovered a thinko from my side here. I tested it by
loading one module that depended on one other, which worked (probably
because the correct phase of moon etc).
> most importantly to ksyms_getval() to indicate whether the request comes
> from the kernel or the userland. It also adds to handy defines as
> wrappers around the new ksyms_getval. Note that this change will require
> a kernel version bump.
Why? Your changes does not affect userland, and the only usage of
those routines are the one you changed.
> The attached patch introduces a new function ksyms_rensymtab that allows
> renaming a symbol time. It is used when loading a LKM, by adding its
> symbol table under the name "/lkmtemp/" before calling the entry function,
> and renaming it to its final name afterwards.
This is a known problem, and also an annoying one :-)
> I know that ksyms_addsymtab can sleep, so maybe I should not make the
> temporary name unique, but rather add the pid of the modload process to
> it. Also, maybe there should be some locking/sleeping in ksyms_rensymtab.
The trivial loching is just to prevent the symbols to be fiddled while
/dev/ksyms is open. This only changes the symbol table name which is not
exposed to userland, so it don't have to be locked.
> Comments? I know the LKM part is just a hack, but not by much more than
> what we do to load LKMs, and a well designed in-kernel linker mechanism
> will solve the issue. In the meantime, I think it is useful to be able to
> access LKM symbols at that precise time.
When looking through your patches it seems good. As you wrote, an in-kernel
linker would take care of much of the problems (and also would cause
much of the ksyms code to be removed/changed). I say check it in.
Hm, I hope I can spend some time soon to deal with the in-kernel linker
again, but it will probably not be until next year.