[PATCH 6.6 000/122] 6.6.28-rc1 review

[Greg Kroah-Hartman]

On Fri, Apr 19, 2024 at 11:50:14AM +0100, Marc Zyngier wrote:
> On Fri, 19 Apr 2024 11:40:33 +0100,
> Greg Kroah-Hartman <gregkh at 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 at 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 at linaro.org> wrote:
> > > > > > > On Tue, 16 Apr 2024 at 16:04, Mark Brown <broonie at 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, now queued up.

greg k-h