Subject: Re: signal(SIGSEGV, SIG_IGN) -> 100% CPU
To: None <email@example.com>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 06/13/1999 13:01:52
[ On Sunday, June 13, 1999 at 23:47:54 (+1000), Robert Elz wrote: ]
> Subject: Re: signal(SIGSEGV, SIG_IGN) -> 100% CPU
> As to whether pipe ought be fixed to pass the array to the kernel or not
> that's pretty much irrelevant - if the cost of doing so is worth any
> benefit it will bring, then change it - but don't use EFAULT as a rationale.
I think the rationale is to do so for consistency's sake -- at least
that's the only reason I can think of.
> Historically all sys calls that returned fd's returned them in registers,
> and pipe was no exception, but that hasn't been true for a long time now.
Well in NetBSD pipe() and a few other systems calls that return multiple
int-wide values do still return their results in CPU registers, which is
really what started this whole thread! ;-)
It has always seemed to me to be rather inelegant that some of the
system calls that apparently take pointers from the C API's point of
view don't actually do so under the hood. The distinction that their
results are file descriptors doesn't seem to be strong enough to
validate this difference -- and it's not even true across the board in
> Also, historically, time() was a sys call, and it (its C library wrapper)
> would also seg fault if handed a bad address - pipe wasn't than unusual a
> case. Now time() still seg faults if it is handed a bad pointer, but
> no-one is objecting, because time() is now time(3) rather than time(2),
> and that distinction is supposed to make a difference?
<tangent> The switch from time(2) to time(3) always seemed to be a major
hack, and clearly the ?etimeofday(2) syscalls weren't quite as well
thought out and elegant as they should have been, as evidenced by the
deprecation of their second argument. </tangent>
> Lastly, the man page should not be fixed either - it should list all the
> errors that might occur, and EFAULT is one of those. It happens that it
> won't occur because the implementation doesn't happen to send the bad
> address to the kernel, but that's no reason that an application might not
> want to check for this and handle it (which is quite different than, say,
> EXDEV which can simply never occur on a pipe call, no matter what).
The application should check for a return value indicating failure
before it looks at errno and the manual page should only document the
return values that are possible. EFAULT *cannot* possibly occur in any
current NetBSD implementation of the pipe(2) call, no matter what, so
far as I can see.
> What might be worth doing is fixing intro(2) such that it says ..
> 14 EFAULT Bad address. The system detected an invalid address in attempt-
> ing to use an argument of a call. The system might generate
> a SIGSEGV signal instead of, or in addition to, generating this
> That would probably make everyone happy.
I would say that's the worst of all the options.
The syscall manual pages should very explicitly mention *only* those
errno values which might actually be returned by the current
implementation. Either the pipe(2) system call must be re-implemented
to actually pass the pointer in to the kernel and return EFAULT when
necessary, *or* mention of EFAULT must be removed from the manual page.
Greg A. Woods
+1 416 218-0098 VE3TCP <email@example.com> <robohack!woods>
Planix, Inc. <firstname.lastname@example.org>; Secrets of the Weird <email@example.com>