On Mon, 28 Jan 2019 09:49:59 +0100 Vincent Whitchurch <vincent.whitchu...@axis.com> wrote:
> Add a sysctl which asks the kernel to panic when any userspace process > receives a fatal signal which would trigger a core dump. This has > proven to be quite useful when debugging problems seen during testing of > embedded systems: When combined with kernel core dumps (saved due to > the panic), it allows easier debugging of crashes which have their > origin in system-wide problems such as buggy drivers or other kernel or > hardware-related issues. > > The crashing process's core dump can be extracted from the kernel core > dump using tools such as the crash utility's gcore extension. > I can't speak to the usefulness of this, but the feature is small and simple. Some documentation would be appreciated. I assume in Documentation/sysctl/kernel.txt. Please also check that print-fatal-signals is appropriately documented while we're in there - it's documented in Documentation/admin-guide/kernel-parameters.rst but not Documentation/sysctl/kernel.txt. > v2: Put the sysctl behind a config option I suppose so... The option is root-only (surely?) so I'm not sure this is really needed. > ... > > --- 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!
