From: Sebastian Ene <sebastianene@google.com>
To: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Marc Zyngier <maz@kernel.org>, Mark Brown <broonie@kernel.org>,
catalin.marinas@arm.com, joey.gouly@arm.com,
kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, oliver.upton@linux.dev,
will@kernel.org, Aishwarya.TCV@arm.com
Subject: Re: [PATCH] KVM: arm64: Fix the upper limit of the walker range
Date: Thu, 16 Jan 2025 14:50:03 +0000 [thread overview]
Message-ID: <Z4kcmwzoRINgTtrO@google.com> (raw)
In-Reply-To: <e79c78a7-24a3-42e6-a217-ec64f8320e91@arm.com>
On Thu, Jan 16, 2025 at 01:49:54PM +0000, Suzuki K Poulose wrote:
Hi,
> On 16/01/2025 10:55, Marc Zyngier wrote:
> > On Thu, 16 Jan 2025 01:16:40 +0000,
> > Mark Brown <broonie@kernel.org> wrote:
> > >
> > > On Tue, Jan 14, 2025 at 02:50:51PM +0000, Sebastian Ene wrote:
> > >
> > > > Prevent the walker from running into weeds when walking an
> > > > entire address range.
> > >
> > > The KVM page_fault_test selftest started failing in next-20250115 on
> > > at least n1sdp and TX2 in VHE mode and a bisect seems to point to this
> > > change. The bisect only just finished, I've done no further
> > > investigation.
> > >
> > > When the test fails it generates backtraces like that below:
> >
> > [...]
> >
> > Thanks for the heads up.
> >
> > Given how close we are to the merge window opening, I've dropped this
> > patch from -next.
> >
> > Seb: it looks this breaks a bunch of existing assumptions. Let's
> > revisit this before -rc1, if possible.
> In kvm_pgtable_walk() we set the walk_data.end to PAGE_ALIGNED(start +
> size), where size is BIT(ia_size) and start = 0, for
> kvm_pgtable_stage2_destroy().
>
> And subtracting the limit in _kvm_pgtable_walk makes things go bad,
> returning -ERANGE.
> Given the kvm_pgtable_walk() passes the "end" as the top address (not
> including it), and is always PAGE_ALIGNED, we should probably leave things
> as it is in the code.
>
Thanks for looking into this.
I have a fix but it is too much of a surgery so we decided not to send
it and instead go with the removal of my change.
>
> Cheers
> Suzuki
>
>
> >
> > Thanks,
> >
> > M.
> >
>
Thanks,
Sebastian
prev parent reply other threads:[~2025-01-16 14:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-14 14:50 [PATCH] KVM: arm64: Fix the upper limit of the walker range Sebastian Ene
2025-01-14 14:55 ` Marc Zyngier
2025-01-14 15:03 ` Sebastian Ene
2025-01-14 15:08 ` Marc Zyngier
2025-01-14 15:07 ` Marc Zyngier
2025-01-16 1:16 ` Mark Brown
2025-01-16 2:07 ` Mark Brown
2025-01-16 10:55 ` Marc Zyngier
2025-01-16 13:49 ` Suzuki K Poulose
2025-01-16 14:50 ` Sebastian Ene [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=Z4kcmwzoRINgTtrO@google.com \
--to=sebastianene@google.com \
--cc=Aishwarya.TCV@arm.com \
--cc=broonie@kernel.org \
--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=suzuki.poulose@arm.com \
--cc=will@kernel.org \
/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.