On Thu 2025-01-16 08:10:44, Joe Lawrence wrote:

On 1/16/25 04:29, Petr Mladek wrote:

quoted

On Tue 2025-01-14 20:01:44, Madhavan Srinivasan wrote:

quoted

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.

quoted

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