[PATCH] selftests: livepatch: handle PRINTK_CALLER in check_result()

[Petr Mladek]

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