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

Hi!
I've tested this patch (VM w/ bus lock detection and w/o split lock 
detection). The warn mode works fine and as expected with only one 
notification per task. However, the ratelimit mode has been changed too: 
only one notification per task will be in dmesg, because this mode 
reuses notification code of warn mode. But in the documentation for 
ratelimit mode there is nothing about the limit of notifications: "Limit 
bus lock rate to N bus locks per second system wide and warn on bus 
locks.". Thus, I think that ratelimit mode should remain old behaviour.

On 9/10/25 19:21, Pedro Falcato wrote:
> 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);

-- 
Best regards,
Maksim Davydov

On Wed, Sep 17, 2025 at 05:41:11PM +0300, Maksim Davydov wrote:
> Hi!

Hi!

> I've tested this patch (VM w/ bus lock detection and w/o split lock
> detection). The warn mode works fine and as expected with only one
> notification per task. However, the ratelimit mode has been changed too:
> only one notification per task will be in dmesg, because this mode reuses
> notification code of warn mode. But in the documentation for ratelimit mode
> there is nothing about the limit of notifications: "Limit bus lock rate to N
> bus locks per second system wide and warn on bus locks.". Thus, I think that
> ratelimit mode should remain old behaviour.
>

So, you're suggesting different "warn" behaviors depending on =warn vs
=ratelimit? I don't have a particularly strong opinion here, but I was assuming
that "warn on bus locks" means "do whatever =warn is supposed to do". I'm not
sure warning every time gains you much, though.

-- 
Pedro

On 9/17/25 18:37, Pedro Falcato wrote:
> On Wed, Sep 17, 2025 at 05:41:11PM +0300, Maksim Davydov wrote:
>> Hi!
> 
> Hi!
> 
>> I've tested this patch (VM w/ bus lock detection and w/o split lock
>> detection). The warn mode works fine and as expected with only one
>> notification per task. However, the ratelimit mode has been changed too:
>> only one notification per task will be in dmesg, because this mode reuses
>> notification code of warn mode. But in the documentation for ratelimit mode
>> there is nothing about the limit of notifications: "Limit bus lock rate to N
>> bus locks per second system wide and warn on bus locks.". Thus, I think that
>> ratelimit mode should remain old behaviour.
>>
> 
> So, you're suggesting different "warn" behaviors depending on =warn vs
> =ratelimit? I don't have a particularly strong opinion here, but I was assuming
> that "warn on bus locks" means "do whatever =warn is supposed to do". I'm not
> sure warning every time gains you much, though.
> 

For me, it's ok to reduce the number of messages to one per task.

By the way, I read the patch again and noticed that split_lock_warn() 
and handle_bus_lock() print messages in the same way. Maybe, it'll be 
better to implement an auxiliary wrapper for printing 
split_lock/bus_lock warning messages (for example, 
print_sl_warn_once()), what do you think?

-- 
Best regards,
Maksim Davydov