Re: [PATCH v3] KVM: arm64: Use BTI for nvhe

[Marc Zyngier]

On Wed, 12 Jul 2023 11:52:39 +0100,
"Linux regression tracking (Thorsten Leemhuis)" <regressions@xxxxxxxxxxxxx> wrote:
> 
> On 12.07.23 12:44, Marc Zyngier wrote:
> > On Wed, 12 Jul 2023 11:34:51 +0100,
> > "Linux regression tracking (Thorsten Leemhuis)" <regressions@xxxxxxxxxxxxx> wrote:
> >>
> >> [CCing the regression list, as it should be in the loop for regressions:
> >> https://docs.kernel.org/admin-guide/reporting-regressions.html]
> >>
> >> [TLDR: I'm adding this report to the list of tracked Linux kernel
> >> regressions; the text you find below is based on a few templates
> >> paragraphs you might have encountered already in similar form.
> >> See link in footer if these mails annoy you.]
> >>
> >> On 04.07.23 15:41, Sudeep Holla wrote:
> >>> On Tue, May 30, 2023 at 03:08:45PM +0000, Mostafa Saleh wrote:
> >>>> CONFIG_ARM64_BTI_KERNEL compiles the kernel to support ARMv8.5-BTI.
> >>>> However, the nvhe code doesn't make use of it as it doesn't map any
> >>>> pages with Guarded Page(GP) bit.
> >>> [...]
> >>> I was chasing a bug in linux-next yesterday with protected nVHE(pKVM) and
> >>> cpuidle enabled. The system fails to boot. I just bisected the issue to this
> >>> patch and also saw this patch landed in the linus tree yesterday/today.
> >>> Not sure if this is something to do with the fact that pKVM skips to
> >>> __kvm_handle_stub_hvc in __host_hvc.
> >>>
> >>> Let me know if you want be to try something.
> >>
> >> Thanks for the report. Seems the fix is slow to progress.
> > 
> > It's not. See [1].
> > 
> > [1] https://lore.kernel.org/r/20230706152240.685684-1-smostafa@xxxxxxxxxx
> 
> I'm aware of that fix, as one of the regzbot commands in the mail your
> quoted pointed to that mail. But unless I'm missing something that fix
> is now nearly a week old and not yet in -next. That from my point of
> view makes it "slow to progress" and trackworthy.

Shoving stuff in -next early is not a guarantee of the fix being
correct. Oddly enough, some of us value taking the time it takes to
make sure the fix is correct and addresses the *full* issue, not only
the reported corner case.

I know, this is not trendy. Too bad. On top of that, we don't push
fixes to -next either, so good luck tracking that.

	M.

-- 
Without deviation from the norm, progress is not possible.