From: sashiko-bot@kernel.org
To: "Christian Borntraeger" <borntraeger@linux.ibm.com>
Cc: "Heiko Carstens" <hca@linux.ibm.com>,
"Vasily Gorbik" <gor@linux.ibm.com>,
kvm@vger.kernel.org, "Alexander Gordeev" <agordeev@linux.ibm.com>,
linux-s390@vger.kernel.org
Subject: Re: [PATCH v2 7/7] KVM: s390: Free guest debug data on vcpu destroy
Date: Tue, 04 Aug 2026 18:47:06 +0000 [thread overview]
Message-ID: <20260804184706.E2B2B1F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260804162435.28617-8-borntraeger@linux.ibm.com>
> kvm_s390_clear_bp_data() is only called from
> kvm_arch_vcpu_ioctl_set_guest_debug(), i.e. when user space changes or
> disables debugging. A vCPU that is destroyed while hardware breakpoints
> are still armed - the normal case when the VMM just exits or crashes -
> leaks hw_bp_info, hw_wp_info and all old_data buffers, since generic KVM
> frees the vCPU right after kvm_arch_vcpu_destroy().
>
> That is bounded by MAX_BP_COUNT entries, so roughly 8 KiB per vCPU, but
> it is unbounded over VM lifetimes. The allocations are
> GFP_KERNEL_ACCOUNT, so the charge also outlives the exiting process and
> pins dying memcgs.
>
> Fix by clearing the debug data on vCPU destruction. Calling it
> unconditionally is fine: struct kvm_vcpu is zero allocated, so for a vCPU
> that never enabled debugging the counters are 0 and the pointers NULL.
>
> Fixes: 27291e2165b6 ("KVM: s390: hardware support for guest debugging")
> Cc: stable@vger.kernel.org
> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260804162435.28617-1-borntraeger@linux.ibm.com?part=7
next prev parent reply other threads:[~2026-08-04 18:47 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-04 16:24 [PATCH v2 0/7] KVM: s390: more fixes Christian Borntraeger
2026-08-04 16:24 ` [PATCH v2 1/7] KVM: s390: Remove user triggerable WARN_ON Christian Borntraeger
2026-08-04 16:33 ` sashiko-bot
2026-08-04 17:47 ` Douglas Freimuth
2026-08-04 16:24 ` [PATCH v2 2/7] KVM: s390: Zero initialize data structures for inject_pfault_token Christian Borntraeger
2026-08-04 17:05 ` sashiko-bot
2026-08-04 16:24 ` [PATCH v2 3/7] KVM: s390: Zero initialize irq in reinject_machine_check Christian Borntraeger
2026-08-04 17:18 ` Matthew Rosato
2026-08-04 17:20 ` sashiko-bot
2026-08-04 16:24 ` [PATCH v2 4/7] KVM: s390: Fix memory leak in guest debug handling Christian Borntraeger
2026-08-04 18:00 ` sashiko-bot
2026-08-04 16:24 ` [PATCH v2 5/7] KVM: s390: Fix old_data leak in guest debug error path Christian Borntraeger
2026-08-04 17:19 ` Matthew Rosato
2026-08-04 18:19 ` sashiko-bot
2026-08-04 16:24 ` [PATCH v2 6/7] KVM: s390: Take srcu when importing watchpoint data Christian Borntraeger
2026-08-04 18:40 ` sashiko-bot
2026-08-05 8:21 ` Christian Borntraeger
2026-08-04 16:24 ` [PATCH v2 7/7] KVM: s390: Free guest debug data on vcpu destroy Christian Borntraeger
2026-08-04 18:47 ` sashiko-bot [this message]
2026-08-04 20:03 ` Matthew Rosato
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=20260804184706.E2B2B1F00A3D@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@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.