linux-kernel - Re: [PATCH 1/2] hung_task: Consolidate hung task warning into an atomic log block

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] [day] [month] [year] [list]

Message-ID: <aTlwyfRklNvodnj2@pathway>
Date: Wed, 10 Dec 2025 14:08:25 +0100
From: Petr Mladek <pmladek@...e.com>
To: Aaron Tomlin <atomlin@...mlin.com>
Cc: Greg KH <gregkh@...uxfoundation.org>, Lance Yang <lance.yang@...ux.dev>,
	sean@...e.io, linux-kernel@...r.kernel.org, mhiramat@...nel.org,
	akpm@...ux-foundation.org, John Ogness <john.ogness@...utronix.de>
Subject: Re: [PATCH 1/2] hung_task: Consolidate hung task warning into an
 atomic log block

On Tue 2025-12-09 17:14:40, Aaron Tomlin wrote:
> On Tue, Dec 09, 2025 at 03:56:58PM +0900, Greg KH wrote:
> > > "%s\n" forces an unconditional newline, causing a spurious blank line when
> > > the flag isn't set, right?
> > 
> > The first \n should not be there, this should be all one line.
> 
> Hi Greg,
> 
> I agree. This will be resolved in a subsequent patch.

I am not sure what exactly is requested here. But a multiline message
defined on a single line would be a mess. I mean that

   printk("aaaa\nbbbbb\ncccccc\n") is hard to follow, in compare with

   printk("aaaa\n"
	  "bbbbb\n"
	  "cccccc\n");

IMHO, the only motivation to keep printk() message on a single line is
that it helps grepping. But the "\n" breaks the grepping anyway.


> > If you have multiple lines wanting to be printed, use multiple pr_err()
> > calls.
> 
> Unfortunately, sequential pr_err() calls risk having their lines separated
> by other log messages, rendering the warning incoherent. The single-call
> implementation is necessary to ensure the entire message is atomically
> written.

With the "printk" maintainer hat on, I am a bit afraid to go this way.
printk() is not designed for huge text blobs. Especially:

   + A single record is flushed to a console atomically, often
     under spin lock with IRQs disabled. Too long messages might
     cause soft lockups on slow serial consoles. [*]

   + A single record can't be wrapped at the end of the data buffer.
     Instead, the remaining space gets unused and the message is
     stored from the beginning of the buffer. So, bigger messages
     might cause more unused space. Note that this limitation
     simplified the already complicated lock-less code.

Instead, the caller ID should allow to sort the messages by a post
processing, see CONFIG_PRINTK_CALLER.

[*] The single message does not make a big difference in this case
    because the hung task report is done from atomic context. And
    it is an emergency message so that even nbcon console drivers
    try to flush it immediately.

Best Regards,
Petr