From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f202.google.com (mail-pf1-f202.google.com [209.85.210.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7F6A1385528 for ; Tue, 10 Mar 2026 13:50:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773150627; cv=none; b=QQEoPrHo7Rhp5Qa9KaNZfOeugoMjOfNiG+j2hxzZ/Pt8RHUngnD2dyKPW8buHlkfH44TyMsKqoZ+E1qDzLA8pyFUfhbYAwg+o8S80MoRbwab+3wg0uuZ/ILVD8Ej+MhyrwA7Gg8XRPMynsnO1CiQPf2YPLrFxctReP2XW327dcE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773150627; c=relaxed/simple; bh=UDAVIYVO8MkFU+qiMQHrkDiQ0TTMA/qUn6QW8DiB+6g=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=Th7NFPL7xOXL0jYqLaeJ9VB5zLhopsoCIp0xKCOT4BwqyvpXuMNjO2x5p6n54eDntyZ2xU6TPkRhwvycAY5euRAXnkDR4+L+5D2KDQGUdvS9KBBp8YhtE6UsOtxNAcVbs2yu7+shH8N208Y0vlgWaEV7HP7zfWuWhk2y0lxXHYk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=094H314B; arc=none smtp.client-ip=209.85.210.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="094H314B" Received: by mail-pf1-f202.google.com with SMTP id d2e1a72fcca58-829a9d3073bso1500437b3a.2 for ; Tue, 10 Mar 2026 06:50:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1773150624; x=1773755424; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=HiFH/eYHWvWCG/nFl2Qe5nesg6mZr7zLTC2RPw3wE9Q=; b=094H314BcT3nh07ZmNTKbUgkI2U8AGEIIlDfmpG5TGUu1QA+pyYQJ8PoUSwbxOsgT2 OdBXLD1m1nN4Z4FJ2kQ/asmnh2VqZYQ+GxWBmvqlW33fu/v9+xX9sNxkb6Uo48pnCMMJ NFxsJOBTpAzeIxiupMy/n9ZsUvDwZjpWZp/t3HCKGcWvYbd322ytA8gfDhNUAp34hP+E a+2425oZEQPKkaDoHdzOlmNmSKqZEd1IkoDLI/IvfeKcGStWIzweAlp8+mwUJznPhs1E FRe6PljJHDNu+uVJDjf27zEWhHoG9r8R5nWEbTCNGBAVT9YGA2C0Hn6RiYzedZmnizlN za0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773150624; x=1773755424; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=HiFH/eYHWvWCG/nFl2Qe5nesg6mZr7zLTC2RPw3wE9Q=; b=EGToX2RNGC5pPv+m+SZSc7IcqaOUmxfs5EQSOxhTsFOVr0pmGWJz9FH+U9WofEPAEt xDcVVmTJ8U/l8KBg1IxOHbG1YrzQODgvaEtU7q5NsfYlE+oS/6/KJvbjkEstBwsfk8m4 LGYi8fNQXt1ddJfTS6mzH3yOjoU6k8vcNARwng2x3lrPWSYxKUjnRV8ECuTUXUx1cofc U0/4qdWVlSx8RGr/r0JhPNJ4BiDcV7OZmCoqJVwHuuM+4PomotXCYwSB2TS/WLpUhG9h yMakTDdujoIa5l+/D0nEhZK6HtVo8dAaXK7OnjA1L5Vej89zk6NxB2BKeVr4eKwjFO30 rzVA== X-Forwarded-Encrypted: i=1; AJvYcCVclzsDDoNiYo7RJgYjC9XhYdL6VbBiTdFHQsJrx3vGdmJfUh5O5dRo9psAftiQHu/5MH1h0Sc=@vger.kernel.org X-Gm-Message-State: AOJu0Yz7F/xbJgfdoxUvO5isc2F5Niu7aHKWCf+eiN3IdZ71YPd+iZK9 MZ8/n9XtrN+F4Px5b6PCUGRJ92zHcVGp3lhyiT0GyO4RwddTcKammctDjxGpj2RwFN7pleT13tD /9xcNYw== X-Received: from pfbho6.prod.google.com ([2002:a05:6a00:8806:b0:829:7b09:ceff]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:4f87:b0:81f:4f05:4fe6 with SMTP id d2e1a72fcca58-829a2d98609mr12931026b3a.1.1773150623480; Tue, 10 Mar 2026 06:50:23 -0700 (PDT) Date: Tue, 10 Mar 2026 06:50:21 -0700 In-Reply-To: <88b3637c84737136da1fe373cde43801845bd062.camel@intel.com> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260302102226.7459-1-kai.huang@intel.com> <88b3637c84737136da1fe373cde43801845bd062.camel@intel.com> Message-ID: Subject: Re: [PATCH] x86/virt/tdx: Fix lockdep assertion failure in cache flush for kexec From: Sean Christopherson To: Kai Huang Cc: "pbonzini@redhat.com" , "kas@kernel.org" , Rick P Edgecombe , "dave.hansen@linux.intel.com" , "bp@alien8.de" , "x86@kernel.org" , "hpa@zytor.com" , "linux-kernel@vger.kernel.org" , Vishal L Verma , "tglx@kernel.org" , "stable@vger.kernel.org" , "mingo@redhat.com" Content-Type: text/plain; charset="us-ascii" 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 > > > Signed-off-by: Kai Huang > > > Tested-by: Vishal Verma > > > > Reviewed-by: Rick Edgecombe > > > > 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.