linux-kernel - Re: [PATCH RESEND] x86/split_lock: Warn for bus locks once for each task

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3c7c5bca-5d3f-4878-b6d4-72b036e8b588@yandex-team.ru>
Date: Wed, 17 Sep 2025 17:41:11 +0300
From: Maksim Davydov <davydov-max@...dex-team.ru>
To: Pedro Falcato <pfalcato@...e.de>
Cc: "H. Peter Anvin" <hpa@...or.com>,
 "Peter Zijlstra (Intel)" <peterz@...radead.org>,
 linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
 Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
 Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org
Subject: Re: [PATCH RESEND] x86/split_lock: Warn for bus locks once for each
 task

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@...e.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