Re: Regression in v4.19.106 breaking waking up of readers of /proc/kmsg and /dev/kmsg

[Greg Kroah-Hartman]

On Thu, Feb 27, 2020 at 11:09:49AM +0000, Lech Perczak wrote:
> Hello,
> 
> After upgrading kernel on our boards from v4.19.105 to v4.19.106 we found out that syslog fails to read the messages after ones read initially after opening /proc/kmsg just after booting.
> I also found out, that output of 'dmesg --follow' also doesn't react on new printks appearing for whatever reason - to read new messages, reopening /proc/kmsg or /dev/kmsg was needed.
> I bisected this down to commit 15341b1dd409749fa5625e4b632013b6ba81609b ("char/random: silence a lockdep splat with printk()"), and reverting it on top of v4.19.106 restored correct behaviour.

That is really really odd.

> My test scenario for bisecting was:
> 1. run 'dmesg --follow' as root
> 2. run 'echo t > /proc/sysrq-trigger'
> 3. If trace appears in dmesg output -> good, otherwise, bad. If trace doesn't appear in output of 'dmesg --follow', re-running it will show the trace.
> 
> I ran my tests on Debian 10.3 with configuration based directly on one from 4.19.0-8-amd64 (4.19.98-1) in Qemu.
> I could reproduce the same issue on several boards with x86 and ARMv7 CPUs alike, with 100% reproducibility.
> 
> I haven't yet digged into why exactly this commit breaks notifications for readers of /proc/kmsg and /dev/kmsg, but as reverting it fixed the issue, I'm pretty sure this is the one. It is possible that the same happened in 5.4 line, bu I hadn't had a chance to test this as well yet.

I can revert this, but it feels like there is something else going wrong
here.  Can you try the 5.4 tree to see if that too has your same
problem?

thanks,

greg k-h