linux-kernel - RE: 5.19 printk breaks message ordering

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: <a35dc47eb9924d56bb6dca7868c34c94@AcuMS.aculab.com>
Date:   Fri, 17 Jun 2022 15:01:33 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Petr Mladek' <pmladek@...e.com>,
        "Jason A. Donenfeld" <Jason@...c4.com>
CC:     John Ogness <john.ogness@...utronix.de>,
        Marco Elver <elver@...gle.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: 5.19 printk breaks message ordering

From: Petr Mladek
> Sent: 17 June 2022 15:21
...
> > I assume this is mostly caused by your threaded printk patchset
> 
> Console has never been fully synchronous. printk() did console_trylock()
> and flushed the message to the console only the lock was available.
> The console kthreads made it asynchronous always when the kthreads
> are available and system is in normal state.

What priority do these kthreads run at?

I'd have thought they ought to run at a high priority?
That should tend to give kernel messages priority over user ones.

Quite how high is another matter.
Probably a bit below the RT/FIFO:50 of threaded ISR.

Although if an x86 one ends up doing software scrolling of
the vga text buffer using the ISA speed accesses that usually
requires maybe not!
Maybe that is faster on modern systems - but I doubt it.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)