* hazards during DO_FAULT macro..
@ 2002-12-04 10:17 atul srivastava
2002-12-04 14:14 ` Ralf Baechle
0 siblings, 1 reply; 3+ messages in thread
From: atul srivastava @ 2002-12-04 10:17 UTC (permalink / raw)
To: linux-mips
My problem is that during return of sys_execve i get a page fault
on userspace address (0x004000b0) but the pt_regs address in
do_page_fault I get is 0x8013a61c which is actually envp_init
arguement passed in execve("/bin/sh",argv_init,envp_init);
I was trying to debug where my pt_regs pointer got thrased during
do_page_fault()
I found following stuff very strange.
macro Do_FAULt(write) expands like..
#define DO_FAULT(write) \
.set noreorder; \
.set noat; \
SAVE_ALL; \
STI; \
nop; \
.set at; \
move a0, sp; \
jal do_page_fault; \
li a1, write; \
nop; \
j ret_from_sys_call; \
nop; \
.set noat;
this macro is called by handle_tlbx() routines.
when I tracked this problem and i observed my pt_regs address
looked o.k. and apparently right till after STI; \ and just before
instruction mfc0 a2, CP0_BADVADDR;
this i found by putting following instructions,
move a0,sp; \
jal show_regs; \
nop; \
later it jumps to do_page_fault() ,and pt_regs address there
equals unexpectedly to envp_init and from thereon everythings goes
wrong..
I also tried with negating STI; \ , but same result.
problamatic assembly code for DO_FAULT macro is following.
.set noat; \
SAVE_ALL; \
8001e694: 03a02021 move $a0,$sp ----{
8001e698: 0c03bba8 jal 800eeea0 <show_regs> my debug code of
show_regs() ...here pt_regs address is
o.k..
8001e69c: 00000000 nop ---}
8001e6a0: 40086000 mfc0 $t0,$12 -----{
8001e6a4: 3c091000 lui $t1,0x1000
8001e6a8: 3529001f ori $t1,$t1,0x1f
8001e6ac: 01094025 or $t0,$t0,$t1 STI macro code , though i
tried without STI for testing purpose, as well
8001e6b0: 3908001e xori $t0,$t0,0x1e
8001e6b4: 40886000 mtc0 $t0,$12
8001e6b8: 40064000 mfc0 $a2,$8 -----}
...
8001e6c4: 03a02021 move $a0,$sp
8001e6c8: 0c007e34 jal 8001f8d0 <do_page_fault>
-----{now in
do_page_fault() pt_regs address is erronousely
different in my case it is equal to envp_init. }
8001e6cc: 24050000 li $a1,0
8001e6d0: 00000000 nop
8001e6d4: 08006a9a j 8001aa68 <ret_from_irq>
what kind of hazard happening..?
Best Regards,
Atul
^ permalink raw reply [flat|nested] 3+ messages in thread
* hazards during DO_FAULT macro..
@ 2002-12-04 10:18 atul srivastava
0 siblings, 0 replies; 3+ messages in thread
From: atul srivastava @ 2002-12-04 10:18 UTC (permalink / raw)
To: linux-mips
My problem is that during return of sys_execve i get a page fault
on userspace address (0x004000b0) but the pt_regs address in
do_page_fault I get is 0x8013a61c which is actually envp_init
arguement passed in execve("/bin/sh",argv_init,envp_init);
I was trying to debug where my pt_regs pointer got thrased during
do_page_fault()
I found following stuff very strange.
macro Do_FAULt(write) expands like..
#define DO_FAULT(write) \
.set noreorder; \
.set noat; \
SAVE_ALL; \
STI; \
nop; \
.set at; \
move a0, sp; \
jal do_page_fault; \
li a1, write; \
nop; \
j ret_from_sys_call; \
nop; \
.set noat;
this macro is called by handle_tlbx() routines.
when I tracked this problem and i observed my pt_regs address
looked o.k. and apparently right till after STI; \ and just before
instruction mfc0 a2, CP0_BADVADDR;
this i found by putting following instructions,
move a0,sp; \
jal show_regs; \
nop; \
later it jumps to do_page_fault() ,and pt_regs address there
equals unexpectedly to envp_init and from thereon everythings goes
wrong..
I also tried with negating STI; \ , but same result.
problamatic assembly code for DO_FAULT macro is following.
.set noat; \
SAVE_ALL; \
8001e694: 03a02021 move $a0,$sp ----{
8001e698: 0c03bba8 jal 800eeea0 <show_regs> my debug code of
show_regs() ...here pt_regs address is
o.k..
8001e69c: 00000000 nop ---}
8001e6a0: 40086000 mfc0 $t0,$12 -----{
8001e6a4: 3c091000 lui $t1,0x1000
8001e6a8: 3529001f ori $t1,$t1,0x1f
8001e6ac: 01094025 or $t0,$t0,$t1 STI macro code , though i
tried without STI for testing purpose, as well
8001e6b0: 3908001e xori $t0,$t0,0x1e
8001e6b4: 40886000 mtc0 $t0,$12
8001e6b8: 40064000 mfc0 $a2,$8 -----}
...
8001e6c4: 03a02021 move $a0,$sp
8001e6c8: 0c007e34 jal 8001f8d0 <do_page_fault>
-----{now in
do_page_fault() pt_regs address is erronousely
different in my case it is equal to envp_init. }
8001e6cc: 24050000 li $a1,0
8001e6d0: 00000000 nop
8001e6d4: 08006a9a j 8001aa68 <ret_from_irq>
what kind of hazard happening..?
Best Regards,
Atul
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: hazards during DO_FAULT macro..
2002-12-04 10:17 hazards during DO_FAULT macro atul srivastava
@ 2002-12-04 14:14 ` Ralf Baechle
0 siblings, 0 replies; 3+ messages in thread
From: Ralf Baechle @ 2002-12-04 14:14 UTC (permalink / raw)
To: atul srivastava; +Cc: linux-mips
On Wed, Dec 04, 2002 at 10:17:41AM -0000, atul srivastava wrote:
> macro Do_FAULt(write) expands like..
>
> #define DO_FAULT(write) \
> .set noreorder; \
> .set noat; \
> SAVE_ALL; \
> STI; \
> nop; \
Unnecessary nop.
> .set at; \
> move a0, sp; \
> jal do_page_fault; \
> li a1, write; \
> nop; \
Unnecessary nop.
> j ret_from_sys_call; \
This is ret_from_exception since about 14 months.
> nop; \
> .set noat;
>
> this macro is called by handle_tlbx() routines.
> when I tracked this problem and i observed my pt_regs address
> looked o.k. and apparently right till after STI; \ and just before
> instruction mfc0 a2, CP0_BADVADDR;
> this i found by putting following instructions,
>
> move a0,sp; \
> jal show_regs; \
> nop; \
>
> later it jumps to do_page_fault() ,and pt_regs address there
> equals unexpectedly to envp_init and from thereon everythings goes
> wrong..
This would means something like your user process was running with
c0_status.cu0 = 1 which is forbidden. If that happens the kernel wouldn't
load a new stack pointer on kerne entry.
> I also tried with negating STI; \ , but same result.
This would means something like your user process was running with
c0_status.cu0 = 1 which is forbidden. If that happens the kernel wouldn't
load a new stack pointer on kerne entry.
> 8001e6ac: 01094025 or $t0,$t0,$t1 STI macro code , though i
The function there has doesn't have STI but KMODE since almost half a
year. Time to upgrade.
And our code never had the mfc0 from the badvaddr register after the STI /
KMODE, so it seems you kernel tree is a) antique b) seems hacked beyond
recognition.
Moving the mfc0 behind the sti would be valid as long as we know there's
always a hazard of at least one cycle before interrupts get activated. That
was true for the initially supported processors like R4000 (3 cycles) or
R4600 (1 cycle) but no longer for modern processors.
Ralf
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2002-12-04 14:14 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-12-04 10:17 hazards during DO_FAULT macro atul srivastava
2002-12-04 14:14 ` Ralf Baechle
-- strict thread matches above, loose matches on Subject: below --
2002-12-04 10:18 atul srivastava
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.