Sometimes, it's possible to see long-running services that keep pounding
the bus_lock logic in a long-standing way that does not trigger
ratelimiting, but still floods the dmesg nonetheless, over time.
Fix it by using current->reported_split_lock, which was previously
used for the split_lock handling. In this way, bus_lock #DB's are only
warned once in the dmesg, for each task that hits a bus lock.
Signed-off-by: Pedro Falcato <pfalcato@suse.de>
---
This is already reflected in the documentation for bus lock, as "Warn
once per task and and continues to run.".
Resend since the first mail had accidentally no mailing list in CC.
arch/x86/kernel/cpu/bus_lock.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/bus_lock.c b/arch/x86/kernel/cpu/bus_lock.c
index 981f8b1f0792..71342e6244e3 100644
--- a/arch/x86/kernel/cpu/bus_lock.c
+++ b/arch/x86/kernel/cpu/bus_lock.c
@@ -335,8 +335,11 @@ void handle_bus_lock(struct pt_regs *regs)
/* Warn on the bus lock. */
fallthrough;
case sld_warn:
- pr_warn_ratelimited("#DB: %s/%d took a bus_lock trap at address: 0x%lx\n",
+ if (!current->reported_split_lock) {
+ pr_warn_ratelimited("#DB: %s/%d took a bus_lock trap at address: 0x%lx\n",
current->comm, current->pid, regs->ip);
+ current->reported_split_lock = 1;
+ }
break;
case sld_fatal:
force_sig_fault(SIGBUS, BUS_ADRALN, NULL);
--
2.51.0