* [PATCH 01/62] kvm: Make pi_enable_wakeup_handler() easier to analyze
2026-02-23 21:50 [PATCH 00/62] Bug fixes and refactoring patches related to locking Bart Van Assche
@ 2026-02-23 21:50 ` Bart Van Assche
2026-02-24 18:20 ` Sean Christopherson
2026-02-23 21:50 ` [PATCH 02/62] blk-ioc: Prepare for enabling thread-safety analysis Bart Van Assche
` (18 subsequent siblings)
19 siblings, 1 reply; 37+ messages in thread
From: Bart Van Assche @ 2026-02-23 21:50 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long, linux-kernel,
Marco Elver, Christoph Hellwig, Steven Rostedt, Nick Desaulniers,
Nathan Chancellor, Kees Cook, Jann Horn, Bart Van Assche,
Sean Christopherson, Paolo Bonzini, kvm
The Clang thread-safety analyzer does not support comparing expressions
that use per_cpu(). Hence introduce a new local variable to capture the
address of a per-cpu spinlock. This patch prepares for enabling the
Clang thread-safety analyzer.
Cc: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
arch/x86/kvm/vmx/posted_intr.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/vmx/posted_intr.c b/arch/x86/kvm/vmx/posted_intr.c
index 4a6d9a17da23..f8711b7b85a8 100644
--- a/arch/x86/kvm/vmx/posted_intr.c
+++ b/arch/x86/kvm/vmx/posted_intr.c
@@ -164,6 +164,7 @@ static void pi_enable_wakeup_handler(struct kvm_vcpu *vcpu)
struct pi_desc *pi_desc = vcpu_to_pi_desc(vcpu);
struct vcpu_vt *vt = to_vt(vcpu);
struct pi_desc old, new;
+ raw_spinlock_t *wakeup_lock;
lockdep_assert_irqs_disabled();
@@ -179,11 +180,11 @@ static void pi_enable_wakeup_handler(struct kvm_vcpu *vcpu)
* entirety of the sched_out critical section, i.e. the wakeup handler
* can't run while the scheduler locks are held.
*/
- raw_spin_lock_nested(&per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu),
- PI_LOCK_SCHED_OUT);
+ wakeup_lock = &per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu);
+ raw_spin_lock_nested(wakeup_lock, PI_LOCK_SCHED_OUT);
list_add_tail(&vt->pi_wakeup_list,
&per_cpu(wakeup_vcpus_on_cpu, vcpu->cpu));
- raw_spin_unlock(&per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu));
+ raw_spin_unlock(wakeup_lock);
WARN(pi_test_sn(pi_desc), "PI descriptor SN field set before blocking");
^ permalink raw reply related [flat|nested] 37+ messages in thread* Re: [PATCH 01/62] kvm: Make pi_enable_wakeup_handler() easier to analyze
2026-02-23 21:50 ` [PATCH 01/62] kvm: Make pi_enable_wakeup_handler() easier to analyze Bart Van Assche
@ 2026-02-24 18:20 ` Sean Christopherson
2026-02-24 19:25 ` Bart Van Assche
0 siblings, 1 reply; 37+ messages in thread
From: Sean Christopherson @ 2026-02-24 18:20 UTC (permalink / raw)
To: Bart Van Assche
Cc: Peter Zijlstra, Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long,
linux-kernel, Marco Elver, Christoph Hellwig, Steven Rostedt,
Nick Desaulniers, Nathan Chancellor, Kees Cook, Jann Horn,
Paolo Bonzini, kvm
For the scope, please use:
KVM: VMX:
On Mon, Feb 23, 2026, Bart Van Assche wrote:
> The Clang thread-safety analyzer does not support comparing expressions
> that use per_cpu(). Hence introduce a new local variable to capture the
> address of a per-cpu spinlock. This patch prepares for enabling the
> Clang thread-safety analyzer.
>
> Cc: Sean Christopherson <seanjc@google.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: kvm@vger.kernel.org
> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
> ---
> arch/x86/kvm/vmx/posted_intr.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/kvm/vmx/posted_intr.c b/arch/x86/kvm/vmx/posted_intr.c
> index 4a6d9a17da23..f8711b7b85a8 100644
> --- a/arch/x86/kvm/vmx/posted_intr.c
> +++ b/arch/x86/kvm/vmx/posted_intr.c
> @@ -164,6 +164,7 @@ static void pi_enable_wakeup_handler(struct kvm_vcpu *vcpu)
> struct pi_desc *pi_desc = vcpu_to_pi_desc(vcpu);
> struct vcpu_vt *vt = to_vt(vcpu);
> struct pi_desc old, new;
> + raw_spinlock_t *wakeup_lock;
>
> lockdep_assert_irqs_disabled();
>
> @@ -179,11 +180,11 @@ static void pi_enable_wakeup_handler(struct kvm_vcpu *vcpu)
> * entirety of the sched_out critical section, i.e. the wakeup handler
> * can't run while the scheduler locks are held.
> */
> - raw_spin_lock_nested(&per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu),
> - PI_LOCK_SCHED_OUT);
> + wakeup_lock = &per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu);
Addressing this piecemeal doesn't seem maintainable in the long term. The odds
of unintentionally regressing the coverage with a cleanup are rather high. Or
we'll end up with confused and/or grumpy developers because they're required to
write code in a very specific way because of what are effectively shortcomings
in the compiler.
> + raw_spin_lock_nested(wakeup_lock, PI_LOCK_SCHED_OUT);
> list_add_tail(&vt->pi_wakeup_list,
> &per_cpu(wakeup_vcpus_on_cpu, vcpu->cpu));
> - raw_spin_unlock(&per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu));
> + raw_spin_unlock(wakeup_lock);
>
> WARN(pi_test_sn(pi_desc), "PI descriptor SN field set before blocking");
>
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 01/62] kvm: Make pi_enable_wakeup_handler() easier to analyze
2026-02-24 18:20 ` Sean Christopherson
@ 2026-02-24 19:25 ` Bart Van Assche
2026-02-26 17:47 ` Sean Christopherson
0 siblings, 1 reply; 37+ messages in thread
From: Bart Van Assche @ 2026-02-24 19:25 UTC (permalink / raw)
To: Sean Christopherson
Cc: Peter Zijlstra, Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long,
linux-kernel, Marco Elver, Christoph Hellwig, Steven Rostedt,
Nick Desaulniers, Nathan Chancellor, Kees Cook, Jann Horn,
Paolo Bonzini, kvm
On 2/24/26 10:20 AM, Sean Christopherson wrote:
> For the scope, please use:
>
> KVM: VMX:
>
> On Mon, Feb 23, 2026, Bart Van Assche wrote:
>> The Clang thread-safety analyzer does not support comparing expressions
>> that use per_cpu(). Hence introduce a new local variable to capture the
>> address of a per-cpu spinlock. This patch prepares for enabling the
>> Clang thread-safety analyzer.
>>
>> Cc: Sean Christopherson <seanjc@google.com>
>> Cc: Paolo Bonzini <pbonzini@redhat.com>
>> Cc: kvm@vger.kernel.org
>> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
>> ---
>> arch/x86/kvm/vmx/posted_intr.c | 7 ++++---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/x86/kvm/vmx/posted_intr.c b/arch/x86/kvm/vmx/posted_intr.c
>> index 4a6d9a17da23..f8711b7b85a8 100644
>> --- a/arch/x86/kvm/vmx/posted_intr.c
>> +++ b/arch/x86/kvm/vmx/posted_intr.c
>> @@ -164,6 +164,7 @@ static void pi_enable_wakeup_handler(struct kvm_vcpu *vcpu)
>> struct pi_desc *pi_desc = vcpu_to_pi_desc(vcpu);
>> struct vcpu_vt *vt = to_vt(vcpu);
>> struct pi_desc old, new;
>> + raw_spinlock_t *wakeup_lock;
>>
>> lockdep_assert_irqs_disabled();
>>
>> @@ -179,11 +180,11 @@ static void pi_enable_wakeup_handler(struct kvm_vcpu *vcpu)
>> * entirety of the sched_out critical section, i.e. the wakeup handler
>> * can't run while the scheduler locks are held.
>> */
>> - raw_spin_lock_nested(&per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu),
>> - PI_LOCK_SCHED_OUT);
>> + wakeup_lock = &per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu);
>
> Addressing this piecemeal doesn't seem maintainable in the long term. The odds
> of unintentionally regressing the coverage with a cleanup are rather high. Or
> we'll end up with confused and/or grumpy developers because they're required to
> write code in a very specific way because of what are effectively shortcomings
> in the compiler.
I think it's worth mentioning that the number of patches similar to the
above is small. If I remember correctly, I only encountered two similar
cases in the entire kernel tree.
Regarding why the above patch is necessary, I don't think that it is
fair to blame the compiler in this case. The macros that implement
per_cpu() make it impossible for the compiler to conclude that the
pointers passed to the raw_spin_lock_nested() and raw_spin_unlock()
calls are identical:
/*
* Add an offset to a pointer. Use RELOC_HIDE() to prevent the compiler
* from making incorrect assumptions about the pointer value.
*/
#define SHIFT_PERCPU_PTR(__p, __offset) \
RELOC_HIDE(PERCPU_PTR(__p), (__offset))
#define RELOC_HIDE(ptr, off) \
({ \
unsigned long __ptr; \
__asm__ ("" : "=r"(__ptr) : "0"(ptr)); \
(typeof(ptr)) (__ptr + (off)); \
})
By the way, the above patch is not the only possible solution for
addressing the thread-safety warning Clang reports for this function.
Another possibility is adding __no_context_analysis to the function
definition. Is the latter perhaps what you prefer?
Bart.
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH 01/62] kvm: Make pi_enable_wakeup_handler() easier to analyze
2026-02-24 19:25 ` Bart Van Assche
@ 2026-02-26 17:47 ` Sean Christopherson
2026-02-26 20:13 ` Marco Elver
2026-02-26 22:36 ` Bart Van Assche
0 siblings, 2 replies; 37+ messages in thread
From: Sean Christopherson @ 2026-02-26 17:47 UTC (permalink / raw)
To: Bart Van Assche
Cc: Peter Zijlstra, Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long,
linux-kernel, Marco Elver, Christoph Hellwig, Steven Rostedt,
Nick Desaulniers, Nathan Chancellor, Kees Cook, Jann Horn,
Paolo Bonzini, kvm
On Tue, Feb 24, 2026, Bart Van Assche wrote:
> On 2/24/26 10:20 AM, Sean Christopherson wrote:
> > For the scope, please use:
> >
> > KVM: VMX:
> >
> > On Mon, Feb 23, 2026, Bart Van Assche wrote:
> > > The Clang thread-safety analyzer does not support comparing expressions
> > > that use per_cpu(). Hence introduce a new local variable to capture the
> > > address of a per-cpu spinlock. This patch prepares for enabling the
> > > Clang thread-safety analyzer.
> > >
> > > Cc: Sean Christopherson <seanjc@google.com>
> > > Cc: Paolo Bonzini <pbonzini@redhat.com>
> > > Cc: kvm@vger.kernel.org
> > > Signed-off-by: Bart Van Assche <bvanassche@acm.org>
> > > ---
> > > arch/x86/kvm/vmx/posted_intr.c | 7 ++++---
> > > 1 file changed, 4 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/arch/x86/kvm/vmx/posted_intr.c b/arch/x86/kvm/vmx/posted_intr.c
> > > index 4a6d9a17da23..f8711b7b85a8 100644
> > > --- a/arch/x86/kvm/vmx/posted_intr.c
> > > +++ b/arch/x86/kvm/vmx/posted_intr.c
> > > @@ -164,6 +164,7 @@ static void pi_enable_wakeup_handler(struct kvm_vcpu *vcpu)
> > > struct pi_desc *pi_desc = vcpu_to_pi_desc(vcpu);
> > > struct vcpu_vt *vt = to_vt(vcpu);
> > > struct pi_desc old, new;
> > > + raw_spinlock_t *wakeup_lock;
> > > lockdep_assert_irqs_disabled();
> > > @@ -179,11 +180,11 @@ static void pi_enable_wakeup_handler(struct kvm_vcpu *vcpu)
> > > * entirety of the sched_out critical section, i.e. the wakeup handler
> > > * can't run while the scheduler locks are held.
> > > */
> > > - raw_spin_lock_nested(&per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu),
> > > - PI_LOCK_SCHED_OUT);
> > > + wakeup_lock = &per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu);
> >
> > Addressing this piecemeal doesn't seem maintainable in the long term. The odds
> > of unintentionally regressing the coverage with a cleanup are rather high. Or
> > we'll end up with confused and/or grumpy developers because they're required to
> > write code in a very specific way because of what are effectively shortcomings
> > in the compiler.
>
> I think it's worth mentioning that the number of patches similar to the
> above is small. If I remember correctly, I only encountered two similar
> cases in the entire kernel tree.
Yeah, it's definitely not a deal-breaker to work around this in KVM, especially
if this is one of the few things blocking -Wthread-safety.
> Regarding why the above patch is necessary, I don't think that it is
> fair to blame the compiler in this case. The macros that implement
> per_cpu() make it impossible for the compiler to conclude that the
> pointers passed to the raw_spin_lock_nested() and raw_spin_unlock()
> calls are identical:
Well rats, that pretty much makes it infeasible to solve the underlying problem.
> /*
> * Add an offset to a pointer. Use RELOC_HIDE() to prevent the compiler
> * from making incorrect assumptions about the pointer value.
> */
> #define SHIFT_PERCPU_PTR(__p, __offset) \
> RELOC_HIDE(PERCPU_PTR(__p), (__offset))
>
> #define RELOC_HIDE(ptr, off) \
> ({ \
> unsigned long __ptr; \
> __asm__ ("" : "=r"(__ptr) : "0"(ptr)); \
> (typeof(ptr)) (__ptr + (off)); \
> })
>
> By the way, the above patch is not the only possible solution for
> addressing the thread-safety warning Clang reports for this function.
> Another possibility is adding __no_context_analysis to the function
> definition. Is the latter perhaps what you prefer?
Hmm, I'd prefer to keep the analysis, even though it's a bit of a pain. We already
went through quite some effort to preserve lockdep for this lock; compared to that,
forcing use of local variables is hardly anything.
My only concern is lack of enforcement and documentation. I fiddled with a bunch
of ideas, but mostly of them flamed out because of the aformentioned lockdep
shenanigans. E.g. forcing use of guard() or scoped_guard() doesn't Just Work.
The best idea I came up with is to rename the global variable to something scary,
and then define a CLASS() so that it's syntactically all but impossible to feed
the the result of per_cpu() directly into lock() or unlock().
What's your timeline for enabling -Wthread-safety? E.g. are you trying to land
it in 7.1? 7.2+? I'd be happy to formally post the below and get it landed in
the N-1 kernel (assuming Paolo is also comfortable landing the patch in 7.0 if
you're targeting 7.1).
---
From: Sean Christopherson <seanjc@google.com>
Date: Thu, 26 Feb 2026 07:21:52 -0800
Subject: [PATCH] KVM: VMX: Force wakeup_vcpus_on_cpu_lock to be captured in
local variable
Wrap wakeup_vcpus_on_cpu_lock in a CLASS() and append "do_not_use" to the
per-CPU symbol to effectively force lock()+unlock() paths to capture the
per-CPU lock in a local variable. Clang's thread-safety analyzer doesn't
support comparing lock() vs. unlock() expressions that use separate
per_cpu() invocations (-Wthread-safety generates false-positves), as the
kernel's per_cpu() implementation deliberately hides the resolved address
from the compiler, specifically to prevent the compiler from reasoning
about the symbol. I.e. per_cpu() is a victim of its own success.
Link: https://lore.kernel.org/all/a2ebde260608230500o3407b108hc03debb9da6e62c@mail.gmail.com
Link: https://news.ycombinator.com/item?id=18050983
Suggested-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
arch/x86/kvm/vmx/posted_intr.c | 30 +++++++++++++++++++++++-------
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kvm/vmx/posted_intr.c b/arch/x86/kvm/vmx/posted_intr.c
index 4a6d9a17da23..e08faaeab12f 100644
--- a/arch/x86/kvm/vmx/posted_intr.c
+++ b/arch/x86/kvm/vmx/posted_intr.c
@@ -31,7 +31,21 @@ static DEFINE_PER_CPU(struct list_head, wakeup_vcpus_on_cpu);
* CPU. IRQs must be disabled when taking this lock, otherwise deadlock will
* occur if a wakeup IRQ arrives and attempts to acquire the lock.
*/
-static DEFINE_PER_CPU(raw_spinlock_t, wakeup_vcpus_on_cpu_lock);
+static DEFINE_PER_CPU(raw_spinlock_t, wakeup_vcpus_on_cpu_lock__do_not_touch);
+
+/*
+ * Route accesses to the lock through a CLASS() to effectively force users to
+ * capture the lock in a local variable. The kernel's per_cpu() implementation
+ * deliberately obfuscates the address of the data to prevent the compiler from
+ * making incorrect assumptions about the symbol. However, hiding the address
+ * triggers false-positive thread-safety warnings if lock() vs. unlock() are
+ * called with different per_cpu() invocations, because the compiler can't tell
+ * its the same lock under the hood.
+ */
+DEFINE_CLASS(pi_wakeup_vcpus_lock, raw_spinlock_t *,
+ lockdep_assert_not_held(_T),
+ &per_cpu(wakeup_vcpus_on_cpu_lock__do_not_touch, cpu),
+ int cpu);
#define PI_LOCK_SCHED_OUT SINGLE_DEPTH_NESTING
@@ -90,7 +104,7 @@ void vmx_vcpu_pi_load(struct kvm_vcpu *vcpu, int cpu)
* current pCPU if the task was migrated.
*/
if (pi_desc->nv == POSTED_INTR_WAKEUP_VECTOR) {
- raw_spinlock_t *spinlock = &per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu);
+ CLASS(pi_wakeup_vcpus_lock, spinlock)(cpu);
/*
* In addition to taking the wakeup lock for the regular/IRQ
@@ -165,6 +179,8 @@ static void pi_enable_wakeup_handler(struct kvm_vcpu *vcpu)
struct vcpu_vt *vt = to_vt(vcpu);
struct pi_desc old, new;
+ CLASS(pi_wakeup_vcpus_lock, spinlock)(vcpu->cpu);
+
lockdep_assert_irqs_disabled();
/*
@@ -179,11 +195,10 @@ static void pi_enable_wakeup_handler(struct kvm_vcpu *vcpu)
* entirety of the sched_out critical section, i.e. the wakeup handler
* can't run while the scheduler locks are held.
*/
- raw_spin_lock_nested(&per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu),
- PI_LOCK_SCHED_OUT);
+ raw_spin_lock_nested(spinlock, PI_LOCK_SCHED_OUT);
list_add_tail(&vt->pi_wakeup_list,
&per_cpu(wakeup_vcpus_on_cpu, vcpu->cpu));
- raw_spin_unlock(&per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu));
+ raw_spin_unlock(spinlock);
WARN(pi_test_sn(pi_desc), "PI descriptor SN field set before blocking");
@@ -254,9 +269,10 @@ void pi_wakeup_handler(void)
{
int cpu = smp_processor_id();
struct list_head *wakeup_list = &per_cpu(wakeup_vcpus_on_cpu, cpu);
- raw_spinlock_t *spinlock = &per_cpu(wakeup_vcpus_on_cpu_lock, cpu);
struct vcpu_vt *vt;
+ CLASS(pi_wakeup_vcpus_lock, spinlock)(cpu);
+
raw_spin_lock(spinlock);
list_for_each_entry(vt, wakeup_list, pi_wakeup_list) {
@@ -269,7 +285,7 @@ void pi_wakeup_handler(void)
void __init pi_init_cpu(int cpu)
{
INIT_LIST_HEAD(&per_cpu(wakeup_vcpus_on_cpu, cpu));
- raw_spin_lock_init(&per_cpu(wakeup_vcpus_on_cpu_lock, cpu));
+ raw_spin_lock_init(&per_cpu(wakeup_vcpus_on_cpu_lock__do_not_touch, cpu));
}
void pi_apicv_pre_state_restore(struct kvm_vcpu *vcpu)
base-commit: 183bb0ce8c77b0fd1fb25874112bc8751a461e49
--
^ permalink raw reply related [flat|nested] 37+ messages in thread* Re: [PATCH 01/62] kvm: Make pi_enable_wakeup_handler() easier to analyze
2026-02-26 17:47 ` Sean Christopherson
@ 2026-02-26 20:13 ` Marco Elver
2026-02-27 0:19 ` Bart Van Assche
2026-02-26 22:36 ` Bart Van Assche
1 sibling, 1 reply; 37+ messages in thread
From: Marco Elver @ 2026-02-26 20:13 UTC (permalink / raw)
To: Sean Christopherson
Cc: Bart Van Assche, Peter Zijlstra, Ingo Molnar, Will Deacon,
Boqun Feng, Waiman Long, linux-kernel, Christoph Hellwig,
Steven Rostedt, Nick Desaulniers, Nathan Chancellor, Kees Cook,
Jann Horn, Paolo Bonzini, kvm
On Thu, 26 Feb 2026 at 18:48, Sean Christopherson <seanjc@google.com> wrote:
> On Tue, Feb 24, 2026, Bart Van Assche wrote:
[...]
> > Regarding why the above patch is necessary, I don't think that it is
> > fair to blame the compiler in this case. The macros that implement
> > per_cpu() make it impossible for the compiler to conclude that the
> > pointers passed to the raw_spin_lock_nested() and raw_spin_unlock()
> > calls are identical:
>
> Well rats, that pretty much makes it infeasible to solve the underlying problem.
>
> > /*
> > * Add an offset to a pointer. Use RELOC_HIDE() to prevent the compiler
> > * from making incorrect assumptions about the pointer value.
> > */
> > #define SHIFT_PERCPU_PTR(__p, __offset) \
> > RELOC_HIDE(PERCPU_PTR(__p), (__offset))
> >
> > #define RELOC_HIDE(ptr, off) \
> > ({ \
> > unsigned long __ptr; \
> > __asm__ ("" : "=r"(__ptr) : "0"(ptr)); \
> > (typeof(ptr)) (__ptr + (off)); \
> > })
There's a slim chance we can "fix" this with a similar approach as in:
https://lore.kernel.org/all/20260216142436.2207937-2-elver@google.com/
(specifically see patch 2/2)
The goal of RELOC_HIDE is to make the optimizer be less aggressive.
But the Thread Safety Analysis's alias analysis happens during
semantic analysis and is completely detached from the optimizer, and
we could potentially construct an expression that (a) lets Thread
Safety Analysis figure out that __ptr is an alias to ptr, while (b)
still hiding it from the optimizer. But I think we're sufficiently
scared of breaking (b) that I'm not sure if this is feasible in a
clean enough way that won't have other side-effects (e.g. worse
codegen).
If I find time I'll have a think unless someone beats me to it.
Thanks,
-- Marco
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH 01/62] kvm: Make pi_enable_wakeup_handler() easier to analyze
2026-02-26 20:13 ` Marco Elver
@ 2026-02-27 0:19 ` Bart Van Assche
2026-03-18 23:31 ` Marco Elver
0 siblings, 1 reply; 37+ messages in thread
From: Bart Van Assche @ 2026-02-27 0:19 UTC (permalink / raw)
To: Marco Elver, Sean Christopherson
Cc: Peter Zijlstra, Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long,
linux-kernel, Christoph Hellwig, Steven Rostedt, Nick Desaulniers,
Nathan Chancellor, Kees Cook, Jann Horn, Paolo Bonzini, kvm
On 2/26/26 12:13 PM, Marco Elver wrote:
> The goal of RELOC_HIDE is to make the optimizer be less aggressive.
> But the Thread Safety Analysis's alias analysis happens during
> semantic analysis and is completely detached from the optimizer, and
> we could potentially construct an expression that (a) lets Thread
> Safety Analysis figure out that __ptr is an alias to ptr, while (b)
> still hiding it from the optimizer. But I think we're sufficiently
> scared of breaking (b) that I'm not sure if this is feasible in a
> clean enough way that won't have other side-effects (e.g. worse
> codegen).
Does the thread-safety alias analyzer assume that function calls with
identical inputs produce identical outputs? If so, how about changing
RELOC_HIDE() from a macro into an inline function? Would that be
sufficient to make the thread-safety checker recognize identical
per_cpu() expressions as identical without affecting the behavior of the
optimizer?
Thanks,
Bart.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 01/62] kvm: Make pi_enable_wakeup_handler() easier to analyze
2026-02-27 0:19 ` Bart Van Assche
@ 2026-03-18 23:31 ` Marco Elver
2026-03-19 14:43 ` Marco Elver
0 siblings, 1 reply; 37+ messages in thread
From: Marco Elver @ 2026-03-18 23:31 UTC (permalink / raw)
To: Bart Van Assche
Cc: Sean Christopherson, Peter Zijlstra, Ingo Molnar, Will Deacon,
Boqun Feng, Waiman Long, linux-kernel, Christoph Hellwig,
Steven Rostedt, Nick Desaulniers, Nathan Chancellor, Kees Cook,
Jann Horn, Paolo Bonzini, kvm
On Thu, Feb 26, 2026 at 04:19PM -0800, Bart Van Assche wrote:
> On 2/26/26 12:13 PM, Marco Elver wrote:
> > The goal of RELOC_HIDE is to make the optimizer be less aggressive.
> > But the Thread Safety Analysis's alias analysis happens during
> > semantic analysis and is completely detached from the optimizer, and
> > we could potentially construct an expression that (a) lets Thread
> > Safety Analysis figure out that __ptr is an alias to ptr, while (b)
> > still hiding it from the optimizer. But I think we're sufficiently
> > scared of breaking (b) that I'm not sure if this is feasible in a
> > clean enough way that won't have other side-effects (e.g. worse
> > codegen).
>
> Does the thread-safety alias analyzer assume that function calls with
> identical inputs produce identical outputs? If so, how about changing
> RELOC_HIDE() from a macro into an inline function? Would that be
> sufficient to make the thread-safety checker recognize identical
> per_cpu() expressions as identical without affecting the behavior of the
> optimizer?
The below works:
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index af16624b29fd..cb2f6050bdf7 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -149,10 +149,7 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
#endif
#ifndef RELOC_HIDE
-# define RELOC_HIDE(ptr, off) \
- ({ unsigned long __ptr; \
- __ptr = (unsigned long) (ptr); \
- (typeof(ptr)) (__ptr + (off)); })
+# define RELOC_HIDE(ptr, off) ((typeof(ptr))((unsigned long)(ptr) + (off)))
#endif
#define absolute_pointer(val) RELOC_HIDE((void *)(val), 0)
That preserves original RELOC_HIDE intent (hide likely out-of-bounds
pointer calculation via unsigned long cast) - GCC has its own version of
RELOC_HIDE, so this seems to be exclusively for Clang. For codegen, the
temporary variable was just optimized away, so I'm not sure what benefit
that indirection had at all. So all in all that should be equivalent to
before, and looks a lot cleaner.
The reason it works for Thread Safety Analysis is that TSA's alias
analysis strips away inner casts when resolving pointer aliases. Whereas
if there was an intermediate non-pointer (here: ulong) variable, it
stops.
Unless there are concerns, I'll send that as a patch.
^ permalink raw reply related [flat|nested] 37+ messages in thread* Re: [PATCH 01/62] kvm: Make pi_enable_wakeup_handler() easier to analyze
2026-03-18 23:31 ` Marco Elver
@ 2026-03-19 14:43 ` Marco Elver
0 siblings, 0 replies; 37+ messages in thread
From: Marco Elver @ 2026-03-19 14:43 UTC (permalink / raw)
To: Bart Van Assche
Cc: Sean Christopherson, Peter Zijlstra, Ingo Molnar, Will Deacon,
Boqun Feng, Waiman Long, linux-kernel, Christoph Hellwig,
Steven Rostedt, Nick Desaulniers, Nathan Chancellor, Kees Cook,
Jann Horn, Paolo Bonzini, kvm
On Thu, 19 Mar 2026 at 00:31, Marco Elver <elver@google.com> wrote:
>
> On Thu, Feb 26, 2026 at 04:19PM -0800, Bart Van Assche wrote:
> > On 2/26/26 12:13 PM, Marco Elver wrote:
> > > The goal of RELOC_HIDE is to make the optimizer be less aggressive.
> > > But the Thread Safety Analysis's alias analysis happens during
> > > semantic analysis and is completely detached from the optimizer, and
> > > we could potentially construct an expression that (a) lets Thread
> > > Safety Analysis figure out that __ptr is an alias to ptr, while (b)
> > > still hiding it from the optimizer. But I think we're sufficiently
> > > scared of breaking (b) that I'm not sure if this is feasible in a
> > > clean enough way that won't have other side-effects (e.g. worse
> > > codegen).
> >
> > Does the thread-safety alias analyzer assume that function calls with
> > identical inputs produce identical outputs? If so, how about changing
> > RELOC_HIDE() from a macro into an inline function? Would that be
> > sufficient to make the thread-safety checker recognize identical
> > per_cpu() expressions as identical without affecting the behavior of the
> > optimizer?
>
> The below works:
[...]
> That preserves original RELOC_HIDE intent (hide likely out-of-bounds
> pointer calculation via unsigned long cast) - GCC has its own version of
> RELOC_HIDE, so this seems to be exclusively for Clang. For codegen, the
> temporary variable was just optimized away, so I'm not sure what benefit
> that indirection had at all. So all in all that should be equivalent to
> before, and looks a lot cleaner.
>
> The reason it works for Thread Safety Analysis is that TSA's alias
> analysis strips away inner casts when resolving pointer aliases. Whereas
> if there was an intermediate non-pointer (here: ulong) variable, it
> stops.
>
> Unless there are concerns, I'll send that as a patch.
This should make the KVM code work as-is:
https://lore.kernel.org/all/20260319135245.1420780-1-elver@google.com/
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 01/62] kvm: Make pi_enable_wakeup_handler() easier to analyze
2026-02-26 17:47 ` Sean Christopherson
2026-02-26 20:13 ` Marco Elver
@ 2026-02-26 22:36 ` Bart Van Assche
2026-02-26 22:41 ` Sean Christopherson
1 sibling, 1 reply; 37+ messages in thread
From: Bart Van Assche @ 2026-02-26 22:36 UTC (permalink / raw)
To: Sean Christopherson
Cc: Peter Zijlstra, Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long,
linux-kernel, Marco Elver, Christoph Hellwig, Steven Rostedt,
Nick Desaulniers, Nathan Chancellor, Kees Cook, Jann Horn,
Paolo Bonzini, kvm
On 2/26/26 9:47 AM, Sean Christopherson wrote:
> What's your timeline for enabling -Wthread-safety? E.g. are you trying to land
> it in 7.1? 7.2+? I'd be happy to formally post the below and get it landed in
> the N-1 kernel (assuming Paolo is also comfortable landing the patch in 7.0 if
> you're targeting 7.1).
Hi Sean,
I expect that I will need two or three release cycles to get all the
patches upstream before -Wthread-safety can be enabled. How about
giving Marco a few weeks time to come up with an improvement for
RELOC_HIDE()?
Thanks,
Bart.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 01/62] kvm: Make pi_enable_wakeup_handler() easier to analyze
2026-02-26 22:36 ` Bart Van Assche
@ 2026-02-26 22:41 ` Sean Christopherson
0 siblings, 0 replies; 37+ messages in thread
From: Sean Christopherson @ 2026-02-26 22:41 UTC (permalink / raw)
To: Bart Van Assche
Cc: Peter Zijlstra, Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long,
linux-kernel, Marco Elver, Christoph Hellwig, Steven Rostedt,
Nick Desaulniers, Nathan Chancellor, Kees Cook, Jann Horn,
Paolo Bonzini, kvm
On Thu, Feb 26, 2026, Bart Van Assche wrote:
> On 2/26/26 9:47 AM, Sean Christopherson wrote:
> > What's your timeline for enabling -Wthread-safety? E.g. are you trying to land
> > it in 7.1? 7.2+? I'd be happy to formally post the below and get it landed in
> > the N-1 kernel (assuming Paolo is also comfortable landing the patch in 7.0 if
> > you're targeting 7.1).
>
> Hi Sean,
>
> I expect that I will need two or three release cycles to get all the patches
> upstream before -Wthread-safety can be enabled. How about
> giving Marco a few weeks time to come up with an improvement for
> RELOC_HIDE()?
Works for me. Thanks!
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 02/62] blk-ioc: Prepare for enabling thread-safety analysis
2026-02-23 21:50 [PATCH 00/62] Bug fixes and refactoring patches related to locking Bart Van Assche
2026-02-23 21:50 ` [PATCH 01/62] kvm: Make pi_enable_wakeup_handler() easier to analyze Bart Van Assche
@ 2026-02-23 21:50 ` Bart Van Assche
2026-02-23 21:50 ` [PATCH 03/62] drbd: Balance RCU calls in drbd_adm_dump_devices() Bart Van Assche
` (17 subsequent siblings)
19 siblings, 0 replies; 37+ messages in thread
From: Bart Van Assche @ 2026-02-23 21:50 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long, linux-kernel,
Marco Elver, Christoph Hellwig, Steven Rostedt, Nick Desaulniers,
Nathan Chancellor, Kees Cook, Jann Horn, Bart Van Assche,
Jens Axboe, Yu Kuai, Jan Kara, linux-block
The Clang thread-safety analyzer does not support testing return values
with "< 0". Hence change the "< 0" test into "!= 0". This is fine since
the radix_tree_maybe_preload() return value is <= 0.
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Yu Kuai <yukuai3@huawei.com>
Cc: Jan Kara <jack@suse.cz>
Cc: linux-block@vger.kernel.org
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
block/blk-ioc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/blk-ioc.c b/block/blk-ioc.c
index d15918d7fabb..0bf78aebc887 100644
--- a/block/blk-ioc.c
+++ b/block/blk-ioc.c
@@ -364,7 +364,7 @@ static struct io_cq *ioc_create_icq(struct request_queue *q)
if (!icq)
return NULL;
- if (radix_tree_maybe_preload(GFP_ATOMIC) < 0) {
+ if (radix_tree_maybe_preload(GFP_ATOMIC) != 0) {
kmem_cache_free(et->icq_cache, icq);
return NULL;
}
^ permalink raw reply related [flat|nested] 37+ messages in thread* [PATCH 03/62] drbd: Balance RCU calls in drbd_adm_dump_devices()
2026-02-23 21:50 [PATCH 00/62] Bug fixes and refactoring patches related to locking Bart Van Assche
2026-02-23 21:50 ` [PATCH 01/62] kvm: Make pi_enable_wakeup_handler() easier to analyze Bart Van Assche
2026-02-23 21:50 ` [PATCH 02/62] blk-ioc: Prepare for enabling thread-safety analysis Bart Van Assche
@ 2026-02-23 21:50 ` Bart Van Assche
2026-02-23 21:50 ` [PATCH 04/62] dax/bus.c: Fix a locking bug Bart Van Assche
` (16 subsequent siblings)
19 siblings, 0 replies; 37+ messages in thread
From: Bart Van Assche @ 2026-02-23 21:50 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long, linux-kernel,
Marco Elver, Christoph Hellwig, Steven Rostedt, Nick Desaulniers,
Nathan Chancellor, Kees Cook, Jann Horn, Bart Van Assche,
Andreas Gruenbacher, linux-block
Make drbd_adm_dump_devices() call rcu_read_lock() before
rcu_read_unlock() is called. This has been detected by the Clang
thread-safety analyzer. Compile-tested only.
Cc: Andreas Gruenbacher <agruen@linbit.com>
Cc: linux-block@vger.kernel.org
Fixes: a55bbd375d18 ("drbd: Backport the "status" command")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
drivers/block/drbd/drbd_nl.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/block/drbd/drbd_nl.c b/drivers/block/drbd/drbd_nl.c
index e201f0087a0f..728ecc431b38 100644
--- a/drivers/block/drbd/drbd_nl.c
+++ b/drivers/block/drbd/drbd_nl.c
@@ -3378,8 +3378,10 @@ int drbd_adm_dump_devices(struct sk_buff *skb, struct netlink_callback *cb)
if (resource_filter) {
retcode = ERR_RES_NOT_KNOWN;
resource = drbd_find_resource(nla_data(resource_filter));
- if (!resource)
+ if (!resource) {
+ rcu_read_lock();
goto put_result;
+ }
cb->args[0] = (long)resource;
}
}
@@ -3628,8 +3630,10 @@ int drbd_adm_dump_peer_devices(struct sk_buff *skb, struct netlink_callback *cb)
if (resource_filter) {
retcode = ERR_RES_NOT_KNOWN;
resource = drbd_find_resource(nla_data(resource_filter));
- if (!resource)
+ if (!resource) {
+ rcu_read_lock();
goto put_result;
+ }
}
cb->args[0] = (long)resource;
}
^ permalink raw reply related [flat|nested] 37+ messages in thread* [PATCH 04/62] dax/bus.c: Fix a locking bug
2026-02-23 21:50 [PATCH 00/62] Bug fixes and refactoring patches related to locking Bart Van Assche
` (2 preceding siblings ...)
2026-02-23 21:50 ` [PATCH 03/62] drbd: Balance RCU calls in drbd_adm_dump_devices() Bart Van Assche
@ 2026-02-23 21:50 ` Bart Van Assche
2026-02-23 21:50 ` [PATCH 05/62] dma-buf: Convert dma_buf_import_sync_file() to the early-return style Bart Van Assche
` (15 subsequent siblings)
19 siblings, 0 replies; 37+ messages in thread
From: Bart Van Assche @ 2026-02-23 21:50 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long, linux-kernel,
Marco Elver, Christoph Hellwig, Steven Rostedt, Nick Desaulniers,
Nathan Chancellor, Kees Cook, Jann Horn, Bart Van Assche,
Dan Williams, Vishal Verma, Dave Jiang, Alison Schofield, nvdimm,
linux-cxl
Only unlock dax_dev_rwsem if it has been locked. This locking bug was
detected by the Clang thread-safety analyzer.
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Vishal Verma <vishal.l.verma@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: nvdimm@lists.linux.dev
Cc: linux-cxl@vger.kernel.org
Fixes: c05ae9d85b47 ("dax/bus.c: replace driver-core lock usage by a local rwsem")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
drivers/dax/bus.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
index c94c09622516..ebd3806c34e5 100644
--- a/drivers/dax/bus.c
+++ b/drivers/dax/bus.c
@@ -1117,11 +1117,10 @@ static ssize_t size_store(struct device *dev, struct device_attribute *attr,
}
rc = down_write_killable(&dax_dev_rwsem);
if (rc)
- goto err_dev;
+ goto err_region;
rc = dev_dax_resize(dax_region, dev_dax, val);
-err_dev:
up_write(&dax_dev_rwsem);
err_region:
up_write(&dax_region_rwsem);
^ permalink raw reply related [flat|nested] 37+ messages in thread* [PATCH 05/62] dma-buf: Convert dma_buf_import_sync_file() to the early-return style
2026-02-23 21:50 [PATCH 00/62] Bug fixes and refactoring patches related to locking Bart Van Assche
` (3 preceding siblings ...)
2026-02-23 21:50 ` [PATCH 04/62] dax/bus.c: Fix a locking bug Bart Van Assche
@ 2026-02-23 21:50 ` Bart Van Assche
2026-02-23 21:50 ` [PATCH 06/62] dma-buf: Handle all dma_resv_lock() errors Bart Van Assche
` (14 subsequent siblings)
19 siblings, 0 replies; 37+ messages in thread
From: Bart Van Assche @ 2026-02-23 21:50 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long, linux-kernel,
Marco Elver, Christoph Hellwig, Steven Rostedt, Nick Desaulniers,
Nathan Chancellor, Kees Cook, Jann Horn, Bart Van Assche,
Sumit Semwal, Christian König, linux-media
Before making changes in dma_buf_import_sync_file(), convert it to
the early-return coding style. No functionality has been changed.
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Christian König <christian.koenig@amd.com>
Cc: linux-media@vger.kernel.org
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
drivers/dma-buf/dma-buf.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 11711874a325..1666133ac8b8 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -523,11 +523,13 @@ static long dma_buf_import_sync_file(struct dma_buf *dmabuf,
dma_resv_lock(dmabuf->resv, NULL);
ret = dma_resv_reserve_fences(dmabuf->resv, num_fences);
- if (!ret) {
- dma_fence_unwrap_for_each(f, &iter, fence)
- dma_resv_add_fence(dmabuf->resv, f, usage);
- }
+ if (ret)
+ goto unlock;
+
+ dma_fence_unwrap_for_each(f, &iter, fence)
+ dma_resv_add_fence(dmabuf->resv, f, usage);
+unlock:
dma_resv_unlock(dmabuf->resv);
}
^ permalink raw reply related [flat|nested] 37+ messages in thread* [PATCH 06/62] dma-buf: Handle all dma_resv_lock() errors
2026-02-23 21:50 [PATCH 00/62] Bug fixes and refactoring patches related to locking Bart Van Assche
` (4 preceding siblings ...)
2026-02-23 21:50 ` [PATCH 05/62] dma-buf: Convert dma_buf_import_sync_file() to the early-return style Bart Van Assche
@ 2026-02-23 21:50 ` Bart Van Assche
2026-02-23 21:50 ` [PATCH 07/62] drm/amdgpu: Unlock a mutex before destroying it Bart Van Assche
` (13 subsequent siblings)
19 siblings, 0 replies; 37+ messages in thread
From: Bart Van Assche @ 2026-02-23 21:50 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long, linux-kernel,
Marco Elver, Christoph Hellwig, Steven Rostedt, Nick Desaulniers,
Nathan Chancellor, Kees Cook, Jann Horn, Bart Van Assche,
Sumit Semwal, Christian König, linux-media
Instead of assuming that dma_resv_lock() only returns 0 or -EDEADLK,
handle all possible dma_resv_lock() return values. This patch prepares
for enabling compile-time thread-safety analysis. This will cause the
compiler to check whether all dma_resv_lock() return values are handled.
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Christian König <christian.koenig@amd.com>
Cc: linux-media@vger.kernel.org
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
drivers/dma-buf/dma-resv.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index bea3e9858aca..b4710f730e9b 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -792,6 +792,8 @@ static int __init dma_resv_lockdep(void)
ret = dma_resv_lock(&obj, &ctx);
if (ret == -EDEADLK)
dma_resv_lock_slow(&obj, &ctx);
+ else if (ret)
+ goto fini;
fs_reclaim_acquire(GFP_KERNEL);
/* for unmap_mapping_range on trylocked buffer objects in shrinkers */
i_mmap_lock_write(&mapping);
@@ -805,12 +807,14 @@ static int __init dma_resv_lockdep(void)
#endif
fs_reclaim_release(GFP_KERNEL);
ww_mutex_unlock(&obj.lock);
+
+fini:
ww_acquire_fini(&ctx);
mmap_read_unlock(mm);
mmput(mm);
- return 0;
+ return ret;
}
subsys_initcall(dma_resv_lockdep);
#endif
^ permalink raw reply related [flat|nested] 37+ messages in thread* [PATCH 07/62] drm/amdgpu: Unlock a mutex before destroying it
2026-02-23 21:50 [PATCH 00/62] Bug fixes and refactoring patches related to locking Bart Van Assche
` (5 preceding siblings ...)
2026-02-23 21:50 ` [PATCH 06/62] dma-buf: Handle all dma_resv_lock() errors Bart Van Assche
@ 2026-02-23 21:50 ` Bart Van Assche
2026-02-24 8:26 ` Christian König
2026-02-23 21:50 ` [PATCH 08/62] drm/amdgpu: Fix locking bugs in error paths Bart Van Assche
` (12 subsequent siblings)
19 siblings, 1 reply; 37+ messages in thread
From: Bart Van Assche @ 2026-02-23 21:50 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long, linux-kernel,
Marco Elver, Christoph Hellwig, Steven Rostedt, Nick Desaulniers,
Nathan Chancellor, Kees Cook, Jann Horn, Bart Van Assche,
Alex Deucher, Christian König, Yang Wang, Hawking Zhang,
amd-gfx
Mutexes must be unlocked before these are destroyed. This has been detected
by the Clang thread-safety analyzer.
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Yang Wang <kevinyang.wang@amd.com>
Cc: Hawking Zhang <Hawking.Zhang@amd.com>
Cc: amd-gfx@lists.freedesktop.org
Fixes: f5e4cc8461c4 ("drm/amdgpu: implement RAS ACA driver framework")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_aca.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_aca.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_aca.c
index afe5ca81beec..db7858fe0c3d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_aca.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_aca.c
@@ -641,6 +641,7 @@ static void aca_error_fini(struct aca_error *aerr)
aca_bank_error_remove(aerr, bank_error);
out_unlock:
+ mutex_unlock(&aerr->lock);
mutex_destroy(&aerr->lock);
}
^ permalink raw reply related [flat|nested] 37+ messages in thread* Re: [PATCH 07/62] drm/amdgpu: Unlock a mutex before destroying it
2026-02-23 21:50 ` [PATCH 07/62] drm/amdgpu: Unlock a mutex before destroying it Bart Van Assche
@ 2026-02-24 8:26 ` Christian König
0 siblings, 0 replies; 37+ messages in thread
From: Christian König @ 2026-02-24 8:26 UTC (permalink / raw)
To: Bart Van Assche, Peter Zijlstra
Cc: Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long, linux-kernel,
Marco Elver, Christoph Hellwig, Steven Rostedt, Nick Desaulniers,
Nathan Chancellor, Kees Cook, Jann Horn, Alex Deucher, Yang Wang,
Hawking Zhang, amd-gfx
On 2/23/26 22:50, Bart Van Assche wrote:
> Mutexes must be unlocked before these are destroyed. This has been detected
> by the Clang thread-safety analyzer.
>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Christian König <christian.koenig@amd.com>
> Cc: Yang Wang <kevinyang.wang@amd.com>
> Cc: Hawking Zhang <Hawking.Zhang@amd.com>
> Cc: amd-gfx@lists.freedesktop.org
> Fixes: f5e4cc8461c4 ("drm/amdgpu: implement RAS ACA driver framework")
> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Looks reasonable to me, but I'm not very familiar with this code. So only:
Acked-by: Christian König <christian.koenig@amd.com>
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_aca.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_aca.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_aca.c
> index afe5ca81beec..db7858fe0c3d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_aca.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_aca.c
> @@ -641,6 +641,7 @@ static void aca_error_fini(struct aca_error *aerr)
> aca_bank_error_remove(aerr, bank_error);
>
> out_unlock:
> + mutex_unlock(&aerr->lock);
> mutex_destroy(&aerr->lock);
> }
>
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 08/62] drm/amdgpu: Fix locking bugs in error paths
2026-02-23 21:50 [PATCH 00/62] Bug fixes and refactoring patches related to locking Bart Van Assche
` (6 preceding siblings ...)
2026-02-23 21:50 ` [PATCH 07/62] drm/amdgpu: Unlock a mutex before destroying it Bart Van Assche
@ 2026-02-23 21:50 ` Bart Van Assche
2026-02-24 8:28 ` Christian König
2026-02-23 21:50 ` [PATCH 09/62] drm: bridge: cdns-mhdp8546: Fix a locking bug in an error path Bart Van Assche
` (11 subsequent siblings)
19 siblings, 1 reply; 37+ messages in thread
From: Bart Van Assche @ 2026-02-23 21:50 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long, linux-kernel,
Marco Elver, Christoph Hellwig, Steven Rostedt, Nick Desaulniers,
Nathan Chancellor, Kees Cook, Jann Horn, Bart Van Assche,
Alex Deucher, Christian König, YiPeng Chai, Hawking Zhang,
amd-gfx
Do not unlock psp->ras_context.mutex if it has not been locked. This has
been detected by the Clang thread-safety analyzer.
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: YiPeng Chai <YiPeng.Chai@amd.com>
Cc: Hawking Zhang <Hawking.Zhang@amd.com>
Cc: amd-gfx@lists.freedesktop.org
Fixes: b3fb79cda568 ("drm/amdgpu: add mutex to protect ras shared memory")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c
index 6e8aad91bcd3..0d3c18f04ac3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c
@@ -332,13 +332,13 @@ static ssize_t ta_if_invoke_debugfs_write(struct file *fp, const char *buf, size
if (!context || !context->initialized) {
dev_err(adev->dev, "TA is not initialized\n");
ret = -EINVAL;
- goto err_free_shared_buf;
+ goto free_shared_buf;
}
if (!psp->ta_funcs || !psp->ta_funcs->fn_ta_invoke) {
dev_err(adev->dev, "Unsupported function to invoke TA\n");
ret = -EOPNOTSUPP;
- goto err_free_shared_buf;
+ goto free_shared_buf;
}
context->session_id = ta_id;
@@ -346,7 +346,7 @@ static ssize_t ta_if_invoke_debugfs_write(struct file *fp, const char *buf, size
mutex_lock(&psp->ras_context.mutex);
ret = prep_ta_mem_context(&context->mem_context, shared_buf, shared_buf_len);
if (ret)
- goto err_free_shared_buf;
+ goto unlock;
ret = psp_fn_ta_invoke(psp, cmd_id);
if (ret || context->resp_status) {
@@ -354,15 +354,17 @@ static ssize_t ta_if_invoke_debugfs_write(struct file *fp, const char *buf, size
ret, context->resp_status);
if (!ret) {
ret = -EINVAL;
- goto err_free_shared_buf;
+ goto unlock;
}
}
if (copy_to_user((char *)&buf[copy_pos], context->mem_context.shared_buf, shared_buf_len))
ret = -EFAULT;
-err_free_shared_buf:
+unlock:
mutex_unlock(&psp->ras_context.mutex);
+
+free_shared_buf:
kfree(shared_buf);
return ret;
^ permalink raw reply related [flat|nested] 37+ messages in thread* Re: [PATCH 08/62] drm/amdgpu: Fix locking bugs in error paths
2026-02-23 21:50 ` [PATCH 08/62] drm/amdgpu: Fix locking bugs in error paths Bart Van Assche
@ 2026-02-24 8:28 ` Christian König
2026-02-24 14:32 ` Alex Deucher
0 siblings, 1 reply; 37+ messages in thread
From: Christian König @ 2026-02-24 8:28 UTC (permalink / raw)
To: Bart Van Assche, Peter Zijlstra
Cc: Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long, linux-kernel,
Marco Elver, Christoph Hellwig, Steven Rostedt, Nick Desaulniers,
Nathan Chancellor, Kees Cook, Jann Horn, Alex Deucher,
YiPeng Chai, Hawking Zhang, amd-gfx
On 2/23/26 22:50, Bart Van Assche wrote:
> Do not unlock psp->ras_context.mutex if it has not been locked. This has
> been detected by the Clang thread-safety analyzer.
>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Christian König <christian.koenig@amd.com>
> Cc: YiPeng Chai <YiPeng.Chai@amd.com>
> Cc: Hawking Zhang <Hawking.Zhang@amd.com>
> Cc: amd-gfx@lists.freedesktop.org
> Fixes: b3fb79cda568 ("drm/amdgpu: add mutex to protect ras shared memory")
> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Acked-by: Christian König <christian.koenig@amd.com>
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c
> index 6e8aad91bcd3..0d3c18f04ac3 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c
> @@ -332,13 +332,13 @@ static ssize_t ta_if_invoke_debugfs_write(struct file *fp, const char *buf, size
> if (!context || !context->initialized) {
> dev_err(adev->dev, "TA is not initialized\n");
> ret = -EINVAL;
> - goto err_free_shared_buf;
> + goto free_shared_buf;
> }
>
> if (!psp->ta_funcs || !psp->ta_funcs->fn_ta_invoke) {
> dev_err(adev->dev, "Unsupported function to invoke TA\n");
> ret = -EOPNOTSUPP;
> - goto err_free_shared_buf;
> + goto free_shared_buf;
> }
>
> context->session_id = ta_id;
> @@ -346,7 +346,7 @@ static ssize_t ta_if_invoke_debugfs_write(struct file *fp, const char *buf, size
> mutex_lock(&psp->ras_context.mutex);
> ret = prep_ta_mem_context(&context->mem_context, shared_buf, shared_buf_len);
> if (ret)
> - goto err_free_shared_buf;
> + goto unlock;
>
> ret = psp_fn_ta_invoke(psp, cmd_id);
> if (ret || context->resp_status) {
> @@ -354,15 +354,17 @@ static ssize_t ta_if_invoke_debugfs_write(struct file *fp, const char *buf, size
> ret, context->resp_status);
> if (!ret) {
> ret = -EINVAL;
> - goto err_free_shared_buf;
> + goto unlock;
> }
> }
>
> if (copy_to_user((char *)&buf[copy_pos], context->mem_context.shared_buf, shared_buf_len))
> ret = -EFAULT;
>
> -err_free_shared_buf:
> +unlock:
> mutex_unlock(&psp->ras_context.mutex);
> +
> +free_shared_buf:
> kfree(shared_buf);
>
> return ret;
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH 08/62] drm/amdgpu: Fix locking bugs in error paths
2026-02-24 8:28 ` Christian König
@ 2026-02-24 14:32 ` Alex Deucher
0 siblings, 0 replies; 37+ messages in thread
From: Alex Deucher @ 2026-02-24 14:32 UTC (permalink / raw)
To: Christian König
Cc: Bart Van Assche, Peter Zijlstra, Ingo Molnar, Will Deacon,
Boqun Feng, Waiman Long, linux-kernel, Marco Elver,
Christoph Hellwig, Steven Rostedt, Nick Desaulniers,
Nathan Chancellor, Kees Cook, Jann Horn, Alex Deucher,
YiPeng Chai, Hawking Zhang, amd-gfx
Applied. Thanks!
On Tue, Feb 24, 2026 at 3:54 AM Christian König
<christian.koenig@amd.com> wrote:
>
> On 2/23/26 22:50, Bart Van Assche wrote:
> > Do not unlock psp->ras_context.mutex if it has not been locked. This has
> > been detected by the Clang thread-safety analyzer.
> >
> > Cc: Alex Deucher <alexander.deucher@amd.com>
> > Cc: Christian König <christian.koenig@amd.com>
> > Cc: YiPeng Chai <YiPeng.Chai@amd.com>
> > Cc: Hawking Zhang <Hawking.Zhang@amd.com>
> > Cc: amd-gfx@lists.freedesktop.org
> > Fixes: b3fb79cda568 ("drm/amdgpu: add mutex to protect ras shared memory")
> > Signed-off-by: Bart Van Assche <bvanassche@acm.org>
>
> Acked-by: Christian König <christian.koenig@amd.com>
>
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c | 12 +++++++-----
> > 1 file changed, 7 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c
> > index 6e8aad91bcd3..0d3c18f04ac3 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c
> > @@ -332,13 +332,13 @@ static ssize_t ta_if_invoke_debugfs_write(struct file *fp, const char *buf, size
> > if (!context || !context->initialized) {
> > dev_err(adev->dev, "TA is not initialized\n");
> > ret = -EINVAL;
> > - goto err_free_shared_buf;
> > + goto free_shared_buf;
> > }
> >
> > if (!psp->ta_funcs || !psp->ta_funcs->fn_ta_invoke) {
> > dev_err(adev->dev, "Unsupported function to invoke TA\n");
> > ret = -EOPNOTSUPP;
> > - goto err_free_shared_buf;
> > + goto free_shared_buf;
> > }
> >
> > context->session_id = ta_id;
> > @@ -346,7 +346,7 @@ static ssize_t ta_if_invoke_debugfs_write(struct file *fp, const char *buf, size
> > mutex_lock(&psp->ras_context.mutex);
> > ret = prep_ta_mem_context(&context->mem_context, shared_buf, shared_buf_len);
> > if (ret)
> > - goto err_free_shared_buf;
> > + goto unlock;
> >
> > ret = psp_fn_ta_invoke(psp, cmd_id);
> > if (ret || context->resp_status) {
> > @@ -354,15 +354,17 @@ static ssize_t ta_if_invoke_debugfs_write(struct file *fp, const char *buf, size
> > ret, context->resp_status);
> > if (!ret) {
> > ret = -EINVAL;
> > - goto err_free_shared_buf;
> > + goto unlock;
> > }
> > }
> >
> > if (copy_to_user((char *)&buf[copy_pos], context->mem_context.shared_buf, shared_buf_len))
> > ret = -EFAULT;
> >
> > -err_free_shared_buf:
> > +unlock:
> > mutex_unlock(&psp->ras_context.mutex);
> > +
> > +free_shared_buf:
> > kfree(shared_buf);
> >
> > return ret;
>
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 09/62] drm: bridge: cdns-mhdp8546: Fix a locking bug in an error path
2026-02-23 21:50 [PATCH 00/62] Bug fixes and refactoring patches related to locking Bart Van Assche
` (7 preceding siblings ...)
2026-02-23 21:50 ` [PATCH 08/62] drm/amdgpu: Fix locking bugs in error paths Bart Van Assche
@ 2026-02-23 21:50 ` Bart Van Assche
2026-02-23 21:50 ` [PATCH 10/62] drm: Make drm_read() easier to analyze Bart Van Assche
` (10 subsequent siblings)
19 siblings, 0 replies; 37+ messages in thread
From: Bart Van Assche @ 2026-02-23 21:50 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long, linux-kernel,
Marco Elver, Christoph Hellwig, Steven Rostedt, Nick Desaulniers,
Nathan Chancellor, Kees Cook, Jann Horn, Bart Van Assche,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Swapnil Jakhade, Tomi Valkeinen
Do not unlock mhdp->mbox_mutex if it has not been locked.
This bug has been detected by the Clang thread-safety analyzer.
Cc: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: Neil Armstrong <neil.armstrong@linaro.org>
Cc: Robert Foss <rfoss@kernel.org>
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: Jonas Karlman <jonas@kwiboo.se>
Cc: Jernej Skrabec <jernej.skrabec@gmail.com>
Cc: Swapnil Jakhade <sjakhade@cadence.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Fixes: fb43aa0acdfd ("drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index 9392c226ff5b..ce4516de11d8 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -502,8 +502,7 @@ int cdns_mhdp_adjust_lt(struct cdns_mhdp_device *mhdp, unsigned int nlanes,
if (nlanes != 4 && nlanes != 2 && nlanes != 1) {
dev_err(mhdp->dev, "invalid number of lanes: %u\n", nlanes);
- ret = -EINVAL;
- goto out;
+ return -EINVAL;
}
payload[0] = nlanes;
^ permalink raw reply related [flat|nested] 37+ messages in thread* [PATCH 10/62] drm: Make drm_read() easier to analyze
2026-02-23 21:50 [PATCH 00/62] Bug fixes and refactoring patches related to locking Bart Van Assche
` (8 preceding siblings ...)
2026-02-23 21:50 ` [PATCH 09/62] drm: bridge: cdns-mhdp8546: Fix a locking bug in an error path Bart Van Assche
@ 2026-02-23 21:50 ` Bart Van Assche
2026-02-23 21:50 ` [PATCH 11/62] drm/pagemap: Unlock cache->lock before freeing it Bart Van Assche
` (9 subsequent siblings)
19 siblings, 0 replies; 37+ messages in thread
From: Bart Van Assche @ 2026-02-23 21:50 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long, linux-kernel,
Marco Elver, Christoph Hellwig, Steven Rostedt, Nick Desaulniers,
Nathan Chancellor, Kees Cook, Jann Horn, Bart Van Assche,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann
Prepare for enabling the Clang thread-safety analyzer by duplicating a
return statement. No functionality has been changed.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
drivers/gpu/drm/drm_file.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index ec820686b302..200979d78452 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -572,8 +572,9 @@ ssize_t drm_read(struct file *filp, char __user *buffer,
mutex_unlock(&file_priv->event_read_lock);
ret = wait_event_interruptible(file_priv->event_wait,
!list_empty(&file_priv->event_list));
- if (ret >= 0)
- ret = mutex_lock_interruptible(&file_priv->event_read_lock);
+ if (ret < 0)
+ return ret;
+ ret = mutex_lock_interruptible(&file_priv->event_read_lock);
if (ret)
return ret;
} else {
^ permalink raw reply related [flat|nested] 37+ messages in thread* [PATCH 11/62] drm/pagemap: Unlock cache->lock before freeing it
2026-02-23 21:50 [PATCH 00/62] Bug fixes and refactoring patches related to locking Bart Van Assche
` (9 preceding siblings ...)
2026-02-23 21:50 ` [PATCH 10/62] drm: Make drm_read() easier to analyze Bart Van Assche
@ 2026-02-23 21:50 ` Bart Van Assche
2026-02-23 21:50 ` [PATCH 12/62] drm/gpusvm.c: Fix a locking bug in an error path Bart Van Assche
` (8 subsequent siblings)
19 siblings, 0 replies; 37+ messages in thread
From: Bart Van Assche @ 2026-02-23 21:50 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long, linux-kernel,
Marco Elver, Christoph Hellwig, Steven Rostedt, Nick Desaulniers,
Nathan Chancellor, Kees Cook, Jann Horn, Bart Van Assche,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Thomas Hellström, Matthew Brost
Although freeing a spinlock without unlocking it is fine, this confuses
static analyzers. Hence this patch.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
drivers/gpu/drm/drm_pagemap_util.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_pagemap_util.c b/drivers/gpu/drm/drm_pagemap_util.c
index 14ddb948a32e..50cb5f9cdac5 100644
--- a/drivers/gpu/drm/drm_pagemap_util.c
+++ b/drivers/gpu/drm/drm_pagemap_util.c
@@ -74,6 +74,8 @@ static void drm_pagemap_cache_fini(void *arg)
cache->dpagemap = NULL;
spin_unlock(&cache->lock);
drm_pagemap_destroy(dpagemap, false);
+ } else {
+ spin_unlock(&cache->lock);
}
out:
^ permalink raw reply related [flat|nested] 37+ messages in thread* [PATCH 12/62] drm/gpusvm.c: Fix a locking bug in an error path
2026-02-23 21:50 [PATCH 00/62] Bug fixes and refactoring patches related to locking Bart Van Assche
` (10 preceding siblings ...)
2026-02-23 21:50 ` [PATCH 11/62] drm/pagemap: Unlock cache->lock before freeing it Bart Van Assche
@ 2026-02-23 21:50 ` Bart Van Assche
2026-02-23 21:50 ` [PATCH 13/62] drm/qxl: Fix a buffer leak " Bart Van Assche
` (7 subsequent siblings)
19 siblings, 0 replies; 37+ messages in thread
From: Bart Van Assche @ 2026-02-23 21:50 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long, linux-kernel,
Marco Elver, Christoph Hellwig, Steven Rostedt, Nick Desaulniers,
Nathan Chancellor, Kees Cook, Jann Horn, Bart Van Assche,
Thomas Hellström, Matthew Brost, Himal Prasad Ghimiray,
Maarten Lankhorst
Only call drm_gpusvm_notifier_unlock() if drm_gpusvm_notifier_lock() was
called first. This has been detected by the Clang thread-safety
analyzer. Compile-tested only.
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: f1d08a586482 ("drm/gpusvm: Introduce a function to scan the current migration state")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
drivers/gpu/drm/drm_gpusvm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_gpusvm.c b/drivers/gpu/drm/drm_gpusvm.c
index 24180bfdf5a2..e9b79ab2f83c 100644
--- a/drivers/gpu/drm/drm_gpusvm.c
+++ b/drivers/gpu/drm/drm_gpusvm.c
@@ -819,7 +819,7 @@ enum drm_gpusvm_scan_result drm_gpusvm_scan_mm(struct drm_gpusvm_range *range,
if (!(pfns[i] & HMM_PFN_VALID)) {
state = DRM_GPUSVM_SCAN_UNPOPULATED;
- goto err_free;
+ goto unlock;
}
page = hmm_pfn_to_page(pfns[i]);
@@ -856,9 +856,10 @@ enum drm_gpusvm_scan_result drm_gpusvm_scan_mm(struct drm_gpusvm_range *range,
i += 1ul << drm_gpusvm_hmm_pfn_to_order(pfns[i], i, npages);
}
-err_free:
+unlock:
drm_gpusvm_notifier_unlock(range->gpusvm);
+err_free:
kvfree(pfns);
return state;
}
^ permalink raw reply related [flat|nested] 37+ messages in thread* [PATCH 13/62] drm/qxl: Fix a buffer leak in an error path
2026-02-23 21:50 [PATCH 00/62] Bug fixes and refactoring patches related to locking Bart Van Assche
` (11 preceding siblings ...)
2026-02-23 21:50 ` [PATCH 12/62] drm/gpusvm.c: Fix a locking bug in an error path Bart Van Assche
@ 2026-02-23 21:50 ` Bart Van Assche
2026-02-23 21:50 ` [PATCH 14/62] hwmon: (it87) Check the it87_lock() return value Bart Van Assche
` (6 subsequent siblings)
19 siblings, 0 replies; 37+ messages in thread
From: Bart Van Assche @ 2026-02-23 21:50 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long, linux-kernel,
Marco Elver, Christoph Hellwig, Steven Rostedt, Nick Desaulniers,
Nathan Chancellor, Kees Cook, Jann Horn, Bart Van Assche,
Dave Airlie, Gerd Hoffmann, virtualization
If qxl_bo_reserve() succeeds, call qxl_bo_unreserve() instead of
skipping that call.
This has been detected by the Clang thread-safety analyzer.
Compile-tested only.
Cc: Dave Airlie <airlied@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: virtualization@lists.linux.dev
Fixes: f64122c1f6ad ("drm: add new QXL driver. (v1.4)")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
drivers/gpu/drm/qxl/qxl_ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/qxl/qxl_ioctl.c b/drivers/gpu/drm/qxl/qxl_ioctl.c
index 4ee2b5acf2e0..5617811f3c9b 100644
--- a/drivers/gpu/drm/qxl/qxl_ioctl.c
+++ b/drivers/gpu/drm/qxl/qxl_ioctl.c
@@ -323,7 +323,7 @@ int qxl_update_area_ioctl(struct drm_device *dev, void *data, struct drm_file *f
qxl_ttm_placement_from_domain(qobj, qobj->type);
ret = ttm_bo_validate(&qobj->tbo, &qobj->placement, &ctx);
if (unlikely(ret))
- goto out;
+ goto out2;
}
ret = qxl_bo_check_id(qdev, qobj);
^ permalink raw reply related [flat|nested] 37+ messages in thread* [PATCH 14/62] hwmon: (it87) Check the it87_lock() return value
2026-02-23 21:50 [PATCH 00/62] Bug fixes and refactoring patches related to locking Bart Van Assche
` (12 preceding siblings ...)
2026-02-23 21:50 ` [PATCH 13/62] drm/qxl: Fix a buffer leak " Bart Van Assche
@ 2026-02-23 21:50 ` Bart Van Assche
2026-02-23 21:50 ` [PATCH 15/62] Input: synaptics-rmi4 - fix a locking bug in an error path Bart Van Assche
` (5 subsequent siblings)
19 siblings, 0 replies; 37+ messages in thread
From: Bart Van Assche @ 2026-02-23 21:50 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long, linux-kernel,
Marco Elver, Christoph Hellwig, Steven Rostedt, Nick Desaulniers,
Nathan Chancellor, Kees Cook, Jann Horn, Bart Van Assche,
Frank Crawford, Guenter Roeck, Jean Delvare, linux-hwmon
Return early in it87_resume() if it87_lock() fails instead of ignoring the
return value of that function. This patch suppresses a Clang thread-safety
warning.
Cc: Frank Crawford <frank@crawford.emu.id.au>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Jean Delvare <jdelvare@suse.com>
Cc: linux-hwmon@vger.kernel.org
Fixes: 376e1a937b30 ("hwmon: (it87) Add calls to smbus_enable/smbus_disable as required")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
drivers/hwmon/it87.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/hwmon/it87.c b/drivers/hwmon/it87.c
index e233aafa8856..8e3935089fca 100644
--- a/drivers/hwmon/it87.c
+++ b/drivers/hwmon/it87.c
@@ -3593,7 +3593,9 @@ static int it87_resume(struct device *dev)
it87_resume_sio(pdev);
- it87_lock(data);
+ int err = it87_lock(data);
+ if (err)
+ return err;
it87_check_pwm(dev);
it87_check_limit_regs(data);
^ permalink raw reply related [flat|nested] 37+ messages in thread* [PATCH 15/62] Input: synaptics-rmi4 - fix a locking bug in an error path
2026-02-23 21:50 [PATCH 00/62] Bug fixes and refactoring patches related to locking Bart Van Assche
` (13 preceding siblings ...)
2026-02-23 21:50 ` [PATCH 14/62] hwmon: (it87) Check the it87_lock() return value Bart Van Assche
@ 2026-02-23 21:50 ` Bart Van Assche
2026-02-23 21:58 ` Dmitry Torokhov
2026-02-23 21:50 ` [PATCH 16/62] md: Make mddev_suspend() easier to analyze Bart Van Assche
` (4 subsequent siblings)
19 siblings, 1 reply; 37+ messages in thread
From: Bart Van Assche @ 2026-02-23 21:50 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long, linux-kernel,
Marco Elver, Christoph Hellwig, Steven Rostedt, Nick Desaulniers,
Nathan Chancellor, Kees Cook, Jann Horn, Bart Van Assche,
Dmitry Torokhov, Nick Dyer, linux-input
Lock f54->data_mutex before the first 'goto error' statement since
jumping to the 'error' label causes that mutex to be unlocked.
This bug has been detected by the Clang thread-safety checker.
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Nick Dyer <nick@shmanahar.org>
Cc: linux-input@vger.kernel.org
Fixes: 3a762dbd5347 ("[media] Input: synaptics-rmi4 - add support for F54 diagnostics")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
drivers/input/rmi4/rmi_f54.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/input/rmi4/rmi_f54.c b/drivers/input/rmi4/rmi_f54.c
index ac4041a69fcd..fd57ebb1cb50 100644
--- a/drivers/input/rmi4/rmi_f54.c
+++ b/drivers/input/rmi4/rmi_f54.c
@@ -539,6 +539,9 @@ static void rmi_f54_work(struct work_struct *work)
int i;
report_size = rmi_f54_get_report_size(f54);
+
+ mutex_lock(&f54->data_mutex);
+
if (report_size == 0) {
dev_err(&fn->dev, "Bad report size, report type=%d\n",
f54->report_type);
@@ -546,8 +549,6 @@ static void rmi_f54_work(struct work_struct *work)
goto error; /* retry won't help */
}
- mutex_lock(&f54->data_mutex);
-
/*
* Need to check if command has completed.
* If not try again later.
^ permalink raw reply related [flat|nested] 37+ messages in thread* Re: [PATCH 15/62] Input: synaptics-rmi4 - fix a locking bug in an error path
2026-02-23 21:50 ` [PATCH 15/62] Input: synaptics-rmi4 - fix a locking bug in an error path Bart Van Assche
@ 2026-02-23 21:58 ` Dmitry Torokhov
2026-02-23 22:05 ` Bart Van Assche
0 siblings, 1 reply; 37+ messages in thread
From: Dmitry Torokhov @ 2026-02-23 21:58 UTC (permalink / raw)
To: Bart Van Assche
Cc: Peter Zijlstra, Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long,
linux-kernel, Marco Elver, Christoph Hellwig, Steven Rostedt,
Nick Desaulniers, Nathan Chancellor, Kees Cook, Jann Horn,
Nick Dyer, linux-input
Hi Bart,
On Mon, Feb 23, 2026 at 01:50:30PM -0800, Bart Van Assche wrote:
> Lock f54->data_mutex before the first 'goto error' statement since
> jumping to the 'error' label causes that mutex to be unlocked.
>
> This bug has been detected by the Clang thread-safety checker.
>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Cc: Nick Dyer <nick@shmanahar.org>
> Cc: linux-input@vger.kernel.org
> Fixes: 3a762dbd5347 ("[media] Input: synaptics-rmi4 - add support for F54 diagnostics")
> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
> ---
> drivers/input/rmi4/rmi_f54.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/rmi4/rmi_f54.c b/drivers/input/rmi4/rmi_f54.c
> index ac4041a69fcd..fd57ebb1cb50 100644
> --- a/drivers/input/rmi4/rmi_f54.c
> +++ b/drivers/input/rmi4/rmi_f54.c
> @@ -539,6 +539,9 @@ static void rmi_f54_work(struct work_struct *work)
> int i;
>
> report_size = rmi_f54_get_report_size(f54);
> +
> + mutex_lock(&f54->data_mutex);
> +
Thank you for the patch. Do you mind if I move mutex_lock() above the
call to rmi_f54_get_report_size()? It does not extend critical section
by much, and I think logically makes more sense.
> if (report_size == 0) {
> dev_err(&fn->dev, "Bad report size, report type=%d\n",
> f54->report_type);
> @@ -546,8 +549,6 @@ static void rmi_f54_work(struct work_struct *work)
> goto error; /* retry won't help */
> }
>
> - mutex_lock(&f54->data_mutex);
> -
> /*
> * Need to check if command has completed.
> * If not try again later.
Thanks.
--
Dmitry
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH 15/62] Input: synaptics-rmi4 - fix a locking bug in an error path
2026-02-23 21:58 ` Dmitry Torokhov
@ 2026-02-23 22:05 ` Bart Van Assche
0 siblings, 0 replies; 37+ messages in thread
From: Bart Van Assche @ 2026-02-23 22:05 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Peter Zijlstra, Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long,
linux-kernel, Marco Elver, Christoph Hellwig, Steven Rostedt,
Nick Desaulniers, Nathan Chancellor, Kees Cook, Jann Horn,
Nick Dyer, linux-input
On 2/23/26 1:58 PM, Dmitry Torokhov wrote:
> Hi Bart,
>
> On Mon, Feb 23, 2026 at 01:50:30PM -0800, Bart Van Assche wrote:
>> Lock f54->data_mutex before the first 'goto error' statement since
>> jumping to the 'error' label causes that mutex to be unlocked.
>>
>> This bug has been detected by the Clang thread-safety checker.
>>
>> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>> Cc: Nick Dyer <nick@shmanahar.org>
>> Cc: linux-input@vger.kernel.org
>> Fixes: 3a762dbd5347 ("[media] Input: synaptics-rmi4 - add support for F54 diagnostics")
>> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
>> ---
>> drivers/input/rmi4/rmi_f54.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/input/rmi4/rmi_f54.c b/drivers/input/rmi4/rmi_f54.c
>> index ac4041a69fcd..fd57ebb1cb50 100644
>> --- a/drivers/input/rmi4/rmi_f54.c
>> +++ b/drivers/input/rmi4/rmi_f54.c
>> @@ -539,6 +539,9 @@ static void rmi_f54_work(struct work_struct *work)
>> int i;
>>
>> report_size = rmi_f54_get_report_size(f54);
>> +
>> + mutex_lock(&f54->data_mutex);
>> +
>
> Thank you for the patch. Do you mind if I move mutex_lock() above the
> call to rmi_f54_get_report_size()? It does not extend critical section
> by much, and I think logically makes more sense.
That sounds good to me. Please keep in mind that I'm not familiar with
the rmi4 driver.
Thanks,
Bart.
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 16/62] md: Make mddev_suspend() easier to analyze
2026-02-23 21:50 [PATCH 00/62] Bug fixes and refactoring patches related to locking Bart Van Assche
` (14 preceding siblings ...)
2026-02-23 21:50 ` [PATCH 15/62] Input: synaptics-rmi4 - fix a locking bug in an error path Bart Van Assche
@ 2026-02-23 21:50 ` Bart Van Assche
2026-02-23 21:50 ` [PATCH 17/62] bnxt_en: Make bnxt_resume() " Bart Van Assche
` (3 subsequent siblings)
19 siblings, 0 replies; 37+ messages in thread
From: Bart Van Assche @ 2026-02-23 21:50 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long, linux-kernel,
Marco Elver, Christoph Hellwig, Steven Rostedt, Nick Desaulniers,
Nathan Chancellor, Kees Cook, Jann Horn, Bart Van Assche,
Song Liu, Yu Kuai, linux-raid
Prepare for enabling Clang's thread-safety analysis by moving an
if-statement. No functionality has been changed.
Cc: Song Liu <song@kernel.org>
Cc: Yu Kuai <yukuai@fnnas.com>
Cc: linux-raid@vger.kernel.org
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
drivers/md/md.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 3ce6f9e9d38e..b0d260d03a7d 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -475,12 +475,13 @@ int mddev_suspend(struct mddev *mddev, bool interruptible)
*/
lockdep_assert_not_held(&mddev->reconfig_mutex);
- if (interruptible)
+ if (interruptible) {
err = mutex_lock_interruptible(&mddev->suspend_mutex);
- else
+ if (err)
+ return err;
+ } else {
mutex_lock(&mddev->suspend_mutex);
- if (err)
- return err;
+ }
if (mddev->suspended) {
WRITE_ONCE(mddev->suspended, mddev->suspended + 1);
^ permalink raw reply related [flat|nested] 37+ messages in thread* [PATCH 17/62] bnxt_en: Make bnxt_resume() easier to analyze
2026-02-23 21:50 [PATCH 00/62] Bug fixes and refactoring patches related to locking Bart Van Assche
` (15 preceding siblings ...)
2026-02-23 21:50 ` [PATCH 16/62] md: Make mddev_suspend() easier to analyze Bart Van Assche
@ 2026-02-23 21:50 ` Bart Van Assche
2026-02-23 21:50 ` [PATCH 18/62] bnxt_en: Fix bnxt_dl_reload_up() Bart Van Assche
` (2 subsequent siblings)
19 siblings, 0 replies; 37+ messages in thread
From: Bart Van Assche @ 2026-02-23 21:50 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long, linux-kernel,
Marco Elver, Christoph Hellwig, Steven Rostedt, Nick Desaulniers,
Nathan Chancellor, Kees Cook, Jann Horn, Bart Van Assche,
Shantiprasad Shettar, netdev
Pass the same argument to netdev_lock() and netdev_unlock(). This patch
prepares for enabling the Clang thread-safety analysis functionality. No
functional change intended.
Cc: Shantiprasad Shettar <shantiprasad.shettar@broadcom.com>
Cc: netdev@vger.kernel.org
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index e062d5d400da..950708575268 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -17121,7 +17121,7 @@ static int bnxt_resume(struct device *device)
}
resume_exit:
- netdev_unlock(bp->dev);
+ netdev_unlock(dev);
bnxt_ulp_start(bp, rc);
if (!rc)
bnxt_reenable_sriov(bp);
^ permalink raw reply related [flat|nested] 37+ messages in thread* [PATCH 18/62] bnxt_en: Fix bnxt_dl_reload_up()
2026-02-23 21:50 [PATCH 00/62] Bug fixes and refactoring patches related to locking Bart Van Assche
` (16 preceding siblings ...)
2026-02-23 21:50 ` [PATCH 17/62] bnxt_en: Make bnxt_resume() " Bart Van Assche
@ 2026-02-23 21:50 ` Bart Van Assche
2026-02-23 21:50 ` [PATCH 19/62] ice: Fix a locking bug in an error path Bart Van Assche
2026-02-23 22:01 ` [PATCH 00/62] Bug fixes and refactoring patches related to locking Peter Zijlstra
19 siblings, 0 replies; 37+ messages in thread
From: Bart Van Assche @ 2026-02-23 21:50 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long, linux-kernel,
Marco Elver, Christoph Hellwig, Steven Rostedt, Nick Desaulniers,
Nathan Chancellor, Kees Cook, Jann Horn, Bart Van Assche,
Jakub Kicinski, Shantiprasad Shettar, Stanislav Fomichev, netdev
bnxt_dl_reload_down() calls rtnl_lock() and netdev_lock() if it returns
0. Hence, bnxt_dl_reload_up() should invoke the corresponding unlock
calls. This issue has been detected by the clang thread-sanitizer.
Compile-tested only.
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Shantiprasad Shettar <shantiprasad.shettar@broadcom.com>
Cc: Stanislav Fomichev <sdf@fomichev.me>
Cc: netdev@vger.kernel.org
Fixes: 004b5008016a ("eth: bnxt: remove most dependencies on RTNL")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
index 15de802bbac4..1e9a3454bb29 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
@@ -562,6 +562,8 @@ static int bnxt_dl_reload_up(struct devlink *dl, enum devlink_reload_action acti
break;
}
default:
+ netdev_unlock(bp->dev);
+ rtnl_unlock();
return -EOPNOTSUPP;
}
^ permalink raw reply related [flat|nested] 37+ messages in thread* [PATCH 19/62] ice: Fix a locking bug in an error path
2026-02-23 21:50 [PATCH 00/62] Bug fixes and refactoring patches related to locking Bart Van Assche
` (17 preceding siblings ...)
2026-02-23 21:50 ` [PATCH 18/62] bnxt_en: Fix bnxt_dl_reload_up() Bart Van Assche
@ 2026-02-23 21:50 ` Bart Van Assche
2026-02-23 22:01 ` [PATCH 00/62] Bug fixes and refactoring patches related to locking Peter Zijlstra
19 siblings, 0 replies; 37+ messages in thread
From: Bart Van Assche @ 2026-02-23 21:50 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long, linux-kernel,
Marco Elver, Christoph Hellwig, Steven Rostedt, Nick Desaulniers,
Nathan Chancellor, Kees Cook, Jann Horn, Bart Van Assche,
Tony Nguyen, Przemek Kitszel, intel-wired-lan
Move the mutex_lock() call up to prevent that DCB settings change after
the ice_query_port_ets() call.
This patch fixes a bug in an error path. Without this patch pf->tc_mutex
may be unlocked in an error path without having been locked. This bug has
been detected by the clang thread-safety analyzer.
Cc: Tony Nguyen <anthony.l.nguyen@intel.com>
Cc: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Cc: intel-wired-lan@lists.osuosl.org
Fixes: 242b5e068b25 ("ice: Fix DCB rebuild after reset")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
drivers/net/ethernet/intel/ice/ice_dcb_lib.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_dcb_lib.c b/drivers/net/ethernet/intel/ice/ice_dcb_lib.c
index bd77f1c001ee..78ded6876581 100644
--- a/drivers/net/ethernet/intel/ice/ice_dcb_lib.c
+++ b/drivers/net/ethernet/intel/ice/ice_dcb_lib.c
@@ -537,14 +537,14 @@ void ice_dcb_rebuild(struct ice_pf *pf)
struct ice_dcbx_cfg *err_cfg;
int ret;
+ mutex_lock(&pf->tc_mutex);
+
ret = ice_query_port_ets(pf->hw.port_info, &buf, sizeof(buf), NULL);
if (ret) {
dev_err(dev, "Query Port ETS failed\n");
goto dcb_error;
}
- mutex_lock(&pf->tc_mutex);
-
if (!pf->hw.port_info->qos_cfg.is_sw_lldp)
ice_cfg_etsrec_defaults(pf->hw.port_info);
^ permalink raw reply related [flat|nested] 37+ messages in thread* Re: [PATCH 00/62] Bug fixes and refactoring patches related to locking
2026-02-23 21:50 [PATCH 00/62] Bug fixes and refactoring patches related to locking Bart Van Assche
` (18 preceding siblings ...)
2026-02-23 21:50 ` [PATCH 19/62] ice: Fix a locking bug in an error path Bart Van Assche
@ 2026-02-23 22:01 ` Peter Zijlstra
2026-02-23 22:13 ` Bart Van Assche
19 siblings, 1 reply; 37+ messages in thread
From: Peter Zijlstra @ 2026-02-23 22:01 UTC (permalink / raw)
To: Bart Van Assche
Cc: Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long, linux-kernel,
Marco Elver, Christoph Hellwig, Steven Rostedt, Nick Desaulniers,
Nathan Chancellor, Kees Cook, Jann Horn
On Mon, Feb 23, 2026 at 01:50:15PM -0800, Bart Van Assche wrote:
> Hi Peter,
>
> Annotating all source files in the kernel tree with lock context annotations
> led to the discovery of a significant number of locking bugs. This patch
> series includes fixes for the discovered bugs. Additionally, multiple
> refactoring patches have been included that make it easier for the compiler
> to verify correctness of locking operations. Please consider this patch series
> for the next merge window.
Should we not rather have the various maintainers take the bits relevant
to them? This seems all rather orthogonal at this point.
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH 00/62] Bug fixes and refactoring patches related to locking
2026-02-23 22:01 ` [PATCH 00/62] Bug fixes and refactoring patches related to locking Peter Zijlstra
@ 2026-02-23 22:13 ` Bart Van Assche
0 siblings, 0 replies; 37+ messages in thread
From: Bart Van Assche @ 2026-02-23 22:13 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long, linux-kernel,
Marco Elver, Christoph Hellwig, Steven Rostedt, Nick Desaulniers,
Nathan Chancellor, Kees Cook, Jann Horn
On 2/23/26 2:01 PM, Peter Zijlstra wrote:
> On Mon, Feb 23, 2026 at 01:50:15PM -0800, Bart Van Assche wrote:
>> Hi Peter,
>>
>> Annotating all source files in the kernel tree with lock context annotations
>> led to the discovery of a significant number of locking bugs. This patch
>> series includes fixes for the discovered bugs. Additionally, multiple
>> refactoring patches have been included that make it easier for the compiler
>> to verify correctness of locking operations. Please consider this patch series
>> for the next merge window.
>
> Should we not rather have the various maintainers take the bits relevant
> to them? This seems all rather orthogonal at this point.
Hi Peter,
Agreed that this patch series can be split into multiple orthogonal
smaller series. However, splitting this series into multiple series,
looking up to which maintainer to send each series and keeping track of
the feedback on each series will significantly increase my workload.
BTW, none of the SMTP servers I tried so far allowed me to post the
entire patch series at once.
Thanks,
Bart.
^ permalink raw reply [flat|nested] 37+ messages in thread