Re: mysterious page fault in _syscall3..

[Ralf Baechle <ralf@linux-mips.org>]

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