LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Jörn Engel" <joern@wohnheim.fh-wedel.de>
To: Albert Cahalan <albert@users.sourceforge.net>
Cc: Ingo Oeser <ioe-lkml@rameria.de>,
	bruce@perens.com, Linus Torvalds <torvalds@osdl.org>,
	linux-kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: Never mind. Re: Signal left blocked after signal handler.
Date: Thu, 27 Nov 2003 18:26:37 +0100	[thread overview]
Message-ID: <20031127172637.GB28676@wohnheim.fh-wedel.de> (raw)
In-Reply-To: <1069947938.722.437.camel@cube>

On Thu, 27 November 2003 10:45:39 -0500, Albert Cahalan wrote:
> 
> It has benefits:
> 
> 1. Continuous respawning is no good.

But trivial to notice. :)

> 2. If the processes sleeps, you can attach a debugger.

If aunt Tilly has a core dump, her son can extract it and send it to
some developer.  No need for you to drive over to aunt Tilly.

> The obviously correct behavior is to go back into
> user space, likely to take the signal again. The only
> thing wrong with this is that it eats CPU time.
> So _pretend_ to do that. Have the process sleep,
> ideally with an "R" state as seen in /proc, and maybe
> even go back to the crazy loop if someone attaches a
> debugger.
> 
> The crazy loop is most correct though. It's what the
> user asked for. It perfectly handles the case of a
> repeating SIGFPE (blocked) followed by some other
> thread unmapping a page of instructions or data that
> turns the SIGFPE into a SIGSEGV.

"It just what you asked for, but not what you wanted."

I am a firm non-believer in the trust-the-programmer paradigm.  How
many people actually intend to do NULL-pointer dereferences, etc?  To
make this possible "if you really really want to" is ok, but at least
make the bad behaviour hard to trigger by accident.

What Linux did in 2.5.7x is not exacly what I would have done, but it
makes it hard to do the Wrong Thing (tm) by accident, while allowing
it for those who really want it.  Good enough for most users.

Jörn

-- 
Those who come seeking peace without a treaty are plotting.
-- Sun Tzu

  reply	other threads:[~2003-11-27 17:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-26 21:53 Albert Cahalan
2003-11-27  9:11 ` Ingo Oeser
2003-11-27 15:45   ` Albert Cahalan
2003-11-27 17:26     ` Jörn Engel [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-11-26 17:39 Bruce Perens
2003-11-26 17:55 ` Linus Torvalds
     [not found]   ` <3FC4ED5F.4090901@perens.com>
     [not found]     ` <3FC4EF24.9040307@perens.com>
     [not found]       ` <3FC4F248.8060307@perens.com>
2003-11-26 18:45         ` Never mind. " Linus Torvalds
2003-11-26 19:04           ` Bruce Perens
2003-11-26 19:14             ` Linus Torvalds
2003-11-26 19:52               ` Jamie Lokier

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=20031127172637.GB28676@wohnheim.fh-wedel.de \
    --to=joern@wohnheim.fh-wedel.de \
    --cc=albert@users.sourceforge.net \
    --cc=bruce@perens.com \
    --cc=ioe-lkml@rameria.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    --subject='Re: Never mind. Re: Signal left blocked after signal handler.' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).