From nobody Mon Feb 9 13:00:29 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 E73B021106 for ; Sat, 11 Jan 2025 01:04:18 +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=1736557460; cv=none; b=qWwaMkFr3n42/MHMmoxq1u4M8GlKZUBgejyrr7WGMePDPRrSzIi7trycFsfv98PV4tc1XaCPW3RuS+CqKc8cG1PUb7liynRQVXEFQWfd8wPM79hlMWFkC6+idd/k0B4tQzxH8g+jXkOiGr6RjFp9r/AqRlEDz1qkUSOK1ijjVHc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736557460; c=relaxed/simple; bh=4AOojhK7RgZpfHVFyZZg/F1b+66In+n0W7FklHWokKs=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=UxocSp4FgQYrQt24NfnqaStjfLNjLsz9UtQd4STyypGba7pdhE1qYwd1EcCgq0bkXZdTDpaDM0AINN5mZEtVJ2Txke1jZ6IEJKqCESG/eSaEt6EIEdLblEoEPzPe4+ky6TuVX0728Jmf9C7vv+0tTzdUyG4OkzrKKP6MKkR1Fls= 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=SS4Dk6LS; 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="SS4Dk6LS" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-2ef9da03117so6730253a91.1 for ; Fri, 10 Jan 2025 17:04:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736557458; x=1737162258; 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=oGi7slrEyYAnwuVNpr6ZrhtkCDMVeK/CUwkbMoeq/cE=; b=SS4Dk6LSfD/sZVtJuIMAVMzMhrSGOGVePoGpUZYs9dQbksms/LORsyTEjwcBrCiPsm Zx7QTXq1sVxb/+vcWoutAybzoOisOCfZ9MnwaZYq7SP6twNqXyf522SM4BIbVdZ4z3MN zf3yj1qjBK4Z60Fv/IoxZNu1gzAzsK6Z4AilPcbZV58NKEHEZD4j284X7kW1wcRw1Ttt 6Wb4NMMzHwag04ebjlaDTguwP/Vn4VYkMM90SojZYjHg12YeMX40p5/zAlwK3rPyFxqy rC8f3Jsl5EbxgU+E/U03ZGZcvwyyz7W09BBQCIG4+Q9r8CPciGEpcPS0lzKsPbCWK1fe E7PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736557458; x=1737162258; 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=oGi7slrEyYAnwuVNpr6ZrhtkCDMVeK/CUwkbMoeq/cE=; b=m6jeYkwd2Kcj5F+Qe2SSguvJn0oWNpAygwRJRqe/h4boy9LyOjkwlpDhE9yQgvuuSa IPmq0J0qHm0I9k8cXX+WeZCjVgBQJ/zYeLP5uFczjrRMsTiLhe63lq+Ksx5qXTuUV6uK sPl4MXpsP+p9nG+ws6wBR2Jl1sntnbKkgKq/KM1/2cleprG8QF+LZv/cCpz1KSZEnnsI yU2e91zwSMoYglumIhE6FLJeVzDitXUF+taJOQE0aAuw41fv+ZvYnDUOwZvUV3WShF/u m7T8pNZDVmiLyfjCPyPb7cfaXqEC4p2U3ROIroFyW2070IfurJ8DPyzt8rzXsNfoHJ3O xcUw== X-Forwarded-Encrypted: i=1; AJvYcCWKZcm4Nwy3t+A3eeKpBFl78MY8tiMraw7ORVVNc+Z6dSXmkSZTcN/D3eTvLfNdh4dX41yP2lTKrYmDGpI=@vger.kernel.org X-Gm-Message-State: AOJu0Yx2PifrEyhLGlVfYSoJMofl8jLO1w39yXkqNDiej2EnbNDlAmIc wXeUQsFTYopcF5YXeqGYjXLBJVDi0mtWbEo24orzwigM89rvx6tY6cCFCBE3PUS6duVyt3x5cH4 wSA== X-Google-Smtp-Source: AGHT+IEU0JMvjhrXcRzpNyyxrvcQqODJ1wZPu5PG2qjeWRbJZlS0/3S5feFaFOwVGoqKiMB61Iex5Pfl42k= X-Received: from pfwz22.prod.google.com ([2002:a05:6a00:1d96:b0:725:e37e:7451]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:3e13:b0:725:eacf:cfda with SMTP id d2e1a72fcca58-72d21fe0263mr18801122b3a.17.1736557458526; Fri, 10 Jan 2025 17:04:18 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 10 Jan 2025 17:04:08 -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-5-seanjc@google.com> Subject: [PATCH 4/5] KVM: Check for empty mask of harvested dirty ring entries in caller 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, explicitly check that there is work to be done before calling kvm_reset_dirty_gfn(), e.g. if no harvested entries are found and/or on the loop's first iteration, and delete the extremely misleading comment "This is only needed to make compilers happy". KVM absolutely relies on mask to be zero-initialized, i.e. the comment is an outright lie. Furthermore, the compiler is right to complain that KVM is calling a function with uninitialized data, as there are no guarantees the implementation details of kvm_reset_dirty_gfn() will be visible to kvm_dirty_ring_reset(). While the flaw could be fixed by simply deleting (or rewording) the comment, and duplicating the check is unfortunate, checking mask in the caller will allow for additional cleanups. Opportunisticaly drop the zero-initialization of cur_slot and cur_offset. If a bug were introduced where either the slot or offset was consumed before mask is set to a non-zero value, then it is highly desirable for the compiler (or some other sanitizer) to yell. Cc: Peter Xu Cc: Yan Zhao Cc: Maxim Levitsky Signed-off-by: Sean Christopherson --- virt/kvm/dirty_ring.c | 29 ++++++++++++++++++++--------- 1 file changed, 20 insertions(+), 9 deletions(-) diff --git a/virt/kvm/dirty_ring.c b/virt/kvm/dirty_ring.c index 37eb2b7142bd..95ab0e3cf9da 100644 --- a/virt/kvm/dirty_ring.c +++ b/virt/kvm/dirty_ring.c @@ -55,9 +55,6 @@ static void kvm_reset_dirty_gfn(struct kvm *kvm, u32 slot= , u64 offset, u64 mask) struct kvm_memory_slot *memslot; int as_id, id; =20 - if (!mask) - return; - as_id =3D slot >> 16; id =3D (u16)slot; =20 @@ -109,13 +106,10 @@ int kvm_dirty_ring_reset(struct kvm *kvm, struct kvm_= dirty_ring *ring, { u32 cur_slot, next_slot; u64 cur_offset, next_offset; - unsigned long mask; + unsigned long mask =3D 0; struct kvm_dirty_gfn *entry; bool first_round =3D true; =20 - /* This is only needed to make compilers happy */ - cur_slot =3D cur_offset =3D mask =3D 0; - while (likely((*nr_entries_reset) < INT_MAX)) { if (signal_pending(current)) return -EINTR; @@ -163,14 +157,31 @@ int kvm_dirty_ring_reset(struct kvm *kvm, struct kvm_= dirty_ring *ring, continue; } } - kvm_reset_dirty_gfn(kvm, cur_slot, cur_offset, mask); + + /* + * Reset the slot for all the harvested entries that have been + * gathered, but not yet fully processed. + */ + if (mask) + kvm_reset_dirty_gfn(kvm, cur_slot, cur_offset, mask); + + /* + * The current slot was reset or this is the first harvested + * entry, (re)initialize the metadata. + */ cur_slot =3D next_slot; cur_offset =3D next_offset; mask =3D 1; first_round =3D false; } =20 - kvm_reset_dirty_gfn(kvm, cur_slot, cur_offset, mask); + /* + * Perform a final reset if there are harvested entries that haven't + * been processed. The loop only performs a reset when an entry can't + * be coalesced, i.e. always leaves at least one entry pending. + */ + if (mask) + kvm_reset_dirty_gfn(kvm, cur_slot, cur_offset, mask); =20 /* * The request KVM_REQ_DIRTY_RING_SOFT_FULL will be cleared --=20 2.47.1.613.gc27f4b7a9f-goog