On 01/22/2016 02:12 PM, Heiko Carstens wrote:
> Christian Borntraeger reported that panic_on_warn doesn't have any
> effect on s390.
>
> The panic_on_warn feature was introduced with 9e3961a09798 ("kernel:
> add panic_on_warn"). However it did care only for the case when
> WANT_WARN_ON_SLOWPATH is defined. This is turn is only the case for
> architectures which do not have an own __WARN_TAINT defined.
>
> Other architectures which do have __WARN_TAINT defined call
> report_bug() for warnings within lib/bug.c which does not call panic()
> in case panic_on_warn is set.
>
> Let's simply enable the panic_on_warn feature by adding the same code
> like it was added to warn_slowpath_common() in panic.c.
>
> This enables panic_on_warn also for arm64, parisc, powerpc, s390 and
> sh.
>
> Cc: Prarit Bhargava <[email protected]>
> Reported-by: Christian Borntraeger <[email protected]>
> Signed-off-by: Heiko Carstens <[email protected]>
Tested-by: Christian Borntraeger <[email protected]>
> ---
> lib/bug.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/lib/bug.c b/lib/bug.c
> index cff145f032a5..6cde380f09de 100644
> --- a/lib/bug.c
> +++ b/lib/bug.c
> @@ -175,6 +175,17 @@ enum bug_trap_type report_bug(unsigned long bugaddr,
> struct pt_regs *regs)
> pr_warn("WARNING: at %p [verbose debug info
> unavailable]\n",
> (void *)bugaddr);
>
> + if (panic_on_warn) {
> + /*
> + * This thread may hit another WARN() in the panic path.
> + * Resetting this prevents additional WARN() from
> + * panicking the system on this thread. Other threads
> + * are blocked by the panic_mutex in panic().
> + */
> + panic_on_warn = 0;
> + panic("panic_on_warn set ...\n");
> + }
> +
> print_modules();
> show_regs(regs);
> print_oops_end_marker();
>
