All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mostafa Saleh <smostafa@google.com>
To: Quentin Perret <qperret@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:25:46 +0000	[thread overview]
Message-ID: <aFvqyl-Xquuoyvh1@google.com> (raw)
In-Reply-To: <aFvqFdwNYI0-3zWY@google.com>

On Wed, Jun 25, 2025 at 12:22:45PM +0000, Quentin Perret wrote:
> 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?

Yes, I surprised in my testing I didn't see an issue with freeing NULL, I
though it might be config related, but I should have looked more.

> 
> 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?

Make sense, I will fix that in v2.

Thanks,
Mostafa

> 
> Thanks,
> Quentin

      reply	other threads:[~2025-06-25 12:25 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
2025-06-25 12:25   ` Mostafa Saleh [this message]

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=aFvqyl-Xquuoyvh1@google.com \
    --to=smostafa@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=qperret@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.