[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190130144851.GK11489@garbanzo.do-not-panic.com>
Date: Wed, 30 Jan 2019 06:48:51 -0800
From: Luis Chamberlain <mcgrof@...nel.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Vincent Whitchurch <vincent.whitchurch@...s.com>,
keescook@...omium.org, linux-kernel@...r.kernel.org,
Vincent Whitchurch <rabinv@...s.com>
Subject: Re: [PATCH v2] sysctl: Add panic-fatal-signals
On Mon, Jan 28, 2019 at 10:05:45AM -0800, Andrew Morton wrote:
> On Mon, 28 Jan 2019 09:49:59 +0100 Vincent Whitchurch <vincent.whitchurch@...s.com> wrote:
> > --- a/init/Kconfig
> > +++ b/init/Kconfig
> > @@ -1242,6 +1242,20 @@ config SYSCTL_SYSCALL
> >
> > If unsure say N here.
> >
> > +config SYSCTL_PANIC_FATAL_SIGNALS
> > + bool "panic-fatal-signals sysctl" if EXPERT
> > + depends on PROC_SYSCTL
> > + help
> > + If you say Y here, a kernel.panic-fatal-signals sysctl will be
> > + offered. If this sysctl is turned on, the kernel will panic if any
> > + userspace process receives a fatal signal which would trigger a core
> > + dump.
> > +
> > + When used together with kernel core dumps, this can be useful for
> > + debugging some system-wide problems, primarily on embedded systems.
> > +
> > + If unsure, say N.
>
> I suggest that the Kconfig help and the forthcoming documentation
> should clearly explain the dangers of enabling this!
And so, should default to n.
Luis
Powered by blists - more mailing lists