Ignatios Souvatzis <ignatios@cs.uni-bonn.de> writes:
> > Or is the pipe(2) call restarted after the fault is detected?
> 
> Uhm, whether you are executing a system call is irrelevant. The program
> re-executes the instruction that caused the SEGV. If this was doing a 
> system call, you reexecute calling the system.

The thing that most people are missing here is that the system call is
_not_ generating the SEGV nor could it even (reasonably 8-) generate
EFAULT as currently implemented.

pipe() is a small libc wrapper around that system call.  What it does
is:
	* invoke the pipe syscall
	* stuff the multi-valued return value into the array that the
	  user specified.

I.e. it's user-land code which is touching the memory, and it's
user-land code which is causing the fault.


The statement:

> If this was doing a
> system call, you reexecute calling the system.

is a bit misleading.  That's true only if the actual system call
invocation (i.e. not any of the actions before, nor any after) caused
the fault.  (I can't actually think of times when that can actually
happen, to be honest, but it's been a long time since i've played with
most architectures.)

That is _not_ what's happening here.


Effectively, what he's done here is equivalent to:

	ignore segv
	(char *)0xdeadbeef = 1;

the pipe() library/system call is irrelevant.  He's just fonud the
good reason that you shouldn't _ignore_ SEGV or attempt to handle it
and not either exit or fix the error, if your program is actually
inclined to generate SEGVs.



cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.