On Fri, 19 Apr 2024 11:40:33 +0100, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Thu, Apr 18, 2024 at 12:21:17PM +0100, Catalin Marinas wrote:
On Thu, Apr 18, 2024 at 12:07:35PM +0100, Marc Zyngier wrote:
On Tue, 16 Apr 2024 18:28:10 +0100, Catalin Marinas catalin.marinas@arm.com wrote:
On Tue, Apr 16, 2024 at 02:22:07PM +0100, Marc Zyngier wrote:
On Tue, 16 Apr 2024 14:07:30 +0100, Naresh Kamboju naresh.kamboju@linaro.org wrote:
On Tue, 16 Apr 2024 at 16:04, Mark Brown broonie@kernel.org wrote: > On Mon, Apr 15, 2024 at 04:19:25PM +0200, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 6.6.28 release. > > There are 122 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > The bisect of the boot issue that's affecting the FVP in v6.6 (only) > landed on c9ad150ed8dd988 (arm64: tlb: Fix TLBI RANGE operand), > e3ba51ab24fdd in mainline, as being the first bad commit - it's also in > the -rc for v6.8 but that seems fine. I've done no investigation beyond > the bisect and looking at the commit log to pull out people to CC and > note that the fix was explicitly targeted at v6.6.
Anders investigated this reported issues and bisected and also found the missing commit for stable-rc 6.6 is e2768b798a19 ("arm64/mm: Modify range-based tlbi to decrement scale")
Which is definitely *not* stable candidate. We need to understand why the invalidation goes south when the scale go up instead of down.
If you backport e3ba51ab24fd ("arm64: tlb: Fix TLBI RANGE operand") which fixes 117940aa6e5f ("KVM: arm64: Define kvm_tlb_flush_vmid_range()") but without the newer e2768b798a19 ("arm64/mm: Modify range-based tlbi to decrement scale"), it looks like "scale" in __flush_tlb_range_op() goes out of range to 4. Tested on my CBMC model, not on the actual kernel. It may be worth adding some WARN_ONs in __flush_tlb_range_op() if scale is outside the 0..3 range or num greater than 31.
I haven't investigated properly (and I'm off tomorrow, back on Thu) but it's likely the original code was not very friendly to the maximum range, never tested. Anyway, if one figures out why it goes out of range, I think the solution is to also backport e2768b798a19 to stable.
I looked into this, and I came to the conclusion that this patch is pretty much incompatible with the increasing scale (even if you cap num to 30).
Thanks Marc for digging into this.
So despite my earlier comment, it looks like picking e2768b798a19 is the right thing to do *if* we're taking e3ba51ab24fd into 6.6-stable.
Otherwise, we need a separate fix, which Ryan initially advocating for initially.
My preference would be to cherry-pick the two upstream commits than coming up with an alternative fix for 6.6.
To be specific, which 2 commits, and what order?
That'd be:
e2768b798a19 ("arm64/mm: Modify range-based tlbi to decrement scale")
followed by:
e3ba51ab24fd ("arm64: tlb: Fix TLBI RANGE operand")
Thanks,
M.