linux-kernel - Re: [PATCH v2] panic: Avoid the extra noise dmesg

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]

Message-Id: <20181126155952.46d0c641a69746d33f4212e6@linux-foundation.org>
Date:   Mon, 26 Nov 2018 15:59:52 -0800
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Feng Tang <feng.tang@...el.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>,
        H Peter Anvin <hpa@...ux.intel.com>,
        Borislav Petkov <bp@...en8.de>,
        Kees Cook <keescook@...omium.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] panic: Avoid the extra noise dmesg

On Thu, 8 Nov 2018 21:05:03 +0800 Feng Tang <feng.tang@...el.com> wrote:

> Sometimes when debugging kernel panic, we saw many extra noisy error
> messages after the expected end:
> 
> [   35.743249] ---[ end Kernel panic - not syncing: Fatal exception
> [   35.749975] ------------[ cut here ]------------

What are these "noisy messages"?  The above looks OK?

> When panic happens under console mode, the screen will first show the panic
> call stack, but will immediately be overrided by noisy extra messages, like
> this for every CPU except the panic one:
> 
> 	WARNING: CPU: 1 PID: 280 at kernel/sched/core.c:1198 set_task_cpu+0x183/0x190
> 	Call Trace:
> 	<IRQ>
> 	try_to_wake_up
> 	default_wake_function
> 	autoremove_wake_function
> 	__wake_up_common
> 	__wake_up_common_lock
> 	__wake_up
> 	wake_up_klogd_work_func
> 	irq_work_run_list
> 	irq_work_tick
> 	update_process_times
> 	tick_sched_timer
> 	__hrtimer_run_queues
> 	hrtimer_interrupt
> 	smp_apic_timer_interrupt
> 	apic_timer_interrupt

And this output looks OK as well.

> Which make debugging more difficult, as the original context is
> lost on screen.
> 
> Keeping the CPU IRQ disabled will void these messages, as we code
> run to this point, the user has chosed not to reboot, nor do
> some extra handling with panic notifier, not much point in
> re-enabling the interrupt.

And please have another attempt at the above paragraph?

> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -295,7 +295,6 @@ void panic(const char *fmt, ...)
>  	}
>  #endif
>  	pr_emerg("---[ end Kernel panic - not syncing: %s ]---\n", buf);
> -	local_irq_enable();
>  	for (i = 0; ; i += PANIC_TIMER_STEP) {
>  		touch_softlockup_watchdog();
>  		if (i >= i_next) {

The patch looks reasonable, but the description is just too hard for me
to follow, sorry.  Please spend a bit more time over that and resend?