On Thu 2025-01-16 08:10:44, Joe Lawrence wrote:
On 1/16/25 04:29, Petr Mladek wrote:
On Tue 2025-01-14 20:01:44, Madhavan Srinivasan wrote:
Some arch configs (like ppc64) enable CONFIG_PRINTK_CALLER, which adds the caller id as part of the dmesg. Due to this, even though the expected vs observed are same, end testcase results are failed.
CONFIG_PRINTK_CALLER is not the only culprit. We (SUSE) have it enabled as well and the selftests pass without this patch.
The difference might be in dmesg. It shows the caller only when the messages are read via the syslog syscall (-S) option. It should not show the caller when the messages are read via /dev/kmsg which should be the default.
I wonder if you define an alias to dmesg which adds the "-S" option or if /dev/kmsg is not usable from some reason.
Hi Petr,
To see the thread markers on a RHEL-9.6 machine, I built and installed the latest dmesg from:
https://github.com/util-linux/util-linux
and ran Madhavan's tests. I don't think there was any alias involved:
$ alias | grep dmesg (nothing)
$ ~/util-linux/dmesg | tail -n1 [ 4361.322790] [ T98877] % rmmod test_klp_livepatch
Good to know. I havn't seen this yet.
From util-linux's 467a5b3192f1 ("dmesg: add caller_id support"):
The dmesg -S using the old syslog interface supports printing the PRINTK_CALLER field but currently standard dmesg does not support printing the field if present. There are utilities that use dmesg and so it would be optimal if dmesg supported PRINTK_CALLER as well.
does that imply that printing the thread IDs is now a (util-linux's) dmesg default?
It looks like. The caller ID information is available also via /dev/kmsg but the older dmesg version did not show it. I guess that they just added support to parse and show it. It actually makes sense to show the same output independently on whether the messages are read via syslog or /dev/kmsg.
So, we need this patch, definitely ;-)
Best Regards, Petr