All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Claudio Imbrenda" <imbrenda@linux.ibm.com>
Cc: linux-s390@vger.kernel.org, kvm@vger.kernel.org,
	"Vasily Gorbik" <gor@linux.ibm.com>,
	"Heiko Carstens" <hca@linux.ibm.com>,
	"Alexander Gordeev" <agordeev@linux.ibm.com>
Subject: Re: [PATCH v1 6/8] KVM: s390: cmma: Fix dirty tracking when removing memslot
Date: Thu, 02 Jul 2026 15:48:05 +0000	[thread overview]
Message-ID: <20260702154807.997981F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260702152406.204782-7-imbrenda@linux.ibm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Double decrement and underflow of cmma_dirty_pages counter when recreating unaligned memslots.
--

commit cfdf82bf92088bc4e4a719ccbb0ad71b6708ed76
Author: Claudio Imbrenda <imbrenda@linux.ibm.com>

KVM: s390: cmma: Fix dirty tracking when removing memslot

This commit fixes the dirty tracking counter when a memslot is removed.
It introduces a dat_walk_ops callback to appropriately decrement the
cmma-dirty counter for any cmma-dirty pages being removed.

> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index 512c81eee0684..2ac3a9ac46988 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c

[ ... ]

> @@ -5792,11 +5792,19 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
>  	return 0;
>  }
>  
> +static long cmma_d_count_pte(union pte *ptep, gfn_t gfn, gfn_t next, struct dat_walk *walk)
> +{
> +	if (pgste_of(ptep)->cmma_d)
> +		atomic64_dec(walk->priv);

[Severity: High]
Does this leave the cmma_d bit set in the PGSTE, which could lead to a double
decrement later?

If a memslot that isn't fully 1MB-aligned is removed or moved,
dat_delete_slot() replaces the PTEs with hole tokens but preserves the PGSTEs.
When userspace creates a new memslot over the same GFN range, dat_create_slot()
replaces the hole tokens with empty PTEs, leaving the stale cmma_d == 1 bits
intact.

During migration, could dat_get_cmma() visit these newly recreated empty PTEs,
see cmma_d == 1, clear the bit, and decrement the counter a second time?

This would cause the cmma_dirty_pages counter to underflow. Since this value is
returned to userspace as an unsigned 64-bit integer, an underflow could cause
QEMU's live migration loop to never converge.

Should we clear the cmma_d bit here after decrementing the counter?

> +	return 0;
> +}
> +
>  void kvm_arch_commit_memory_region(struct kvm *kvm,
>  				struct kvm_memory_slot *old,
>  				const struct kvm_memory_slot *new,
>  				enum kvm_mr_change change)

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260702152406.204782-1-imbrenda@linux.ibm.com?part=6

  reply	other threads:[~2026-07-02 15:48 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-02 15:23 [PATCH v1 0/8] KVM: s390: Misc fixes Claudio Imbrenda
2026-07-02 15:23 ` [PATCH v1 1/8] KVM: s390: vsie: Avoid potential deadlock with real spaces Claudio Imbrenda
2026-07-02 15:24 ` [PATCH v1 2/8] KVM: s390: Fix unlikely NULL gmap dereference Claudio Imbrenda
2026-07-02 15:43   ` sashiko-bot
2026-07-02 15:24 ` [PATCH v1 3/8] KVM: s390: Fix unlikely race with KVM_CAP_S390_USER_OPEREXEC Claudio Imbrenda
2026-07-02 15:42   ` sashiko-bot
2026-07-02 17:08   ` Eric Farman
2026-07-02 15:24 ` [PATCH v1 4/8] KVM: s390: Fix return value of kvm_s390_set_cmma_bits() Claudio Imbrenda
2026-07-02 15:37   ` sashiko-bot
2026-07-02 15:24 ` [PATCH v1 5/8] KVM: s390: Fix race in __do_essa() Claudio Imbrenda
2026-07-02 15:34   ` sashiko-bot
2026-07-02 15:24 ` [PATCH v1 6/8] KVM: s390: cmma: Fix dirty tracking when removing memslot Claudio Imbrenda
2026-07-02 15:48   ` sashiko-bot [this message]
2026-07-02 15:24 ` [PATCH v1 7/8] KVM: s390: Fix dat_crste_walk_range() early return Claudio Imbrenda
2026-07-02 15:24 ` [PATCH v1 8/8] KVM: s390: Improve kvm_s390_vm_stop_migration() Claudio Imbrenda

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260702154807.997981F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=agordeev@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.