linux-kernel - Re: [PATCH] dump

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 30 Oct 2007 20:30:03 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Andi Kleen <andi@...stfloor.org>
cc:	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Christoph Hellwig <hch@...radead.org>,
	Daniel Walker <dwalker@...sta.com>
Subject: Re: [PATCH] dump_stack on panic

--
On Wed, 31 Oct 2007, Andi Kleen wrote:

> Steven Rostedt <rostedt@...dmis.org> writes:
>
> > Is there any reason why we don't do a dump_stack on panic?
>
> One (mostly psychological, but still serious) problem is that stack
> dumps make panics always look like kernel bugs.  But there are panics
> which are definitely not kernel bugs: like the popular cannot mount
> root or machine checks or a couple of others.

Good point.

>
> We do not want users to send all these panics to linux-kernel
> and they would if they look too much like kernel bugs.
>
> I think it's in principle a good idea, but only if you
> distingush the cases which are not kernel bugs.
> e.g. use a different panic() call for them that does not dump.
>

Do you think adding a panic_nodump() call would be fine for those few
locations that is obviously a user/machine bug. This way we could make a
wrapper for panic. Change panic to have a dump parameter.

e.g.

  void __panic(int dump, const char * fmt, ...);

  #define panic(x...) __panic(1, x)
  #define panic_nodump(x...) __panic(0, x)

hmm, that will cause the print format to need to be changed, and if
someone screws up their formanting, the offset of parameters will be off.

Perhaps stripping most of the panic code into separate static functions,
and having two normal functions panic and panic_nodump might be better.

Thoughts?

-- Steve

-
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/