On Wed, Apr 17, 2024 at 09:05:12AM +0200, Greg Kroah-Hartman wrote: > On Tue, Apr 16, 2024 at 06:28:10PM +0100, Catalin Marinas 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@xxxxxxxxxx> wrote: > > > > On Tue, 16 Apr 2024 at 16:04, Mark Brown <broonie@xxxxxxxxxx> 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. > > How about I drop the offending commit from stable and let you all figure > out what needs to be added before applying anything else :) It makes sense ;). We'll send them to stable once sorted. -- Catalin