| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <aa0732c6-5c4e-8a8b-a1c1-75ebe3dca05b@camlintechnologies.com>
Date: Thu, 27 Feb 2020 11:09:49 +0000
From: Lech Perczak <l.perczak@...lintechnologies.com>
To: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Theodore Ts'o <tytso@....edu>, Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC: Krzysztof Drobiński
<k.drobinski@...lintechnologies.com>,
Pawel Lenkow <p.lenkow@...lintechnologies.com>
Subject: Regression in v4.19.106 breaking waking up of readers of /proc/kmsg
and /dev/kmsg
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.
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.
For reference, here is my bisect log:
git bisect start
# bad: [f25804f389846835535db255e7ba80eeed967ed7] Linux 4.19.106
git bisect bad f25804f389846835535db255e7ba80eeed967ed7
# good: [4fccc2503536a564a4ba31a1d50439854201659f] Linux 4.19.105
git bisect good 4fccc2503536a564a4ba31a1d50439854201659f
# bad: [aec48d8d0e6e291f61d0a0741bef2f8cc0712584] clk: uniphier: Add SCSSI clock gate for each channel
git bisect bad aec48d8d0e6e291f61d0a0741bef2f8cc0712584
# bad: [5fe69d2ba08f516ace6496d40ac47fe33d3d4ec7] KVM: s390: ENOTSUPP -> EOPNOTSUPP fixups
git bisect bad 5fe69d2ba08f516ace6496d40ac47fe33d3d4ec7
# bad: [15341b1dd409749fa5625e4b632013b6ba81609b] char/random: silence a lockdep splat with printk()
git bisect bad 15341b1dd409749fa5625e4b632013b6ba81609b
# good: [b9dc4d61b5c2d8ea289087f57898426017431391] cpu/hotplug, stop_machine: Fix stop_machine vs hotplug order
git bisect good b9dc4d61b5c2d8ea289087f57898426017431391
# good: [e5c8d49b9be04080f5aab67ea36ac65a30758442] pinctrl: sh-pfc: sh7264: Fix CAN function GPIOs
git bisect good e5c8d49b9be04080f5aab67ea36ac65a30758442
# good: [67f7f0c7e9f4a6c5215e78728261b1d4ab57dcc6] powerpc/powernv/iov: Ensure the pdn for VFs always contains a valid PE number
git bisect good 67f7f0c7e9f4a6c5215e78728261b1d4ab57dcc6
# good: [4802b257d352e48a0b10886b2d1a12b366a17c48] iommu/vt-d: Fix off-by-one in PASID allocation
git bisect good 4802b257d352e48a0b10886b2d1a12b366a17c48
# first bad commit: [15341b1dd409749fa5625e4b632013b6ba81609b] char/random: silence a lockdep splat with printk()
--
Pozdrawiam/With kind regards,
Lech Perczak
Sr. Software Engineer
Camlin Technologies Poland Limited Sp. z o.o.
Powered by blists - more mailing lists