Problems with FC3

[Goran Devic]

Hi,
I installed FC3 + kernel sources for 2.6.9-1.667, after fixing up the
Makefile, .config and rebuilding the includes, the linice module does
not want to load due to this:

# insmod linice.ko
linice: unknown symbol copy_from_user
linice: unknown symbol copy_from_user

We do include correct <asm/uaccess.h>. The System.map also does not
show that symbol (should it?) That may even be a macro when it
resolves, but I never had this problem before with any distro. RH9 has
a different set of copy_from_user exports.

Just to narrow the scope, I also tried to use one of the test modules
(module.ko) with that function (copy_from_user) and it also did not
want to load. What's the matter with those two functions? Are there any
kernel options that zap them away? Should we be using some other
(alternate) functions instead (seems like the compatibilty hell :)
Thanks!
- Goran

[Goran Devic]

(As a side note - you're not suppose to load linice by using insmod,
neither unload it using rmmod due to the init protocol and hooks- this
is just to debug the dynamic linking and loading part :)

[Carlos Manuel Duclos Vergara]

Hi all,

there will be lots of compatibility problems with linice, because it uses 2.4
mechanisms such as registering a char device. That's why I told you about
splitting the code in two parts (kernel dependent and kernel independent).
BTW, I'm still trying to make the user_helper program to works with linice by
means of a ioctl call, however I get a very weird problem with the reiserfs
module. If anybody wants to test it with another filesystem I can post the
source code of my experiments in my web server.

Cheers

PS As far as I remember I think I compromised myself to rewrite the
initialisation code. I have the squeleton of that, it will load but it is not
added to the rest of the linice code. However it won't be difficult to do
(but very time consuming because there is a lot of source code to be
rearranged), is there any voluntaries to do this?

--
Carlos Manuel Duclos Vergara
car...@embedded.cl
http://www.embedded.cl

[prcoder]

I haven't this problem.
linice.ko loads normaly, but causes kernal panic on init.

[root@tpchome root]# uname -sr
Linux 2.6.9-1.640asptpc

[root@tpchome root]# cat /boot/System.map | grep copy_from_user
021315a3 t __filemap_copy_from_user_iovec
0215cf17 t exact_copy_from_user
021a0fe0 T __copy_from_user_ll
02295149 t copy_from_user_state
02295a6c t copy_from_user_tmpl
02295aa0 t copy_from_user_policy

[Goran Devic]

For the world of it I cannot make this work. What did you do??

I cleanly reinstalled FC3, got kernel sources for its 2.6.9.1-667
version (all the patches were already applied), used config from the
sources or from /boot, recompiled kernel includes. Linice (and one
simple test program) compiles fine, but it can't find those two symbols
(copy_to and _from) on actual load.

grepping the /boot/System.map-2.6.9.1-667 gives exactly the same output
as yours above. Interestingly, if I call __copy_from_user_ll, it still
cannot link to it: I dont know whether it is because that symbol is "T"
(static?) or simply something else is wrong.

I see copy_from_user has a proto in uaccess.h and that's it - it does
not get redefined into some other call, which means it has to be
exported by the kernel in order to link. What I am missing here??

I really feel FC is a piece of s***. One should not have problems like
this :-(

# uname -a
# Linux localhost.localdomain 2.6.9-1.667 #1 (...) i686 i686 i386
GNU/Linux

[Goran Devic]

Ok, google is your best friend :)
I am quite sure the root of the problem is the option CONFIG_X86_4G=y.
Formal FC3 kernel had been built with that option turned on. Not only
that penalizes the system performace (some claims 20-30%!) but it also
breaks many legacy interfaces that count on directly sharing memory
between user app and kernel module. That's why it does not work. In
fact, Linice assumes some user/kernel boundary at a known address (be
it 80000000 or C0000000), so even if we fix this interface, I am not
sure how well will Linice work in a new (!) environment. It may just
panic, as prcoder already noticed :)
I feel FC3 made a bad choice of compile options :)
If somebody knows how to rewrite that interface (copy_to/from_user),
that would be the first step in making this work, if it's worth it.

[Goran Devic]

Found the problem: compile_2.6 should have:
make -C /lib/modules/`uname -r`/build/include/.. SUBDIRS=$PWD
SRCROOT=$PWD/. modules
;-)

[Goran Devic]

Hi Carlos,
What's the problem with register_chrdev() in 2.6? It fails on FC3. Why
it cannot be used in 2.6? (I think it works on Debian just fine)
Thanks!

[Carlos Manuel Duclos Vergara]

Hi Goran,

a very simple one... it's deprecated :-|
the real problem is that major and minor number have suffered a
transformation, from 16 bits to 32 bits. So register_chrdev have to be
updated. To make this code update more clear, the kernel developers instead
of just changing the behaviour of register_chrdev first introduced the
register_chrdev_region(...) function.
With 2.6 they put a warning in register_chrdev saying it was deprecated and
from 2.6.9-something they simply delete it from kernel source code. So it's
possible that your debian has an older kernel (previous to 2.6.9-something)
than your fedora and this way your debian still has the definition of
register_chrdev.
The changes does not ended there, there is a bunch of other changes around so
that's the reason I told you to rewrite the initialisation from scratch for
2.6 (including the fact that doing your little trick of loading the module
inside a helper program won't work, because the kernel module loading has
been rewriten in 2.6)

Look at the source code I'm writing, because it's based on this new scheme:
http://www.elbazaar.cl/~carlos/linice-20041128.tar.gz
http://www.elbazaar.cl/~carlos/external_symbol_loading-20041230.tar.gz

The first file contains my first attempt to split the linice code into
kernel_dependent and kernel_independent parts. As you may see my idea was not
as good as I thought. However the new initialisation scheme is there to be
used.
The second file contains my attempt to use ioctl and helper_programs to load
the symbol table (I don't know why yet, but I'm having problems with this
module and reiserfs any ideas would be very welcomed). The new initialisation
scheme is also there to be used.

If any of you guys want a better explanation of this changes, take a look at
http://lwn.net/Articles/driver-porting/

or just ask and I'll try to answer here :-D

cheers!

--
Carlos Manuel Duclos Vergara
car...@embedded.cl

http://www.elbazaar.cl/

[prcoder]

As has written rezn there are many options influencing for properly
work of module like CONFIG_X86_4G, CONFIG_REGPARM, CONFIG_PREEMPT
e.t.c. I'll try to play with it.
And I agree with Carlos Manuel Duclos Vergara concerning that may be it
is necessary to rewrite the initialisation code for 2.6 from scratch.

[Goran Devic]

Yep - that seems to be the right (+long term) way to go. Carlos' also
correct - Debian is using 2.6.8.1, that's why it still works. I'll d/l
your files this evening and see how to merge them into existing
infrastructure, Carlos. Plus, need to do some more reading on that
before making so much noise about (obvious for you) things :), thanks
for the links!