mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "David Schwartz" <davids@webmaster.com>
To: "Mike Fedyk" <mfedyk@matchmail.com>
Cc: "Hank Leininger" <hlein@progressive-comp.com>,
	<linux-kernel@vger.kernel.org>
Subject: RE: Dumb question: Why are exceptions such as SIGSEGV not logged
Date: Mon, 18 Aug 2003 15:53:17 -0700	[thread overview]
Message-ID: <MDEHLPKNGKAHNMBLJOLKCEFNFDAA.davids@webmaster.com> (raw)
In-Reply-To: <20030818224409.GJ10320@matchmail.com>



> On Mon, Aug 18, 2003 at 03:39:15PM -0700, David Schwartz wrote:

> > > And why not just catch the ones sent from the kernel?  That's
> > > the one that
> > > is killing the program because it crashed, and that's the one the
> > > origional
> > > poster wants logged...

> > 	Because sometimes a program wants to terminate. And it is
> > perfectly legal
> > for a programmer who needs to terminate his program as quickly
> > as possible
> > to do this:

> > char *j=NULL;
> > signal(SIGSEGV, SIG_DFL);
> > *j++;

> > 	This is a perfectly sensible thing for a program to do with
> > well-defined
> > semantics. If a program wants to create a child every minute
> > like this and
> > kill it, that's perfectly fine. We should be able to do that in
> > the default
> > configuration without a sysadmin complaining that we're DoSing
> > his syslogs.

> Are you saying that a signal requested from userspace uses the same code
> path as the signal sent when a process has overstepped its bounds?

	It depends what you mean by "requested".

> Surely some flag can be set so that we know the kernel is killing
> it because
> it did something illegal...

	It depends what you mean by "illegal".

	Dereferencing a NULL pointer deliberately to induce the kernel to kill your
process is indistinguishable from dereferencing a NULL pointer accidentally
and forcing the kernel to kill your process.

	These "illegal" operations have well-defined semantics that programmers can
use and rely on. Logging every such operation changes their semantics and
breaks programs that currently work -- breaks in the sense that they will
now DoS logs and result in admin complaints.

	The kernel cannot determine whether a SEGV or ILL was the result of a
deliberate attempt on the part of the programmer to create such a signal or
whether it's due to a programming error. Even an uncaught exception can be
used as a good way to terminate a process immediately (is there another
portable way to do that?).

	DS



  reply	other threads:[~2003-08-18 22:53 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-18 20:50 Hank Leininger
2003-08-18 21:02 ` Mike Fedyk
2003-08-18 21:18   ` Hank Leininger
2003-08-18 21:25     ` Mike Fedyk
2003-08-18 22:12   ` William Lee Irwin III
2003-08-18 22:39   ` David Schwartz
2003-08-18 22:44     ` Mike Fedyk
2003-08-18 22:53       ` David Schwartz [this message]
2003-08-19  6:54     ` Denis Vlasenko
2003-08-19  8:31       ` Proposal (was: Why are exceptions such as SIGSEGV not logged) Jakob Oestergaard
2003-08-19 14:52       ` Dumb question: Why are exceptions such as SIGSEGV not logged Valdis.Kletnieks
2003-08-19 18:51       ` David Schwartz
  -- strict thread matches above, loose matches on Subject: below --
2003-08-18  1:56 Hank Leininger
     [not found] <lv8Y.2XU.9@gated-at.bofh.it>
     [not found] ` <lv8Y.2XU.11@gated-at.bofh.it>
     [not found]   ` <lv8Y.2XU.13@gated-at.bofh.it>
     [not found]     ` <lviD.35d.3@gated-at.bofh.it>
     [not found]       ` <lviD.35d.1@gated-at.bofh.it>
     [not found]         ` <lvC1.3p9.11@gated-at.bofh.it>
2003-08-17 14:29           ` Ihar 'Philips' Filipau
     [not found] <lg0i.6yo.11@gated-at.bofh.it>
     [not found] ` <lgjJ.6Oo.5@gated-at.bofh.it>
     [not found]   ` <lilr.p2.7@gated-at.bofh.it>
     [not found]     ` <livc.wX.17@gated-at.bofh.it>
2003-08-17 12:43       ` Ihar 'Philips' Filipau
     [not found]     ` <lj7O.14a.1@gated-at.bofh.it>
2003-08-17 12:52       ` Ihar 'Philips' Filipau
2003-08-17 13:09         ` Alan Cox
     [not found]     ` <lOll.3Jp.19@gated-at.bofh.it>
2003-08-18  9:34       ` Ihar 'Philips' Filipau
2003-08-18 17:26         ` David Schwartz
2003-08-16 20:10 Michael Frank
2003-08-16 20:49 ` Valdis.Kletnieks
2003-08-16 21:42   ` Jamie Lokier
2003-08-16 23:06   ` David D. Hagood
2003-08-16 23:17     ` Doug McNaught
2003-08-16 23:41       ` Dr. David Alan Gilbert
2003-08-17  8:17         ` Russell King
2003-08-16 23:49     ` Alan Cox
2003-08-17 20:54     ` Jakob Oestergaard
2003-08-18  4:28       ` Michael Frank
2003-08-18  9:15     ` David Schwartz
2003-08-19  2:43       ` H. Peter Anvin
2003-08-19 13:27         ` Jesse Pollard
2003-08-19 19:28         ` David Schwartz
2003-08-19 19:34           ` H. Peter Anvin
2003-08-19 20:01             ` David Schwartz
2003-08-18 14:31 ` William Lee Irwin III
2003-08-18 17:52   ` Michael Frank

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=MDEHLPKNGKAHNMBLJOLKCEFNFDAA.davids@webmaster.com \
    --to=davids@webmaster.com \
    --cc=hlein@progressive-comp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mfedyk@matchmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome