> Hi,
>
> > I don't see the program hanging. Instead, I see it looping, using
> > about 50% of the available CPU. It is still responsive to ^C, etc.
> > This is what I would expect because you are trying to produce a
> > double-fault and the kernel won't let you do this. However, you
> > have prevented the kernel from using its normal fault-handler, so
> > what would you expect? The program appears to perform exactly
> > as coded. If there is no signal-stack, you don't get a signal.
> > You deliberately used your signal stack via recursion and you
> > have no trap to force an exit so what you see is what you get.
>
> >From the Single Unix Specification, Version 2, getrlimit();
>
> <QUOTE>
> RLIMIT_STACK
> This is the maximum size of a process' stack in bytes. The
> implementation will not automatically grow the stack beyond this limit. If
> this limit is exceeded, SIGSEGV is generated for the thread. If the thread
> is blocking SIGSEGV, or the process is ignoring or catching SIGSEGV and
> has not made arrangements to use an alternate stack, the disposition of
> SIGSEGV will be set to SIG_DFL before it is generated.
> </QUOTE>
>
> Tigran was catching SIGSEGV (ie. has a handler), and there was no
> alternative stack. Linux isn't setting the disposition of SIGSEGV for
> an exceeded stack to SIG_DFL. Hence the looping, and the breaking of the
> standard. At least that's how I read it, I could be wrong....
>
> Simply loosening the condition under the give_sigsegv label, where the
> handler is set to SIG_DFL, in setup_frame()/setup_rt_frame() should be
> sufficient...?
>
So you are saying that setup_frame() should reserve enough signal
stack-space to use the default handler if the signal stack grows
beyond limits? Let's look at the case of root where there is no
getrlimit set.
Perhaps, generically, there should be enough stack-space reserved to
handle the default signal. This would allow an overflow to be caught in
all cases.
I think it could be done easier than that. If you are going to SIGSEGV,
and you are running out of stack, you could use any place on the signal
stack because the existing return addresses are never going to be used.
In other words, reset the signal stack-pointer, change the vector to
SIG_DFL, and let it happen. This may screw up observations of the
core-dump if it is turned on, but do we have any tools that actually
look at the signal stack on a core-dump?
Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.2.2 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
Wisdom : It's not a Y2K problem. It's a Y2Day problem.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/