Messages in this thread | | | From | Keith Owens <> | Subject | Re: Nice values for kernel modules | Date | Sat, 16 Mar 2002 23:34:35 +1100 |
| |
On Sat, 16 Mar 2002 11:27:03 +0000 (GMT), Tigran Aivazian <tigran@veritas.com> wrote: >On Sat, 16 Mar 2002, Paul Mackerras wrote: > >> Keith Owens writes: >> >> > On Sat, 16 Mar 2002 09:51:16 +0000 (GMT), >> > <tigran@aivazian.fsnet.co.uk> wrote: >> > >jump to sys_nice() indirectly via exported sys_call_table[]. >> > >> > Breaks on ia64 and ppc. >> >> Not that I want to encourage this sort of thing, but why would it >> break on ppc?
Should have been ppc64, not ppc.
>and also why would it break on ia64. I can understand __mips but why ia64?
Address of function text is NOT the same as &function. On many architectures &function is the same as the first byte of the function text but not on all architectures. On IA64 &func points to a function descriptor which contains { void * __gp; void * function_text; }. When you call a function on ia64, the code is really :-
save current __gp load address of function_text load __gp (global data pointer) for new function call function_text restore original __gp
Within the kernel, all direct function calls (call function by name) are assumed to have the same __gp so the code reduces to :-
load address of function_text call function_text
just like most other architectures, this is why syscalls within the kernel work.
When the kernel calls a function via a pointer then __gp must be saved, set and restored. This is especially true when calling from the kernel to a module or vice versa, I guarantee that kernel and modules have different __gp values.
Fetching &sys_nice from the syscall table and blindly calling that address from a module will crash the kernel. PPC64 has a similar problem, it has a function descriptor that contains 3 fields.
There is no architecture independent method for accessing syscall entries _as functions_ from a module. Code that works on ix86 will break on ia64 and ppc64. I can see no good reason why the syscall table has been exported.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |