All of lore.kernel.org
 help / color / mirror / Atom feed
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: Mikael Pettersson <mikpe@it.uu.se>
Cc: linux-kernel@vger.kernel.org, shiwh@cn.fujitsu.com
Subject: Re: [PATCH 1/3] signal(i386): alternative signal stack wraparound occurs
Date: Wed, 3 Oct 2007 21:40:29 +0900	[thread overview]
Message-ID: <20071003214029.edcafcc5.kamezawa.hiroyu@jp.fujitsu.com> (raw)
In-Reply-To: <200710031220.l93CK75T028343@harpo.it.uu.se>

On Wed, 3 Oct 2007 14:20:07 +0200 (MEST)
Mikael Pettersson <mikpe@it.uu.se> wrote:

> What I don't agree with is the logic itself:
> - You only catch altstack overflow caused by the kernel pushing
>   a sigframe. You don't catch overflow caused by the user-space
>   signal handler pushing its own stack frame after the sigframe.
> - SUSv3 specifies the effect of altstack overflow as "undefined".
> - The overflow problem can be solved in user-space: allocate the
>   altstack with mmap(), then mprotect() the lowest page to prevent
>   accesses to it. Any overflow into it, by the kernel's signal
>   delivery code or by the user-space signal handler, will be caught.
> 
> So this patch gets a NAK from me.
> 

I can understand what you say, but a program which meets this problem
cannot be debugged ;(

gdb just shows infinit loop of function frames and origignal signal frame
which includes the most important information is overwritten.

Ah yes, user's sigaltstack setup is bad if this happens, but I can't ask
novice programmers to take care of "please verify the page next to
sigaltstack is not mapped or protected." such a thing is not written in man(2)
page of sigaltstack now.


Thanks,
-Kame

  reply	other threads:[~2007-10-03 12:40 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-03 12:20 [PATCH 1/3] signal(i386): alternative signal stack wraparound occurs Mikael Pettersson
2007-10-03 12:40 ` KAMEZAWA Hiroyuki [this message]
2007-10-03 13:20   ` KAMEZAWA Hiroyuki
2007-10-04 11:02 ` Shi Weihua
     [not found] <474CF7D5.6010702@cn.fujitsu.com>
2007-11-28  6:07 ` Fw: " Shi Weihua
2007-12-04 13:02   ` Ingo Molnar
2007-12-04 21:52     ` Roland McGrath
2007-12-04 21:57       ` Ingo Molnar
2007-12-05  5:22       ` Shi Weihua
2007-12-05  5:36         ` Roland McGrath
     [not found] <20071126143317.dd884128.akpm@linux-foundation.org>
     [not found] ` <20071126230242.GA9623@elte.hu>
2007-11-27  3:02   ` Fw: " Roland McGrath
2007-11-27 22:57     ` Arjan van de Ven
  -- strict thread matches above, loose matches on Subject: below --
2007-10-04 13:08 Mikael Pettersson
2007-10-05  0:55 ` Shi Weihua
2007-10-03 13:46 Mikael Pettersson
2007-10-03 14:25 ` KAMEZAWA Hiroyuki
2007-10-04 11:56   ` Shi Weihua
2007-10-04 12:17     ` KAMEZAWA Hiroyuki
2007-10-04 12:33       ` Shi Weihua
2007-10-04 12:47         ` KAMEZAWA Hiroyuki
2007-10-03  8:06 Shi Weihua
2007-11-19  2:15 ` Shi Weihua

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071003214029.edcafcc5.kamezawa.hiroyu@jp.fujitsu.com \
    --to=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikpe@it.uu.se \
    --cc=shiwh@cn.fujitsu.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.