From: Quentin Perret <qperret@google.com>
To: Mostafa Saleh <smostafa@google.com>
Cc: linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, maz@kernel.org,
oliver.upton@linux.dev, joey.gouly@arm.com,
suzuki.poulose@arm.com, yuzenghui@huawei.com,
catalin.marinas@arm.com, will@kernel.org
Subject: Re: [PATCH] KVM: arm64: Fix error path in init_hyp_mode()
Date: Wed, 25 Jun 2025 12:22:45 +0000 [thread overview]
Message-ID: <aFvqFdwNYI0-3zWY@google.com> (raw)
In-Reply-To: <20250625113301.580253-1-smostafa@google.com>
On Wednesday 25 Jun 2025 at 11:33:01 (+0000), Mostafa Saleh wrote:
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index 38a91bb5d4c7..5bb36c3b06b5 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -2344,15 +2344,22 @@ static void __init teardown_hyp_mode(void)
> int cpu;
>
> free_hyp_pgds();
> + /* Order matches the order of initialization init_hyp_mode() */
> for_each_possible_cpu(cpu) {
> + if (!per_cpu(kvm_arm_hyp_stack_base, cpu))
> + continue;
> free_pages(per_cpu(kvm_arm_hyp_stack_base, cpu), NVHE_STACK_SHIFT - PAGE_SHIFT);
> +
> + if (!kvm_nvhe_sym(kvm_arm_hyp_percpu_base)[cpu])
> + continue;
> free_pages(kvm_nvhe_sym(kvm_arm_hyp_percpu_base)[cpu], nvhe_percpu_order());
>
> if (free_sve) {
> struct cpu_sve_state *sve_state;
>
> sve_state = per_cpu_ptr_nvhe_sym(kvm_host_data, cpu)->sve_state;
> - free_pages((unsigned long) sve_state, pkvm_host_sve_state_order());
> + if (sve_state)
> + free_pages((unsigned long) sve_state, pkvm_host_sve_state_order());
I'm a bit confused by these extra checks -- free_pages() should be safe
to call on NULL?
IIUC correctly, the actual issue is that per_cpu_ptr_nvhe_sym() will
dereference the per-cpu pages to find the sve state, which is entirely
bogus if the per-cpu pages have not been allocated. Now, looking at
this, it looks like the bigger problem is that we literally free the
per-cpu pages right before the sve state...
Should we at least change the freeing order here?
Thanks,
Quentin
next prev parent reply other threads:[~2025-06-25 12:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-25 11:33 [PATCH] KVM: arm64: Fix error path in init_hyp_mode() Mostafa Saleh
2025-06-25 12:22 ` Quentin Perret [this message]
2025-06-25 12:25 ` Mostafa Saleh
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=aFvqFdwNYI0-3zWY@google.com \
--to=qperret@google.com \
--cc=catalin.marinas@arm.com \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=smostafa@google.com \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.com \
/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.