Re: emulating no-senders notifications in L4?

[Adam Olsen]

On Tue, Jan 01, 2002 at 11:34:49PM +0100, Ondrej Hurt wrote:
> 
> > > The application has the right to trash itself but it should not harm
> > > the rest of the system. In the case of unreliable fault detection, it
> > > is not only the app who will suffer because it can lock resources in
> > > other apps, it can hold references to misc stuff forbiding its
> > > deletion (leaving it 'busy'), it consumes task slot etc.
> 
> 
> > > BUT - I realized that the possibility of exception handler making
> > > another exception making another exception making another exception
> > > ...... is standard in UNIX and we must do it the same way :-/
> 
> 
> 
> I supposed that this exception looping is standard (POSIX).
> 
> I ran the following code on Linux and the Hurd:
> 
> #include <stdlib.h>
> #include <unistd.h>
> #include <signal.h>
> 
> int nsig=0;
> 
> void handler(int x)
> {
>       nsig++;
>       printf("%i ", nsig); fflush(0);
>       *((int*)0) = 0xabcdef;
>       printf("end of handler");
> }
> 
> int main()
> {
>       signal(SIGSEGV, handler);
>       *((int*)0) = 0xabcdef;
>       return 0;
> }
> 
> In Linux, it wrote out all numbers from 1 to 36147, followed by a
> "Segmentation fault" message and then the process stopped. There
> seems to be some limit.
> 
> In the Hurd, only the number "1" was written and that was all. The
> process was not stopped (maybe it would after some time, dunno).
> 
> And I suppose that this would happen on L4:
> 
> 1) you set up an exception handler
> 2) some thread causes exception which is IPCed to the handler
> 3) the handler thread receives the IPC
> 4) the handler causes some exception (not pg fault) itself
> 5) exception is IPCed to the handler again ... but it will not
> receive it because it is already being blocked by this exception
> 
> So the desired(?) "exception looping" will not take place, unless you
> set another thread as exception handler at the beginning of the
> original exception handler. Or am I missing something as usual ? :)
> 
> 
> 
> > Not only that, but exceptions are only one way that a process could
> > get stuck in a loop.  Fixing them is pointless unless you're gonna fix
> > the rest.  And the only way to "fix" a general loop is to put a limit
> > on the process's lifespan.
> >
> > --
> > Adam Olsen, aka Rhamphoryncus
> 
> 
> Why would be fixing of only one part of all possible ill behaviours
> pointless ?

It doesn't gain you anything.  But recursive (that's what it is,
right?) segfault handlers may not be "ill behavior" if they have
defined behavior.[0]

I think it'd be interesting to see if they really are recursive, or
just looping.  To do that you'd need to mprotect a page of memory,
generate the fault on that, then after 30000 or so iterations
un-mprotect it and let the signal handler return.  See if they all
print out "end of handler".


[0] There definetely ARE uses of segfault handlers, and possibly
recursive ones too.

-- 
Adam Olsen, aka Rhamphoryncus