mysterious page fault in _syscall3..

mysterious page fault in _syscall3..

[atul srivastava]

Hello,

on Mips idt with Rc323334 core i have following problem.

1.After boot when the shell is execved the sequence goes like 
this.

in init/main.c

execve -( macro expansion in _syscall3 in unistd. h)--> sys_execve 
--> do_execve

do_execve return success and i get a sensible register dump after 
do_execve(0 call in sys_execve() like,

$0 : 00000000 00000000 00000000 00000000
$4 : 00000000 00000000 00000000 00000000
$8 : 00000000 00000000 00000000 00000000
$12: 00000000 00000000 00000000 00000000
$16: 00000000 00000000 00000000 00000000
$20: 00000000 00000000 00000000 00000000
$24: 00000000 00000000
$28: 00000000 7fff7f80 00000000 00000000
epc   : 004000b0
Status: 0000ff13
Cause : 00000020

EPC 004000b0 is verified by objdump of /bin/sh
STATUS 0000ff13 imply user mode and CAUSE 00000020 indicate 
syscall exception..all fine.

2.but immediately after sys_execve returns the value, i get a 
sudden page fault producing a imposible register dump ( epc status 
and cause all zero)

Unable to handle kernel paging request at virtual address 
0fc01788, epc == 00000000, ra == 00000000
Oops in fault.c:do_page_fault, line 225:
$0 : 00000000 00000000 00000000 00000000
$4 : 000072c0 800ef814 00000000 801fc000
$8 : 00000000 00000000 00000000 4c696e75
$12: 78000000 00000000 00000000 00000000
$16: 00000000 00000000 00000000 00000000
$20: 00000000 00000000 00000000 00000000
$24: 00000000 00000000
$28: 6e652900 00000000 00000000 00000000
epc   : 00000000
Status: 00000000
Cause : 00000000

this i guess when sys_execve returns , stack is corrupted somehow 
and regs(pointer to struct pt_regs) is no more correct.

though i haven't read fully the gcc info page and acquanited with 
nasty  asm code of _syscall3 in unistd.h , but does execve enters 
sys_execve directly by macro expansion in _syscall3 ..or there are 
relevant steps in between.?

what kind of problem i am facing ?
is this problem with saving & restoring , corruption
or in _syscall3..?
any possibility of write buffer and pipeline hazard..?

I have tried with interrupts disabled in sys_execve just for 
checking prupose..
would taking support of BDI2000 kind of debuggers will be 
helpful?

Best Regards,
Atul



__________________________________________________________
Give your Company an email address like
ravi @ ravi-exports.com.  Sign up for Rediffmail Pro today!
Know more. http://www.rediffmailpro.com/signup/

Re: mysterious page fault in _syscall3..

[Ralf Baechle]

On Thu, Nov 21, 2002 at 01:33:07PM -0000, atul srivastava wrote:

> 2.but immediately after sys_execve returns the value, i get a 
> sudden page fault producing a imposible register dump ( epc status 
> and cause all zero)

Check the cache and TLB code for your architecture.  Read it 10 times if
necessary because bugs in that code can have extremly subtle effects.

> though i haven't read fully the gcc info page and acquanited with 
> nasty  asm code of _syscall3 in unistd.h , but does execve enters 
> sys_execve directly by macro expansion in _syscall3 ..or there are 
> relevant steps in between.?

I recommend to not use the _syscall macros in userspace _at_all.  They've
been written for use by kernelspace; getting them bullet proof for
userspace as well has been a big pain over the years.  I know, you're
doing this for testing only but even then you're not safe ...

In general the use of all kernel header files for userspace applications
is a dangerous idea ...

> what kind of problem i am facing ?
> is this problem with saving & restoring , corruption
> or in _syscall3..?

_syscallX() is pure userspace stuff.  Any bugs in that area should only
result in your process but not the entire system crashing.

> any possibility of write buffer and pipeline hazard..?

Write buffer stuff is only relevant for dealing with external agents that
is SMP or I/O which doesn't seem related to your case.

Double check the cache code for your CPU.  There are lots of creative
implementations of caches out there that need special treatment in the
kernel.

(That was the political correct version of speaking about those cache
designs.  My prefered wording about this issue can't be posted in any
public forum ;-)

> I have tried with interrupts disabled in sys_execve just for 
> checking prupose..
> would taking support of BDI2000 kind of debuggers will be 
> helpful?

The Linux/MIPS kernel has been ported and debugged entirely using printk
and even more important by just look at the source.

  Ralf