From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 64296C4345F for ; Fri, 19 Apr 2024 10:40:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=KVakPlvKitpSKMKnUDh6kf0P9W4vHGCXKZ9w3tuqjW0=; b=uOdUrGCyKXIO6l j0pR1NzrzsmfUiybRRIHHuoWbohZvbr5QLySDGziT4NvCH2io9Tg0yn/K3wPn35E7V2gAsiHGugx7 r0tyM0L0OWCBBbAPDgoSz6cdDwkLIVyJJ1xpdhG7GfRY4Y4xn2vief/7b5flF2M3MDjisb+6WBDrZ rH14jak9B5eI9DXD+kAIA+foG6DZOMa5vUCbE8XJ9QwZrpn+q142ov0JcD0y+PZyqqzSG1NgondCv DGJdUR92TzBJ+gmlYjoaEYxI5R2oDXg9bzDQXj+Z0iqMBgEU9OJ9TeQbSsjq8tgEVOd/XAMbd502B Xw7iOutMNFu4FHkMzOtg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rxlfh-00000005LPl-0xo5; Fri, 19 Apr 2024 10:40:45 +0000 Received: from sin.source.kernel.org ([2604:1380:40e1:4800::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rxlfe-00000005LOw-0Z07 for linux-arm-kernel@lists.infradead.org; Fri, 19 Apr 2024 10:40:44 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 8ED58CE1A73; Fri, 19 Apr 2024 10:40:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1AEF6C072AA; Fri, 19 Apr 2024 10:40:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1713523238; bh=ri/VNF8+x+uUhczJHngVNn6oFRLkfNLj0bwKqlWZIzQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=WeC3+ENvz+TN27Esdm/RbWH+MG+s52+P+bjha7fh95m1E0R3zZqhRs5qy7O1L7AoZ WH+9c+FL/fcXE9NtLidlL68LN3n4sZwxNLAm981tf8xB0NB0z5p7RQ3D9KibYOSWSi XbSt5h9BofkxGJLzcOEQfHvCt42ap4UBvBJKKhb0= Date: Fri, 19 Apr 2024 12:40:33 +0200 From: Greg Kroah-Hartman To: Catalin Marinas Cc: Marc Zyngier , Naresh Kamboju , Mark Brown , stable@vger.kernel.org, patches@lists.linux.dev, linux-kernel@vger.kernel.org, torvalds@linux-foundation.org, akpm@linux-foundation.org, linux@roeck-us.net, shuah@kernel.org, patches@kernelci.org, lkft-triage@lists.linaro.org, pavel@denx.de, jonathanh@nvidia.com, f.fainelli@gmail.com, sudipm.mukherjee@gmail.com, srw@sladewatkins.net, rwarsow@gmx.de, conor@kernel.org, allen.lkml@gmail.com, Yihuang Yu , Gavin Shan , Ryan Roberts , Anshuman Khandual , Shaoqin Huang , Will Deacon , linux-arm-kernel@lists.infradead.org, Anders Roxell Subject: Re: [PATCH 6.6 000/122] 6.6.28-rc1 review Message-ID: <2024041921-drown-dizzy-7481@gregkh> References: <20240415141953.365222063@linuxfoundation.org> <86y19dqw74.wl-maz@kernel.org> <86sezjq688.wl-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240419_034042_575864_4D090465 X-CRM114-Status: GOOD ( 35.83 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 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 wrote: > > > > > On Tue, 16 Apr 2024 at 16:04, Mark Brown 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? thanks, greg k-h _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel