linux-kernel - Re: test 1: was: Re: A Comparison of printk between upstream and linux-rt-devel

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: <Zsyafduo2UItzLAK@pathway.suse.cz>
Date: Mon, 26 Aug 2024 17:08:45 +0200
From: Petr Mladek <pmladek@...e.com>
To: Derek Barbosa <debarbos@...hat.com>
Cc: pmaldek@...e.com, williams@...hat.com, john.ogness@...utronix.de,
	tglx@...utronix.de, linux-rt-users@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: test 1: was: Re: A Comparison of printk between upstream and
 linux-rt-devel

On Mon 2024-08-26 10:46:52, Derek Barbosa wrote:
> On Mon, Aug 26, 2024 at 04:02:34PM +0200, Petr Mladek wrote:
> > > If you have any other questions, please let me know. I would be happy to re-do
> > > these tests with different kernels, configs + other variables and controls.
> > 
> > It might be interesting to redo the 1st test without the crashdump.
> > I wonder if console_flush_on_panic() would allow to see the panic
> > backtrace with the stock kernel.
> 
> Sure. 
> 
> I disabled the systemd kdump service unit via systemctl, and performed a reboot
> to ensure that the crashkernel would not be armed.
> 
> Performing a trial run of console_blast.sh shows results similar to what was
> documented previously, with the difference being we don't reboot after the test
> is completed and the kernel has effectively "crashed" via the sysrq-trigger.
>
> I have appended the serial console output as an attachment. You will see that we
> do not get a final trace printed.
>
> [   98.341743] sysrq: Show State
> [   98.341746] sysrq: Show State
> [   98.341805] sysrq: Show State
> [   98.341808] sysrq: Show State
> [   98.341812] task:systemd         state:S
> [   98.341814] task:systemd         state:S
> [   98.341814]  stack:0     pid:1     tgid:1     ppid:0      flags:0x00000002
> [   98.341818]  stack:0     pid:1     tgid:1     ppid:0      flags:0x00000002
[...]
> [  111.777491]  ? __pfx_hrtimer_wakeup+0x10/0x10
> ** 8555 printk messages dropped **
> [  111.807996]  ? __lruvec_stat_mod_folio+0x86/0xd0
> 

I see. I guess that the panic CPU ended in a deadlock in
console_flush_on_panic() after it ignored the console_lock().
Otherwise, it would have flushed the last messages and rebooted.

Best Regards,
Petr