Re: avoid spinning processes when catching SEGV/BUS/FPE

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> Currently processes that catch SIGSEGV/SIGBUS/SIGFPE and receive a
> signal again while they are processing the signal handler end in an
> infinite loop spinning because the signal is masked during delivery
> (and executing the handler).

If I've understood you correctly, this is true only under two important
assumptions: (1) the "a signal" is another such signal, not an
unrelated signal like SIGTSTP or SIGIO, and (2) the signal handler
generates the signal in a way that repeats in the absence of signal
delivery.

> This is not desirable behavior.

True.  But...

> I would be better to just reset the signal to default if it is being
> "caught and masked" since in that scenario the process will never see
> the signal and the signal will keep being delivered.

...to the extent this is true (it depends, as I remarked above, on
various things not explicit here), I think most such potential loops
are "don't do that, then" (but see below).  There are a _lot_ of ways
for a process to end up in an infinite loop, many of them involving
signals; the kernel is not in a position to prevent all, nor even most,
of them (though with sufficient cleverness it probably could prevent
most of the ones depending on signals).

The only case where anything like this makes any sense to me is (a)
when the signal is generated in direct response to a hardware trap and
(b) the situation is such that, with the signal blocked, the failing
hardware operation will be re-attempted immediately and will
necessarily produce the same result.  ((b) has some unobvious cases
where it might not be true; consider, for example, a process doing a
divide by a memory-resident value which happens to be zero, looping
until another process sharing the memory changes that value.  I'm not
sure it's worth trying to do anything special with such cases, but I'm
also not sure it's not.)

I suspect this is the scenario you actually want to address, but as far
as I can see you stated neither of those conditions (though I _think_
the patch you show restricts itself to those cases, under a few
reasonable assumptions about the hardware and when/how it traps and
what returning to userland without delivering the signal does).

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B