> 
> 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.

-- Ragge