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

[Linux regression tracking (Thorsten Leemhuis)]

On 12.07.23 13:01, Marc Zyngier wrote:
> 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.

All that is totally fine with me. Sorry, we got off on the wrong foot,
because I didn't choose my words carefully. Apologies. All I wanted to
express was: "I saw a bug report and a fix for it; I wouldn't have added
this to the tracking if that fix was already heading towards mainline".

Ciao, Thorsten