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 X-Spam-Level: X-Spam-Status: No, score=-5.0 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B6F36C433DB for ; Thu, 4 Feb 2021 14:39:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 841E164F4D for ; Thu, 4 Feb 2021 14:39:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236802AbhBDOio (ORCPT ); Thu, 4 Feb 2021 09:38:44 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55706 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236814AbhBDOhI (ORCPT ); Thu, 4 Feb 2021 09:37:08 -0500 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [IPv6:2001:4d48:ad52:32c8:5054:ff:fe00:142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 61AD7C061788 for ; Thu, 4 Feb 2021 06:36:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=dIUX1UJ9YE8lpmLnWwpq590HsZ3ByZbducXK2xflJPo=; b=DFmzaMfMbNUxXMVfJoBXvnYA8 zx+VDWMGRqNLZ00I0o3iGn1gszJLI/MKXQcsFIuJWYwMp+UURWWjxjogzu9Xd6jswfTZiMFoYtx+x HwEvrvlpk2i5N1qP7pEjK100u28wf6ILGcLd8CmsoXEMlGc+TJsPT+zs8SJ9MtkbC8TawmDOMeNHi IciPNoLXDNBGlg+r90Hhjd9I6WX6zBNASV/IrWjgYNi/3Tdyf85QEnPA6v8gHDxQuNLdzEITc5ROT NGN7XVyo0x6P9DsNLwBAJEk4R1xmie0cu+buRF05aPFPgU+MR5FvzLmlOof7o17lj+7b+C+ESF0p2 sKAvTfUrQ==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:39118) by pandora.armlinux.org.uk with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l7fk3-0006eK-Hy; Thu, 04 Feb 2021 14:36:19 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1l7fk2-0005Ej-Cd; Thu, 04 Feb 2021 14:36:18 +0000 Date: Thu, 4 Feb 2021 14:36:18 +0000 From: Russell King - ARM Linux admin To: Ard Biesheuvel Cc: Marc Zyngier , Guillaume Tucker , Geert Uytterhoeven , Linux Kernel Mailing List , Linus Walleij , Linux ARM , Nicolas Pitre , kernelci-results@groups.io Subject: Re: next/master bisection: baseline.login on rk3288-rock2-square Message-ID: <20210204143618.GY1463@shell.armlinux.org.uk> References: <601b773a.1c69fb81.9f381.a32a@mx.google.com> <6c65bcef-d4e7-25fa-43cf-2c435bb61bb9@collabora.com> <20210204100601.GT1463@shell.armlinux.org.uk> <20210204104714.GU1463@shell.armlinux.org.uk> <090003e6f825de1f8460c0e987e14577@kernel.org> <20210204140911.GX1463@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: Russell King - ARM Linux admin Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 04, 2021 at 03:25:20PM +0100, Ard Biesheuvel wrote: > Pushing contents of the cache hierarchy to main memory is *not* a > valid use of set/way ops, and so there is no point in pretending that > set/way ops will produce the same results as by-VA ops. Only the by-VA > ops give the architectural guarantees that we rely on for correctness. ... yet we /were/ doing that, and it worked fine for 13 years - from 1st June 2007 until the by-VA merge into mainline on the 3rd April 2020. You may be right that it wasn't the most correct way, but it worked for those 13 years without issue, and it's only recently that it's become a problem, and trying to "fix" that introduced a regression, and fixing that regression has caused another regression... and I what I'm wondering is how many more regression fixing cycles it's going to take - how many regression fixes on top of other regression fixes are we going to end up seeing here. The fact is, we never properly understood why your patch caused the regression I was seeing. If we don't understand it, then we can never say that we've fixed the problem properly. That is highlighted by the fact that fixing the regression I was seeing has caused another regression. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! 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 X-Spam-Level: X-Spam-Status: No, score=-5.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 23BCEC433DB for ; Thu, 4 Feb 2021 14:40:33 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E064A64DDD for ; Thu, 4 Feb 2021 14:40:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E064A64DDD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=armlinux.org.uk Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject: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=Z1tbNjwmUZbXv4Tp5CecXp39EYTQEmtLJqvcejXKPSM=; b=bDLbU+5oODk+J9eaowBhVonLh BoeRm9fCPcIfqmGPbjSYmoyVZFprN33ZhWPHYH71yyKIZP2MCX/kU5qQ50qJhRKsBLvijdcBgonAX QjPKcOcXXhk5T3osWj9K/0+KRB6YGs4Pj7GnIHwfh5Z+sfQEPt5KqEAjpY5zsNGSszK8jn5cPNRef jx2K372d4/vuUJboDJu6qoKnKvAb0zZVD9jzwuJwrTWzOiZS1iYmd7Zfz2ifdv0ebIwCEUsz2uxYa WWCHY4OTbd8RrR0KLG6+ocEDwEfjjLr7HfHcGkit9vpk5AROy2aeQaywbeucnVxg9DoKi+sgSG78F 0LN87qqiw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l7fn7-00041h-Ap; Thu, 04 Feb 2021 14:39:29 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:32c8:5054:ff:fe00:142]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l7fn4-0003cM-Gr for linux-arm-kernel@lists.infradead.org; Thu, 04 Feb 2021 14:39:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=dIUX1UJ9YE8lpmLnWwpq590HsZ3ByZbducXK2xflJPo=; b=DFmzaMfMbNUxXMVfJoBXvnYA8 zx+VDWMGRqNLZ00I0o3iGn1gszJLI/MKXQcsFIuJWYwMp+UURWWjxjogzu9Xd6jswfTZiMFoYtx+x HwEvrvlpk2i5N1qP7pEjK100u28wf6ILGcLd8CmsoXEMlGc+TJsPT+zs8SJ9MtkbC8TawmDOMeNHi IciPNoLXDNBGlg+r90Hhjd9I6WX6zBNASV/IrWjgYNi/3Tdyf85QEnPA6v8gHDxQuNLdzEITc5ROT NGN7XVyo0x6P9DsNLwBAJEk4R1xmie0cu+buRF05aPFPgU+MR5FvzLmlOof7o17lj+7b+C+ESF0p2 sKAvTfUrQ==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:39118) by pandora.armlinux.org.uk with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l7fk3-0006eK-Hy; Thu, 04 Feb 2021 14:36:19 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1l7fk2-0005Ej-Cd; Thu, 04 Feb 2021 14:36:18 +0000 Date: Thu, 4 Feb 2021 14:36:18 +0000 From: Russell King - ARM Linux admin To: Ard Biesheuvel Subject: Re: next/master bisection: baseline.login on rk3288-rock2-square Message-ID: <20210204143618.GY1463@shell.armlinux.org.uk> References: <601b773a.1c69fb81.9f381.a32a@mx.google.com> <6c65bcef-d4e7-25fa-43cf-2c435bb61bb9@collabora.com> <20210204100601.GT1463@shell.armlinux.org.uk> <20210204104714.GU1463@shell.armlinux.org.uk> <090003e6f825de1f8460c0e987e14577@kernel.org> <20210204140911.GX1463@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210204_093926_576518_D742283E X-CRM114-Status: GOOD ( 13.13 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kernelci-results@groups.io, Geert Uytterhoeven , Nicolas Pitre , Marc Zyngier , Linus Walleij , Linux Kernel Mailing List , Guillaume Tucker , Linux ARM 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, Feb 04, 2021 at 03:25:20PM +0100, Ard Biesheuvel wrote: > Pushing contents of the cache hierarchy to main memory is *not* a > valid use of set/way ops, and so there is no point in pretending that > set/way ops will produce the same results as by-VA ops. Only the by-VA > ops give the architectural guarantees that we rely on for correctness. ... yet we /were/ doing that, and it worked fine for 13 years - from 1st June 2007 until the by-VA merge into mainline on the 3rd April 2020. You may be right that it wasn't the most correct way, but it worked for those 13 years without issue, and it's only recently that it's become a problem, and trying to "fix" that introduced a regression, and fixing that regression has caused another regression... and I what I'm wondering is how many more regression fixing cycles it's going to take - how many regression fixes on top of other regression fixes are we going to end up seeing here. The fact is, we never properly understood why your patch caused the regression I was seeing. If we don't understand it, then we can never say that we've fixed the problem properly. That is highlighted by the fact that fixing the regression I was seeing has caused another regression. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel