| To: | Atsushi Nemoto <nemoto@toshiba-tops.co.jp> |
|---|---|
| Subject: | Re: setup_frame() failure |
| From: | Ralf Baechle <ralf@oss.sgi.com> |
| Date: | Fri, 14 Sep 2001 22:14:55 +0200 |
| Cc: | linux-mips@oss.sgi.com |
| In-reply-to: | <20010914.111632.41627160.nemoto@toshiba-tops.co.jp>; from nemoto@toshiba-tops.co.jp on Fri, Sep 14, 2001 at 11:16:32AM +0900 |
| References: | <20010910.114402.41626914.nemoto@toshiba-tops.co.jp> <20010912.130914.112630116.nemoto@toshiba-tops.co.jp> <20010913031119.B27168@dea.linux-mips.net> <20010914.111632.41627160.nemoto@toshiba-tops.co.jp> |
| Sender: | owner-linux-mips@oss.sgi.com |
| User-agent: | Mutt/1.2.5i |
On Fri, Sep 14, 2001 at 11:16:32AM +0900, Atsushi Nemoto wrote:
> ralf> The actual fix should be skipping over the faulting instruction
> ralf> when returning from the signal handler.
>
> Since the signal handler may want to know the faulting instruction,
> the "skipping" should be done AFTER the returning from the handler.
> On the other hand, the handler may do the "skipping" by itself...
>
> The symptom I reported first ("the process can not be killd by
> SIGKILL") does not occur if the signal handler executed successfully
> because do_signal() will be called when returning from sys_sygreturn.
> The symptom occur if setup_frame() failed. So I still think there is
> a point to check a failure of setup_frame().
Certain I/O models use a large number of signals so we're trying hard to
keep signal latency down. The current code already can guarantee proper
termination in case of a stack fault, just not the shortest way.
Ralf
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: The Linux binutils vs. the FSF binutils on Linux/mips, Eric Christopher |
|---|---|
| Next by Date: | Framax DOKA For Sale, Ceri |
| Previous by Thread: | Re: setup_frame() failure, Atsushi Nemoto |
| Next by Thread: | Re: setup_frame() failure, Atsushi Nemoto |
| Indexes: | [Date] [Thread] [Top] [All Lists] |