From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from 011.lax.mailroute.net (011.lax.mailroute.net [199.89.1.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6906D2F617C; Tue, 24 Feb 2026 19:26:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=199.89.1.14 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771961168; cv=none; b=TgpfjQwCwWcnT0i1O61s0LcTbMJyTQQoJqBCwsSZz6D2mh4IaU3aecZ2TPWLUeatzhnWDens8Aq+chru32KQXgycLGWSOB4/AeY0dBOky8bdjLj/UUPAl/Tjaqsf730857jTUOPZWI7AHm1yKO6ZExVi0fSO93CaSZ/XqVi5xGw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771961168; c=relaxed/simple; bh=m23sxk2fsrDn0ix0e/ZaHu0BCuHJX82d/xQJo5X520k=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=FaTgUQO7rds5OEa+3mL9s8/h6KdI4mQGj4Cj4XV2LdAD86IkohxXY0Ds3UkhHjuA1PJ/XMY+8iBaYL6Fz+K0zyuD0BkaX2lF9AxcH+aCu3uXPMZzuPPpAzNkJ05N+m+bt0b+W5LFNbuwfelLwAsDOQWUN1tPkH+mWXkiUJNNeDw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=acm.org; spf=pass smtp.mailfrom=acm.org; dkim=pass (2048-bit key) header.d=acm.org header.i=@acm.org header.b=Ge3kA35s; arc=none smtp.client-ip=199.89.1.14 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=acm.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=acm.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=acm.org header.i=@acm.org header.b="Ge3kA35s" Received: from localhost (localhost [127.0.0.1]) by 011.lax.mailroute.net (Postfix) with ESMTP id 4fL74G4bGYz1XM6JH; Tue, 24 Feb 2026 19:26:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=acm.org; h= content-transfer-encoding:content-type:content-type:in-reply-to :from:from:content-language:references:subject:subject :user-agent:mime-version:date:date:message-id:received:received; s=mr01; t=1771961163; x=1774553164; bh=YUwsQGY2aFfZKK7Wlzh+EJtf iWdyE9X0mtY4U0hZqxM=; b=Ge3kA35sBhCoJF8c3Ti1glvz8fLxq82vKp/Kwnwb +iTUsyjRNVXuQ7SFVkqBPKfkCCAwkR6gm7dU77rxAs78UKc4sFO6oa1JP/5tbOAK AdTUZhh3kGegZDXLJE9z5HsonLgH9kQME2EChYeK9WpyZipCfLLgSmoc35HVdKuY mgo5qiMeG61wGt8ty4lSq2/1mUZWqoqVWvjy9OBCHz9FOnjQKZUlZtYWAdLJ23lu qJD9VLoA0r7HYl5XIellHSPrUtYCStYskIvtGRyfi8YBJZftVFMv68yQQlR22Um1 ymblRp5e8wWR8qNO8bixPnrN1iaxlks6949ViZ5AMl3HWw== X-Virus-Scanned: by MailRoute Received: from 011.lax.mailroute.net ([127.0.0.1]) by localhost (011.lax [127.0.0.1]) (mroute_mailscanner, port 10029) with LMTP id J7sLZpho_xoS; Tue, 24 Feb 2026 19:26:03 +0000 (UTC) Received: from [172.20.2.156] (unknown [4.28.11.157]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bvanassche@acm.org) by 011.lax.mailroute.net (Postfix) with ESMTPSA id 4fL7464Psrz1XM6J6; Tue, 24 Feb 2026 19:25:58 +0000 (UTC) Message-ID: <7a22294b-1150-4c55-a95a-ea918cfb9b76@acm.org> Date: Tue, 24 Feb 2026 11:25:56 -0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 01/62] kvm: Make pi_enable_wakeup_handler() easier to analyze To: Sean Christopherson Cc: Peter Zijlstra , Ingo Molnar , Will Deacon , Boqun Feng , Waiman Long , linux-kernel@vger.kernel.org, Marco Elver , Christoph Hellwig , Steven Rostedt , Nick Desaulniers , Nathan Chancellor , Kees Cook , Jann Horn , Paolo Bonzini , kvm@vger.kernel.org References: <20260223215118.2154194-1-bvanassche@acm.org> <20260223215118.2154194-2-bvanassche@acm.org> Content-Language: en-US From: Bart Van Assche In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 >> Cc: Paolo Bonzini >> Cc: kvm@vger.kernel.org >> Signed-off-by: Bart Van Assche >> --- >> 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.