From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 3DB32438004; Thu, 6 Aug 2026 09:52:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786009946; cv=none; b=lJQy6lfYSM+rfT8geWPjbC5VIHwRFjeNQ/USlKnUx7joNfFtvNCp42QkfMdjQ9h//7Nfj153Zf05bTTZ9ZIuMjxpQTmSxITR68zUdaEcEfLz0xxjEH8J4CTiZLt5nvqmNzAgCxrnSCLdTkh3DB8BISHh3BcoTm2Ywtdh9McEkRw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786009946; c=relaxed/simple; bh=wfOtogsiDhdgFl5X25Hmcqc7cHMVFzmxiJMPo7wbrk8=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=H/e8IDYGXz0ILj1T0d8hWWQ/ZXQryOOw9a9PbVG9QW+xiBw8IxrQUSGt/MYx6yha4zIaAbTCFtjwgAZyHhCHoqartjIRFDVrpckTgxmwTnZoqTuuG+FRY401T71uwmR4CvjbmmrFpqGi/RxBiY5Qm7WgJ2htWTH5MVljGv/t2Z8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Bu2g3P7Y; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Bu2g3P7Y" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AB1351F00A3A; Thu, 6 Aug 2026 09:52:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786009944; bh=yy/PBymCnUnAsLNJv5RqBWp45lwidiqpkJnTenKI7GE=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=Bu2g3P7YeC/Cw9wNhPftVtqXbNKoevmqRtZZbh2Cdi5mjmCTu5DR5dsLgGB8BNtFj 8LQ7K0WVs/4/Rsg3NSEa1O8dYlxqbjC9o+bD9UxH2zikEdFjq6VpspvN63vrydf3d9 vqN+L0QEyRm4BrkN6X+QqKmbnK6IzjG5KQ9U+JwTDzQS2lG7PBNe1mp98VCER7AVSc 3z6x5PuAIqELx4TYjCP/75MV3L25yJ1ts+4kWF3OA1fjsG98D1Z/BqnOZu6GJkzGxD TimvPqGCM1Rh5uMLz9RVZeZ5SW4420N9dNUVCQO7RROU73nwIlSu6Iu4emvNY/mtFD Kj/JiKdIcplOQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wruly-0000000CuNp-2k16; Thu, 06 Aug 2026 09:52:22 +0000 Date: Thu, 06 Aug 2026 10:52:22 +0100 Message-ID: <86a4qzbmp5.wl-maz@kernel.org> From: Marc Zyngier To: sashiko-reviews@lists.linux.dev Cc: "Oliver Upton" , kvmarm@lists.linux.dev, kvm@vger.kernel.org Subject: Re: [PATCH v2 5/8] KVM: arm64: Handle VNCR TLB invalidation race with vcpu_put() VNCR unmapping In-Reply-To: <20260806092540.501541F000E9@smtp.kernel.org> References: <20260806091026.620700-1-maz@kernel.org> <20260806091026.620700-6-maz@kernel.org> <20260806092540.501541F000E9@smtp.kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: sashiko-reviews@lists.linux.dev, oupton@kernel.org, kvmarm@lists.linux.dev, kvm@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Thu, 06 Aug 2026 10:25:39 +0100, sashiko-bot@kernel.org wrote: > > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: > > Pre-existing issues: > - [High] Acquiring `mmu_lock` with preemption disabled causes a sleep-in-atomic bug on PREEMPT_RT kernels. > -- > > --- Patch [5]: [PATCH v2 5/8] KVM: arm64: Handle VNCR TLB invalidation race with vcpu_put() VNCR unmapping --- > commit 7a7c469ac4158e77c3548a526ab62a924ed75161 > Author: Marc Zyngier > > KVM: arm64: Handle VNCR TLB invalidation race with vcpu_put() VNCR unmapping > > This patch addresses a race condition between VNCR TLB invalidation and VNCR > unmapping during vcpu_put(). It introduces an atomic exchange for resetting > the cpu tracking field and a common function for unmapping, ensuring these > operations happen atomically. This closes the TOCTOU race and prevents > concurrent mapping faults. > > Link: https://lore.kernel.org/r/20260801130237.0FD8F1F00ACA@smtp.kernel.org > > > diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c > > index 67cc5b6d80705..05f0e7e89e982 100644 > > --- a/arch/arm64/kvm/nested.c > > +++ b/arch/arm64/kvm/nested.c > > [ ... ] > > > @@ -1584,8 +1607,6 @@ static void kvm_map_l1_vncr(struct kvm_vcpu *vcpu) > > [Severity: High] > This is a pre-existing issue, but does acquiring mmu_lock inside a > preemption-disabled region here cause a sleep-in-atomic bug on RT kernels? > > Looking at kvm_map_l1_vncr() from the context, it starts with: > > static void kvm_map_l1_vncr(struct kvm_vcpu *vcpu) > { > struct vncr_tlb *vt = vcpu->arch.vncr_tlb; > pgprot_t prot; > > guard(preempt)(); > guard(read_lock)(&vcpu->kvm->mmu_lock); > > Since read_lock() is implemented as an RT-mutex on PREEMPT_RT and can block, > could this sequence trigger a scheduling-while-atomic panic if the lock is > contended? I think we need to understand what that means for the state of the fixmap if we get preempted at this point. I think it is OK as long as the read_lock itself disables preemption but this is sketchy. In any case, RT+NV is not something I wish to think about right now. M. -- Without deviation from the norm, progress is not possible.