[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070226120154.GD3386@elf.ucw.cz>
Date: Mon, 26 Feb 2007 13:01:54 +0100
From: Pavel Machek <pavel@....cz>
To: David Howells <dhowells@...hat.com>
Cc: Markus Gutschke <markus@...gle.com>,
"Kawai, Hidehiro" <hidehiro.kawai.ez@...achi.com>,
Andrew Morton <akpm@...l.org>,
kernel list <linux-kernel@...r.kernel.org>,
Robin Holt <holt@....com>, Alan Cox <alan@...rguk.ukuu.org.uk>,
Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
sugita <yumiko.sugita.yf@...achi.com>,
Satoshi OSHIMA <soshima@...hat.com>
Subject: Re: [PATCH 0/4] coredump: core dump masking support v3
> > While I am sure you could construct scenarios where this would happen,
> > realistically the only one I have run into were stack overflows, and they can
> > be handled by carefully setting up an alternate stack for signal handlers --
> > just make sure the entire stack is already dirtied before you run out of
> > memory (or, turn of overcommitting).
>
> Duff SIGSEGV or SIGBUS signal handlers are just as realistic. All that takes
> is for someone to make a programming error. Remember: error paths are the
> least frequently tested.
>
> And any time you say "by carefully setting up" you can guarantee someone's
> going to do it wrong.
By same argument, we should just give up the coredumping in kernel. It
is rarely tested, so someone will just get it wrong.
Remember: we are having people with huge apps, and therefore huge
coredumps. They want to hack a kernel in ugly way to make their dumps
smaller.
...but there's better solution for them, create (& debug) userland
coredumping library. No need to hack a kernel.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists