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 4B3F7C4345F for ; Thu, 18 Apr 2024 11:08:03 +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:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=yEWaEGPYVf+D58tdujbfwGMUUmcsM3mJYTMxA3zD7E4=; b=Y2llNmr7Tx/5La 2eHUMEWvcGMXlthLSuhL697JerOqevt5NPuJxjuNDGq0ZjrdO3AlN13JHzOBEL4cnglPophW2UU++ w9eHfBGxVRxcy6ZqrETRwoIrUOltwn1jjABnmXAIAiaBpDpUZzQWqk6rK2U3xI1ZyrlVStYhCRFAU He3aYKBjFBp8VYR3mqfBjlv5Zzj/7JXjI/OsKJmFUov4XEEWvsh5l/9InzuySCXqu4NQuTnv26jvU NE2whvRwrOCvwyhdXRhgaCwn9F1MAQgpnyX2iWY52vKcbSlnNA74+zXghrXqA6jGDM27jjoycDsTX RcPLsvLKxQNasqZbuGeQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rxPcI-00000001wHU-0Kbt; Thu, 18 Apr 2024 11:07:46 +0000 Received: from sin.source.kernel.org ([145.40.73.55]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rxPcD-00000001wGA-2ZpZ for linux-arm-kernel@lists.infradead.org; Thu, 18 Apr 2024 11:07:44 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id A0FEDCE1811; Thu, 18 Apr 2024 11:07:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 340B6C4AF08; Thu, 18 Apr 2024 11:07:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1713438459; bh=zwXcSp+gS+V/zeI7KiXiX9qGQJloCCeFDJ8XC9FCmp8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=WtBUCCudLJbry0qzPtwylXf2XGuGsS9YFZZbVBKyb4nwXE9SbJPICMdSz17v5pxpQ zHMRtYfZqNy8jVXfppLtkwfowLAiAnDXlQFRDsgFJThXqFJO5h3zoSsvYjRlEMLzAx 9LXQ6/oTWKWqsKJRc3vDNEzH4kYvhm8PMnO/2O86+TtjGbI0mDRKn1qKcM1i53BaD7 cxUXY2nD7xItggFx0zxzRcrcPku0l6YxKUng3U7W95PmU5T9CGOmmgyciRByFeKSMS 0HWc5L4ytm1JZ0cJPT3mJopkclbM0rRRltrI9Q7mBDJWZkjWVJ7tY+CxB9RRvdEunj PByS17Na8RLYg== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1rxPc8-005iIG-CB; Thu, 18 Apr 2024 12:07:36 +0100 Date: Thu, 18 Apr 2024 12:07:35 +0100 Message-ID: <86sezjq688.wl-maz@kernel.org> From: Marc Zyngier To: Catalin Marinas Cc: Naresh Kamboju , Greg Kroah-Hartman , 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 In-Reply-To: References: <20240415141953.365222063@linuxfoundation.org> <86y19dqw74.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.2 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: catalin.marinas@arm.com, naresh.kamboju@linaro.org, gregkh@linuxfoundation.org, broonie@kernel.org, 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, yihyu@redhat.com, gshan@redhat.com, ryan.roberts@arm.com, anshuman.khandual@arm.com, shahuang@redhat.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, anders.roxell@linaro.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240418_040742_040466_599F74EF X-CRM114-Status: GOOD ( 33.77 ) 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 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). The number of pages to invalidate is a 20 bit quantity, a 5 bit slice per scale. With the 6.6 approach (limit of num=30 and increasing scale), we invalidate each 5 bit slice independently. After each scale round, the corresponding slice is guaranteed to be 0. With the 6.9 method, we invalidate the maximum possible for a given scale. With a decreasing scale, we converge towards 0 or 1 on each round. With an increasing scale, this breaks spectacularly, because the strong guarantee that the remaining page count is "aligned" to 2^(5*scale+1) is not valid anymore (the low bits may not be 0). As a result, we don't converge because we never consider these low bits anymore, the page count doesn't decrease, scale goes past 3, and everything catches fire. 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. Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel