Re: [PATCH] x86/virt/tdx: Fix lockdep assertion failure in cache flush for kexec

[Sean Christopherson <seanjc@google.com>]

On Tue, Mar 10, 2026, Kai Huang wrote:
> On Mon, 2026-03-09 at 16:38 +0000, Edgecombe, Rick P wrote:
> > On Mon, 2026-03-02 at 23:22 +1300, Kai Huang wrote:
> > > Remove the too strong lockdep_assert_preemption_disabled(), and
> > > change this_cpu_{read|write}() to __this_cpu_{read|write}() which
> > > provide the more proper check (when CONFIG_DEBUG_PREEMPT is true),
> > > which checks all conditions that the context cannot be moved to
> > > another CPU to run in the middle.
> > > 
> > > Fixes: 61221d07e815 ("KVM/TDX: Explicitly do WBINVD when no more TDX
> > > SEAMCALLs")
> > > Cc: stable@vger.kernel.org
> > > Reported-by: Vishal Verma <vishal.l.verma@intel.com>
> > > Signed-off-by: Kai Huang <kai.huang@intel.com>
> > > Tested-by: Vishal Verma <vishal.l.verma@intel.com>
> > 
> > Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
> > 
> > But this issue is also solved by:
> > https://lore.kernel.org/kvm/20260307010358.819645-3-rick.p.edgecombe@intel.com/

Even when that series comes along, I would rather have __this_cpu_{read|write}()
instead of the explicit lockdep_assert_preemption_disabled().  Similar to the WARN
about IRQs being disabled that got removed, explicitly requiring that preemption
be disabled feels like a description of the current code, not an actual requirement.

Asserting that preemption is disabled gives the false impression that the current
task must not be scheduled out, between reading and writing cache_state_incoherent.
Which then raises the question of why scheduling out the current task is bad".

> This depends on Sean's series to move VMXON to x86 core, so it's not stable
> friendly.
> 
> > 
> > I guess that these changes are correct in either case. There is no need
> > for the stricter asserts. But depending on the order the log would be
> > confusing in the history when it talks about lockdep warnings. So we'll
> > have to keep an eye on things. If this goes first, then it's fine.
> 
> I see.  Will keep this in mind.
> 
> > 
> > You know, it might have helped to include the splat if you end up with
> > a v2.

+1.  I can read a backtrace about 10x faster than a full sentence describing the
backtrace.