[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: emulating no-senders notifications in L4?
From: |
Adam Olsen |
Subject: |
Re: emulating no-senders notifications in L4? |
Date: |
Wed, 2 Jan 2002 02:23:38 +0000 |
User-agent: |
Mutt/1.3.23i |
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