problem accessing current->thread in assembly syscall handler
Bo Hong
I met some serious problems when hacking linux on powerpc. Any
help would be appreciated. Please bear with the long description here
as I want to be as clear as possible.
I am working on a Power6 running fedora 12, kernel version
2.6.32.23-170. The purpose is to test some ideas that fine tunes
thread scheduling.
I added a new field "unsigned long my_priority" to the end of
thread_struct (arch/powerpc/include/asm/processor.h)
I can access this field through my newly added system calls by
referring to current->thread.my_priority. Everything was fine, the
modified kernel boots, and I can set and read my_priority via system
calls. (I haven't changed the scheduling as of now).
So I moved on and tried to to access my_priority in the assembly
syscall handler. It's in arch/powerpc/kernel/exception_64s.S
Here is original codelet:
. = 0xc00
HMT_MEDIUM
cmpdi r0,0x1ebe
beq- 1f
....
Here is my first modification:
. = 0xc00
HMT_MEDIUM
mfspr r13, SPRN_SPRG_PACA // read paca of the current cpu
ld r10, PACACURRENT(r13) // paca->__current
li r12, 18 // just a test,
try to set priority to 18
std r12, (THREAD+336)(r13) // paca->__current-
>thread.my_priority ( paca+THREAD is current->thread_struct,
my_priority is 336 bytes further down)
cmpdi r0,0x1ebe
beq- 1f
....
My kernel will not boot with the four new instructions!
Then I tried to identify what problem is, so I change the code to
the following:
. = 0xc00
1. HMT_MEDIUM
2. cmpdi r0, 324 // okay, will
only touch it in syscall 324. This is a new sys call that I added to
the kernel
3. bne not_sys_call_324
4. mfspr r13, SPRN_SPRG_PACA // read paca of the current cpu
5. ld r3, PACACURRENT(r13) // r3 = paca->__current
6. ld r4, (THREAD+336)(r3) // r3+THREAD is paca-
>__current->thread, my_priority is 336 bytes further down,
// so I expect r4
= paca->__current->thead.my_priority,
not_sys_call_324:
cmpdi r0,0x1ebe
beq- 1f
....
This time, the system boots - since no one will do syscall 324 and
trigger my code.
syscall 324, written in C, just printk the two parameters (passed
via r3 and r4) as well as 'current', and does nothing else.
Then I tested syscall 324 from a user program. to my surprise, /
var/log/messages shows that
r3, when passed into the syscall handler, becomes "0x570daee0",
while current is "0xc0000001570daee0".
the syscall also complained that "ld r4, (THREAD+336)(r3) "
caused a "Bad kernel stack pointer"
Here are my questions:
1. When the 64-bit __current is truncated to 32-bits when I load
it in line 5? right when it's loaded, or is it possible that r3
still has 64 bits, but when passed into syscall 324, it is truncated?
2. could this be the reason that my first mod failed to boot?
Many thanks in advance
Bo Hong