Fernando Apesteguía wrote: > I even removed the counters and statistics. The replacement goes fine, > but when I try to rmmod the module I get an Oops like this (This is a > partial output): > > *pde=018ed067 > *pte=00000000 > Oops: 0000 [#1] > PREEMPT > Modules linked in: <here comes the list of modules> > CPU: 0 > EIP: 0060: [<f8ad234a>] Tainted: P VLI > EFLAGS: 00010286 (2.6.15.6 <http://2.6.15.6>) > EIP is at 0xf8ad234a > eax: 00000033 ebx: 0000000 ecx: 00000033 edx: 0000000 > esi: 0000001 edi: 0000000 ebp: f78d4000 esp: f78d5f78 > ds: 007b es: 007b ss: 0068 > > Process klogd (pid: 2539, threadinfo=f78d4000 task=f78c0a50) > .. > .. > Call Trace: > [<c0102b79>] syscall_call + 0x7/0xb > Code: Bad EIP value > > > I don't know what I'm doing wrong... the other syscalls I catched > (brk, fork and vfork) works fine. They probably work fine most of the time but I wouldn't count on them being generally correct ;) The problem is, once you've hijacked some system calls you can't just remove your module, there might be calls in progress using your code. This is exactly what happens with your oops: klogd is doing a blocking read(), the read syscall is hijacked by my_read() which in turns ends up calling old_read(). That's where klogd is sleeping waiting for data. Then you remove your module and my_read() goes away. When klogd finally gets some input, old_read() tries to return into my_read() since that's where it was called from but that memory region is probably in use by something else by now so... oops. Modifying the syscall table this way is highly discouraged (for a good reason, as you can see it's inherently racy), probably your safest bet is to mark your module in use and never unload it. --- fm -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
