linux-mips
[Top] [All Lists]

Re: setup_frame() failure

To: ralf@oss.sgi.com
Subject: Re: setup_frame() failure
From: Atsushi Nemoto <nemoto@toshiba-tops.co.jp>
Date: Mon, 17 Sep 2001 12:28:52 +0900 (JST)
Cc: linux-mips@oss.sgi.com
In-reply-to: <20010914221455.A2272@dea.linux-mips.net>
Organization: TOSHIBA Personal Computer System Corporation
References: <20010913031119.B27168@dea.linux-mips.net> <20010914.111632.41627160.nemoto@toshiba-tops.co.jp> <20010914221455.A2272@dea.linux-mips.net>
Sender: owner-linux-mips@oss.sgi.com
Thanks for your answer.

>>>>> On Fri, 14 Sep 2001 22:14:55 +0200, Ralf Baechle <ralf@oss.sgi.com> said:
ralf> Certain I/O models use a large number of signals so we're trying
ralf> hard to keep signal latency down.

I agree.

ralf> The current code already can guarantee proper termination in
ralf> case of a stack fault, just not the shortest way.

I can not believe it.  There is a case we can not terminate the
process:

a)  If we installed a signal handler for SIGTRAP,
b)  and a signal queued by a "trap" instruction,
c)  and a stack fault occured.

I will show the reason (again):

1.  "trap" instruction raises a exception.
2.  The exception handler queues SIGTRAP(5).
3.  do_signal() dequeue a signal with LOWEST number.
4.  setup_frame() fails and queues SIGSEGV(11).
5.  returns to user process (without compute_return_epc()).
6.  again from 1. (forever)

In this case, dequeue_signal() always return SIGTRAP and any signal
which has a larger number than SIGTRAP never be processed, isn't it?
Or am I missing something?

Thank you.
---
Atsushi Nemoto

<Prev in Thread] Current Thread [Next in Thread>