From nobody Mon Feb 9 06:24:17 2026 Received: from mail-pj1-f74.google.com (mail-pj1-f74.google.com [209.85.216.74]) (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 9F41D54765 for ; Sat, 11 Jan 2025 01:04:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.74 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736557459; cv=none; b=Ofq6VZUVW37w/+hj7drnc2rBacqKI76VkwX3wTDQd4RgMvNUG02x5eqMvISMtTza/sVrAQeclQK8RPQLYRDt4M7D6rHZkW/stNpZag7/OzljfdoWuiO+ED6Xzvqz1j29TnJiMf1ZfpdJNgDPODQf6wlZCJTopDtc7bWq89omHXw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736557459; c=relaxed/simple; bh=38yKh50jmTM2QnQCwQHA2pD1K0ArDB2ne9BY9y0yDsE=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=kD82Y1ULmcNMddQeRnphT4SQU7X+XKQf468SYxnCs+kc5Mz/Vc7koPg+WJnIARogGlrx7CcRY07kaZMHvIOn/5AciY0saBvaiNnEgnz26vahnfpXsF33HGDM3W4spGTNUAsUuq5wkghFwJzieaTqvLMHF64XF1vLIFC80Zkqu/E= 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=OtwLxFBh; arc=none smtp.client-ip=209.85.216.74 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="OtwLxFBh" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-2ef9e4c5343so6698840a91.0 for ; Fri, 10 Jan 2025 17:04:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736557457; x=1737162257; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=qztCq3yN4c7V5VVWefuCXzG4z+KIAvAw68bTrwIGEiM=; b=OtwLxFBhXTN+tJ+2KUpBBqdXmvLd6QivviqhooqBIdpPjzAQnYEbmbLWXTQ9OKKAhZ h0PMoIdDfPxwSd4KEOmmwsQXCGZmb+s+5LUFFIqPq0kmHUK3gKlMT/7oZtwcS2OMmdCu fJKGsKXxyoCtAxaspOiRLZ95rwhrWXwyFL9Rr3QO8LLMcLC1oekmaPZ3Jse/NZmc4gFP qCAKEV0Q+pAU76dvkHUW/p7t++udkCGmsHuthpVWKbm1PfqhORHzxQyRORavYKTC3LU3 +A4WvGYoqIkrAYcMm6tiMEW+Uw04OReJlLPcrpSiJWcP4I/8eX5xNBVU1lxKO5MPXJ/G 9Ocg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736557457; x=1737162257; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qztCq3yN4c7V5VVWefuCXzG4z+KIAvAw68bTrwIGEiM=; b=E30TIHmqZJiiBw0o9Tq4ZQmMg3tQ83/Qui45Hhd5aCgIXajfmeLO+9Y+4ozRelM8nc ZdmnLffxNjDp28cKbVBocdWSABxB/A8FurkpTSpsx/knpEmCx6Ik/pEaPtpePdQbt3nr IQ5xKhzeLgRu9lMj69q2sExm15B92L77RJnpORxwMxM/DkrJSxUD9TBqDudhBHjfCdJI 7TYqRzwUB9cwQrggLPZat5Yyo0YU7+oH/jcqdDBnHJ+sTFu4sLtnfPoesxGfcBORHdWz c4bisQFYl/r6xFV8Z7agacOWo7lLu4TOc1gpxeyVtLI7+BM+8L52Ke72TsUbs+gYAp4C X4bw== X-Forwarded-Encrypted: i=1; AJvYcCU6+r0XOf0EV+aGQgIEa5yJYiqGmBu3K4CB8MG4mfZrpoO/OnTfKk6KDGZfjdLDAubEbSI688GBjNtE5Z0=@vger.kernel.org X-Gm-Message-State: AOJu0YwDrcSUX6Ay5Pz1RoXdG+66G1SkJ4lCSpiUfLtVSJG7BdnvdPqA OCo/VJXtBrxVejqUJwYBaO59q/yiEhyea2B+szyyRT72MbMgrnFhb4gyjbOQPRe9uc2N5+GkqbP UwA== X-Google-Smtp-Source: AGHT+IGWC2DYlQkU/EcPOOmwCPjaBsLhvhJQuYZtuDOFD2C754CM0kGzgUC90dVegSd+WxYgpA7SBB0o1w0= X-Received: from pjc4.prod.google.com ([2002:a17:90b:2f44:b0:2f2:ea3f:34c3]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:274e:b0:2f4:4003:f3ea with SMTP id 98e67ed59e1d1-2f5490f19c7mr19708701a91.33.1736557457046; Fri, 10 Jan 2025 17:04:17 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 10 Jan 2025 17:04:07 -0800 In-Reply-To: <20250111010409.1252942-1-seanjc@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250111010409.1252942-1-seanjc@google.com> X-Mailer: git-send-email 2.47.1.613.gc27f4b7a9f-goog Message-ID: <20250111010409.1252942-4-seanjc@google.com> Subject: [PATCH 3/5] KVM: Conditionally reschedule when resetting the dirty ring From: Sean Christopherson To: Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Peter Xu , Yan Zhao , Maxim Levitsky , Sean Christopherson Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When resetting a dirty ring, conditionally reschedule on each iteration after the first. The recently introduced hard limit mitigates the issue of an endless reset, but isn't sufficient to completely prevent RCU stalls, soft lockups, etc., nor is the hard limit intended to guard against such badness. Note! Take care to check for reschedule even in the "continue" paths, as a pathological scenario (or malicious userspace) could dirty the same gfn over and over, i.e. always hit the continue path. rcu: INFO: rcu_sched self-detected stall on CPU rcu: 4-....: (5249 ticks this GP) idle=3D51e4/1/0x4000000000000000 softi= rq=3D309/309 fqs=3D2563 rcu: (t=3D5250 jiffies g=3D-319 q=3D608 ncpus=3D24) CPU: 4 UID: 1000 PID: 1067 Comm: dirty_log_test Tainted: G L = 6.13.0-rc3-17fa7a24ea1e-HEAD-vm #814 Tainted: [L]=3DSOFTLOCKUP Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvm_arch_mmu_enable_log_dirty_pt_masked+0x26/0x200 [kvm] Call Trace: kvm_reset_dirty_gfn.part.0+0xb4/0xe0 [kvm] kvm_dirty_ring_reset+0x58/0x220 [kvm] kvm_vm_ioctl+0x10eb/0x15d0 [kvm] __x64_sys_ioctl+0x8b/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Tainted: [L]=3DSOFTLOCKUP Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvm_arch_mmu_enable_log_dirty_pt_masked+0x17/0x200 [kvm] Call Trace: kvm_reset_dirty_gfn.part.0+0xb4/0xe0 [kvm] kvm_dirty_ring_reset+0x58/0x220 [kvm] kvm_vm_ioctl+0x10eb/0x15d0 [kvm] __x64_sys_ioctl+0x8b/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Fixes: fb04a1eddb1a ("KVM: X86: Implement ring-based dirty memory tracking") Signed-off-by: Sean Christopherson --- virt/kvm/dirty_ring.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/virt/kvm/dirty_ring.c b/virt/kvm/dirty_ring.c index a81ad17d5eef..37eb2b7142bd 100644 --- a/virt/kvm/dirty_ring.c +++ b/virt/kvm/dirty_ring.c @@ -133,6 +133,16 @@ int kvm_dirty_ring_reset(struct kvm *kvm, struct kvm_d= irty_ring *ring, =20 ring->reset_index++; (*nr_entries_reset)++; + + /* + * While the size of each ring is fixed, it's possible for the + * ring to be constantly re-dirtied/harvested while the reset + * is in-progress (the hard limit exists only to guard against + * wrapping the count into negative space). + */ + if (!first_round) + cond_resched(); + /* * Try to coalesce the reset operations when the guest is * scanning pages in the same slot. --=20 2.47.1.613.gc27f4b7a9f-goog