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

["Huang, Kai" <kai.huang@intel.com>]

On Tue, 2026-03-10 at 06:50 -0700, Sean Christopherson wrote:
> 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".

Agreed.

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

I'll include the actual WARN splat in v2.

Thanks for the ack!