From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: John Ogness <john.ogness@linutronix.de>,
Petr Mladek <pmladek@suse.com>, Marco Elver <elver@google.com>,
linux-kernel@vger.kernel.org
Subject: 5.19 printk breaks message ordering
Date: Fri, 17 Jun 2022 15:23:02 +0200 [thread overview]
Message-ID: <YqyANveL50uxupfQ@zx2c4.com> (raw)
Hi John & folks,
In 5.19, I'm seeing some changes in message ordering / interleaving
which lead to confusion. The most obvious (and benign) example appears
on system boot, in which the "Run /init as init process" message gets
intermixed with the messages that init actually writes() to stdout. For
example, here's a snippet from build.wireguard.com:
[ 0.469732] Freeing unused kernel image (initmem) memory: 4576K
[ 0.469738] Write protecting the kernel read-only data: 10240k
[ 0.473823] Freeing unused kernel image (text/rodata gap) memory: 2044K
[ 0.475228] Freeing unused kernel image (rodata/data gap) memory: 1136K
[ 0.475236] Run /init as init process
WireGuard Test Suite on Linux 5.19.0-rc2+ x86_64
[+] Mounting filesystems...
[+] Module self-tests:
* allowedips self-tests: pass
* nonce counter self-tests: pass
* ratelimiter self-tests: pass
[+] Enabling logging...
[+] Launching tests...
[ 0.475237] with arguments:
[ 0.475238] /init
[ 0.475238] with environment:
[ 0.475239] HOME=/
[ 0.475240] TERM=linux
[+] ip netns add wg-test-46-0
[+] ip netns add wg-test-46-1
Before the "with arguments:" and such would print prior to the
"wireguard test suite on linux 5.19" banner. Now it shows after.
I see the same thing with "Freeing unused kernel image (text/rodata gap)
memory" printing interwoven into the console of my initramfs on my
laptop. And so forth.
But the bigger issue for me is that it makes it very confusing to
interpret CI results later on. Prior, I would nice a nice correlation
of:
[+] some userspace command
[ 1.2345 ] some kernel log output
[+] some userspace command
[ 1.2346 ] some kernel log output
[+] some userspace command
[ 1.2347 ] some kernel log output
Now, the kernel log outputs are all over the place and out of order with
the sequence of commands. This makes debugging issues somewhat tricky,
because post hoc ergo propter hoc winds up being a good intuition to
follow when tracking down bugs, and now the post hoc part is muddled.
I assume this is mostly caused by your threaded printk patchset, which
moves some of that printing into a worker, which means it's more
dependent on the scheduler than before. This probably has important
benefits. But it certainly makes CI and related debugging a bit
trickier as a result.
So I was wondering if there was some way to boot the kernel with a
command line option or compile-time flag that always flushes printk
messages when they're made, or does something to make the ordering a bit
more faithful.
Thanks,
Jason
next reply other threads:[~2022-06-17 13:23 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-17 13:23 Jason A. Donenfeld [this message]
2022-06-17 13:37 ` Jason A. Donenfeld
2022-06-17 13:38 ` [PATCH] printk: allow direct console printing to be enabled always Jason A. Donenfeld
2022-06-19 0:30 ` Randy Dunlap
2022-06-19 8:37 ` Jason A. Donenfeld
2022-06-19 11:05 ` John Ogness
2022-06-19 20:39 ` Jason A. Donenfeld
2022-06-19 20:43 ` [PATCH v2] " Jason A. Donenfeld
2022-06-19 23:17 ` John Ogness
2022-06-19 23:28 ` Jason A. Donenfeld
2022-06-19 23:33 ` [PATCH v3] " Jason A. Donenfeld
2022-06-20 16:58 ` Petr Mladek
2022-06-20 17:03 ` Jason A. Donenfeld
2022-06-21 9:43 ` David Laight
2022-06-21 9:59 ` Jason A. Donenfeld
2022-06-22 12:55 ` Jason A. Donenfeld
2022-06-20 4:04 ` [PATCH v2] " David Laight
2022-06-20 5:17 ` Sergey Senozhatsky
2022-06-20 7:56 ` Jason A. Donenfeld
2022-06-21 1:34 ` Sergey Senozhatsky
2022-06-21 21:47 ` John Ogness
2022-06-17 14:21 ` 5.19 printk breaks message ordering Petr Mladek
2022-06-17 14:41 ` Jason A. Donenfeld
2022-06-17 15:01 ` David Laight
2022-06-19 8:15 ` John Ogness
2022-06-19 14:24 ` David Laight
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YqyANveL50uxupfQ@zx2c4.com \
--to=jason@zx2c4.com \
--cc=elver@google.com \
--cc=john.ogness@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=pmladek@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome