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.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,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 E1738C433E0 for ; Wed, 30 Dec 2020 11:00:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AC985221F8 for ; Wed, 30 Dec 2020 11:00:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726530AbgL3LAF (ORCPT ); Wed, 30 Dec 2020 06:00:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49404 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726318AbgL3LAE (ORCPT ); Wed, 30 Dec 2020 06:00:04 -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 E0197C061799; Wed, 30 Dec 2020 02:59:08 -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-Transfer-Encoding:Content-Type: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-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=hT6meR7oLJ3QCZauwMdEleF46LZvd7h7X5Tjnd6x4Qw=; b=Hykl2u0iY2soETjdsm8W1fkAT t1VW8LTnQe9fnmia93AoHZA8QuMrh0DEZmxjhj3gaa9mGnMbw6Lk5hoE8+k5mvta5w7BUoy3nJelO 7K0/cfgmQE4kGhWwcdp0Qva9Ckjsio9BfWpTnTHJ/zGNyBIpldEu/TtCrQShCcuqX6DCFASfZWYnS 0pwJtkDIOd4tSCPOE70uPvCOqwwNmKTVx4Judpkml4jQSMBiKFQaq7ws0zitiXiKsxB04/tSn6iKu wsTEyhYWff7TyaoR2/kpxMPSPaCXaB42Ebv+YcP2JyrmxjW3eveajDG8qnndOmc+0mRsbE3vytQMy j1mpPJKxA==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:44904) by pandora.armlinux.org.uk with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kuZBq-0005e6-5q; Wed, 30 Dec 2020 10:58:50 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1kuZBn-00028I-Qn; Wed, 30 Dec 2020 10:58:47 +0000 Date: Wed, 30 Dec 2020 10:58:47 +0000 From: Russell King - ARM Linux admin To: Nicholas Piggin Cc: linuxppc-dev , Catalin Marinas , paulmck , Arnd Bergmann , Jann Horn , Peter Zijlstra , Benjamin Herrenschmidt , x86 , linux-kernel , stable , Mathieu Desnoyers , Andy Lutomirski , Michael Ellerman , Paul Mackerras , Will Deacon , linux-arm-kernel Subject: Re: [RFC please help] membarrier: Rewrite sync_core_before_usermode() Message-ID: <20201230105847.GQ1551@shell.armlinux.org.uk> References: <20201228190852.GI1551@shell.armlinux.org.uk> <1086654515.3607.1609187556216.JavaMail.zimbra@efficios.com> <1609200902.me5niwm2t6.astroid@bobo.none> <1609210162.4d8dqilke6.astroid@bobo.none> <20201229104456.GK1551@shell.armlinux.org.uk> <1609290821.wrfh89v23a.astroid@bobo.none> <20201230100028.GP1551@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20201230100028.GP1551@shell.armlinux.org.uk> 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 Wed, Dec 30, 2020 at 10:00:28AM +0000, Russell King - ARM Linux admin wrote: > On Wed, Dec 30, 2020 at 12:33:02PM +1000, Nicholas Piggin wrote: > > Excerpts from Russell King - ARM Linux admin's message of December 29, 2020 8:44 pm: > > > On Tue, Dec 29, 2020 at 01:09:12PM +1000, Nicholas Piggin wrote: > > >> I think it should certainly be documented in terms of what guarantees > > >> it provides to application, _not_ the kinds of instructions it may or > > >> may not induce the core to execute. And if existing API can't be > > >> re-documented sanely, then deprecatd and new ones added that DTRT. > > >> Possibly under a new system call, if arch's like ARM want a range > > >> flush and we don't want to expand the multiplexing behaviour of > > >> membarrier even more (sigh). > > > > > > The 32-bit ARM sys_cacheflush() is there only to support self-modifying > > > code, and takes whatever actions are necessary to support that. > > > Exactly what actions it takes are cache implementation specific, and > > > should be of no concern to the caller, but the underlying thing is... > > > it's to support self-modifying code. > > > > Caveat > > cacheflush() should not be used in programs intended to be portable. > > On Linux, this call first appeared on the MIPS architecture, but nowa‐ > > days, Linux provides a cacheflush() system call on some other architec‐ > > tures, but with different arguments. > > > > What a disaster. Another badly designed interface, although it didn't > > originate in Linux it sounds like we weren't to be outdone so > > we messed it up even worse. > > > > flushing caches is neither necessary nor sufficient for code modification > > on many processors. Maybe some old MIPS specific private thing was fine, > > but certainly before it grew to other architectures, somebody should > > have thought for more than 2 minutes about it. Sigh. > > WARNING: You are bordering on being objectionable and offensive with > that comment. > > The ARM interface was designed by me back in the very early days of > Linux, probably while you were still in dypers, based on what was > known at the time. Back in the early 2000s, ideas such as relaxed > memory ordering were not known. All there was was one level of > harvard cache. Sorry, I got that slightly wrong. Its origins on ARM were from 12 Dec 1998: http://www.armlinux.org.uk/developer/patches/viewpatch.php?id=88/1 by Philip Blundell, and first appeared in the ARM pre-patch-2.1.131-19981214-1.gz. It was subsequently documented in the kernel sources by me in July 2001 in ARM patch-2.4.6-rmk2.gz. It has a slightly different signature: the third argument on ARM is a flags argument, whereas the MIPS code, it is some undocumented "cache" parameter. Whether the ARM version pre or post dates the MIPS code, I couldn't say. Whether it was ultimately taken from the MIPS implementation, again, I couldn't say. However, please stop insulting your fellow developers ability to think. -- 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.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,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 66786C433E0 for ; Wed, 30 Dec 2020 11:15:01 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (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 33097221FA for ; Wed, 30 Dec 2020 11:14:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 33097221FA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=armlinux.org.uk Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 4D5TG91YrbzDqJ2 for ; Wed, 30 Dec 2020 22:14:57 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=armlinux.org.uk (client-ip=2001:4d48:ad52:32c8:5054:ff:fe00:142; helo=pandora.armlinux.org.uk; envelope-from=linux+linuxppc-dev=lists.ozlabs.org@armlinux.org.uk; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=armlinux.org.uk Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; secure) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.a=rsa-sha256 header.s=pandora-2019 header.b=Hykl2u0i; dkim-atps=neutral Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [IPv6:2001:4d48:ad52:32c8:5054:ff:fe00:142]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4D5T5X2ClbzDqH6 for ; Wed, 30 Dec 2020 22:07:22 +1100 (AEDT) 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-Transfer-Encoding:Content-Type: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-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=hT6meR7oLJ3QCZauwMdEleF46LZvd7h7X5Tjnd6x4Qw=; b=Hykl2u0iY2soETjdsm8W1fkAT t1VW8LTnQe9fnmia93AoHZA8QuMrh0DEZmxjhj3gaa9mGnMbw6Lk5hoE8+k5mvta5w7BUoy3nJelO 7K0/cfgmQE4kGhWwcdp0Qva9Ckjsio9BfWpTnTHJ/zGNyBIpldEu/TtCrQShCcuqX6DCFASfZWYnS 0pwJtkDIOd4tSCPOE70uPvCOqwwNmKTVx4Judpkml4jQSMBiKFQaq7ws0zitiXiKsxB04/tSn6iKu wsTEyhYWff7TyaoR2/kpxMPSPaCXaB42Ebv+YcP2JyrmxjW3eveajDG8qnndOmc+0mRsbE3vytQMy j1mpPJKxA==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:44904) by pandora.armlinux.org.uk with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kuZBq-0005e6-5q; Wed, 30 Dec 2020 10:58:50 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1kuZBn-00028I-Qn; Wed, 30 Dec 2020 10:58:47 +0000 Date: Wed, 30 Dec 2020 10:58:47 +0000 From: Russell King - ARM Linux admin To: Nicholas Piggin Subject: Re: [RFC please help] membarrier: Rewrite sync_core_before_usermode() Message-ID: <20201230105847.GQ1551@shell.armlinux.org.uk> References: <20201228190852.GI1551@shell.armlinux.org.uk> <1086654515.3607.1609187556216.JavaMail.zimbra@efficios.com> <1609200902.me5niwm2t6.astroid@bobo.none> <1609210162.4d8dqilke6.astroid@bobo.none> <20201229104456.GK1551@shell.armlinux.org.uk> <1609290821.wrfh89v23a.astroid@bobo.none> <20201230100028.GP1551@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20201230100028.GP1551@shell.armlinux.org.uk> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: paulmck , Arnd Bergmann , Jann Horn , Peter Zijlstra , Catalin Marinas , x86 , linux-kernel , stable , Will Deacon , Mathieu Desnoyers , Andy Lutomirski , Paul Mackerras , linuxppc-dev , linux-arm-kernel Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Wed, Dec 30, 2020 at 10:00:28AM +0000, Russell King - ARM Linux admin wrote: > On Wed, Dec 30, 2020 at 12:33:02PM +1000, Nicholas Piggin wrote: > > Excerpts from Russell King - ARM Linux admin's message of December 29, 2020 8:44 pm: > > > On Tue, Dec 29, 2020 at 01:09:12PM +1000, Nicholas Piggin wrote: > > >> I think it should certainly be documented in terms of what guarantees > > >> it provides to application, _not_ the kinds of instructions it may or > > >> may not induce the core to execute. And if existing API can't be > > >> re-documented sanely, then deprecatd and new ones added that DTRT. > > >> Possibly under a new system call, if arch's like ARM want a range > > >> flush and we don't want to expand the multiplexing behaviour of > > >> membarrier even more (sigh). > > > > > > The 32-bit ARM sys_cacheflush() is there only to support self-modifying > > > code, and takes whatever actions are necessary to support that. > > > Exactly what actions it takes are cache implementation specific, and > > > should be of no concern to the caller, but the underlying thing is... > > > it's to support self-modifying code. > > > > Caveat > > cacheflush() should not be used in programs intended to be portable. > > On Linux, this call first appeared on the MIPS architecture, but nowa‐ > > days, Linux provides a cacheflush() system call on some other architec‐ > > tures, but with different arguments. > > > > What a disaster. Another badly designed interface, although it didn't > > originate in Linux it sounds like we weren't to be outdone so > > we messed it up even worse. > > > > flushing caches is neither necessary nor sufficient for code modification > > on many processors. Maybe some old MIPS specific private thing was fine, > > but certainly before it grew to other architectures, somebody should > > have thought for more than 2 minutes about it. Sigh. > > WARNING: You are bordering on being objectionable and offensive with > that comment. > > The ARM interface was designed by me back in the very early days of > Linux, probably while you were still in dypers, based on what was > known at the time. Back in the early 2000s, ideas such as relaxed > memory ordering were not known. All there was was one level of > harvard cache. Sorry, I got that slightly wrong. Its origins on ARM were from 12 Dec 1998: http://www.armlinux.org.uk/developer/patches/viewpatch.php?id=88/1 by Philip Blundell, and first appeared in the ARM pre-patch-2.1.131-19981214-1.gz. It was subsequently documented in the kernel sources by me in July 2001 in ARM patch-2.4.6-rmk2.gz. It has a slightly different signature: the third argument on ARM is a flags argument, whereas the MIPS code, it is some undocumented "cache" parameter. Whether the ARM version pre or post dates the MIPS code, I couldn't say. Whether it was ultimately taken from the MIPS implementation, again, I couldn't say. However, please stop insulting your fellow developers ability to think. -- 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.3 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,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 E2CF4C433DB for ; Wed, 30 Dec 2020 11:01:04 +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 9D4612220B for ; Wed, 30 Dec 2020 11:01:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9D4612220B 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=jUDpyeb75XMdgbWA3Mfew2iQlfVW18Df2/ES2ppFU6E=; b=myJsIawSZqPkj0kzkWpcwch2/ UnqhIoatUV5l3Kym7SLgkdQiYA7weRFV/Alo6UpiaSNXzHw1PeiV4XFkIC4AvEqfFCF5LPf5XRWZg be9InicA1FIA+FPFN5Q9Q+yP0ffyFGvP+c3h0PQ7F44lLkaQSHrBeVFL24JNqUPFM2FsngpOobFRN WRylX7PzJORGrOEJV7qPmtajC0jp7AWWJ8Gb0SOHlus09BhnYPX1jp8DaeJ7hEmTMfI/vEGmkyhf8 zjtD8gHtfuQ/oKdbL9bxWbagV3UouyUgvplvoPcQbfXztwZ7T4TzKah3mgM48NMAHxPeBylCYEEil lHw5Pweaw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kuZCR-0001KN-54; Wed, 30 Dec 2020 10:59:27 +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 1kuZCN-0001K4-N4 for linux-arm-kernel@lists.infradead.org; Wed, 30 Dec 2020 10:59:25 +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-Transfer-Encoding:Content-Type: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-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=hT6meR7oLJ3QCZauwMdEleF46LZvd7h7X5Tjnd6x4Qw=; b=Hykl2u0iY2soETjdsm8W1fkAT t1VW8LTnQe9fnmia93AoHZA8QuMrh0DEZmxjhj3gaa9mGnMbw6Lk5hoE8+k5mvta5w7BUoy3nJelO 7K0/cfgmQE4kGhWwcdp0Qva9Ckjsio9BfWpTnTHJ/zGNyBIpldEu/TtCrQShCcuqX6DCFASfZWYnS 0pwJtkDIOd4tSCPOE70uPvCOqwwNmKTVx4Judpkml4jQSMBiKFQaq7ws0zitiXiKsxB04/tSn6iKu wsTEyhYWff7TyaoR2/kpxMPSPaCXaB42Ebv+YcP2JyrmxjW3eveajDG8qnndOmc+0mRsbE3vytQMy j1mpPJKxA==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:44904) by pandora.armlinux.org.uk with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kuZBq-0005e6-5q; Wed, 30 Dec 2020 10:58:50 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1kuZBn-00028I-Qn; Wed, 30 Dec 2020 10:58:47 +0000 Date: Wed, 30 Dec 2020 10:58:47 +0000 From: Russell King - ARM Linux admin To: Nicholas Piggin Subject: Re: [RFC please help] membarrier: Rewrite sync_core_before_usermode() Message-ID: <20201230105847.GQ1551@shell.armlinux.org.uk> References: <20201228190852.GI1551@shell.armlinux.org.uk> <1086654515.3607.1609187556216.JavaMail.zimbra@efficios.com> <1609200902.me5niwm2t6.astroid@bobo.none> <1609210162.4d8dqilke6.astroid@bobo.none> <20201229104456.GK1551@shell.armlinux.org.uk> <1609290821.wrfh89v23a.astroid@bobo.none> <20201230100028.GP1551@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201230100028.GP1551@shell.armlinux.org.uk> 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-20201230_055923_772720_1E6AB2DF X-CRM114-Status: GOOD ( 29.20 ) 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: paulmck , Arnd Bergmann , Jann Horn , Peter Zijlstra , Catalin Marinas , x86 , linux-kernel , stable , Will Deacon , Mathieu Desnoyers , Michael Ellerman , Andy Lutomirski , Benjamin Herrenschmidt , Paul Mackerras , linuxppc-dev , linux-arm-kernel Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org T24gV2VkLCBEZWMgMzAsIDIwMjAgYXQgMTA6MDA6MjhBTSArMDAwMCwgUnVzc2VsbCBLaW5nIC0g QVJNIExpbnV4IGFkbWluIHdyb3RlOgo+IE9uIFdlZCwgRGVjIDMwLCAyMDIwIGF0IDEyOjMzOjAy UE0gKzEwMDAsIE5pY2hvbGFzIFBpZ2dpbiB3cm90ZToKPiA+IEV4Y2VycHRzIGZyb20gUnVzc2Vs bCBLaW5nIC0gQVJNIExpbnV4IGFkbWluJ3MgbWVzc2FnZSBvZiBEZWNlbWJlciAyOSwgMjAyMCA4 OjQ0IHBtOgo+ID4gPiBPbiBUdWUsIERlYyAyOSwgMjAyMCBhdCAwMTowOToxMlBNICsxMDAwLCBO aWNob2xhcyBQaWdnaW4gd3JvdGU6Cj4gPiA+PiBJIHRoaW5rIGl0IHNob3VsZCBjZXJ0YWlubHkg YmUgZG9jdW1lbnRlZCBpbiB0ZXJtcyBvZiB3aGF0IGd1YXJhbnRlZXMKPiA+ID4+IGl0IHByb3Zp ZGVzIHRvIGFwcGxpY2F0aW9uLCBfbm90XyB0aGUga2luZHMgb2YgaW5zdHJ1Y3Rpb25zIGl0IG1h eSBvcgo+ID4gPj4gbWF5IG5vdCBpbmR1Y2UgdGhlIGNvcmUgdG8gZXhlY3V0ZS4gQW5kIGlmIGV4 aXN0aW5nIEFQSSBjYW4ndCBiZQo+ID4gPj4gcmUtZG9jdW1lbnRlZCBzYW5lbHksIHRoZW4gZGVw cmVjYXRkIGFuZCBuZXcgb25lcyBhZGRlZCB0aGF0IERUUlQuCj4gPiA+PiBQb3NzaWJseSB1bmRl ciBhIG5ldyBzeXN0ZW0gY2FsbCwgaWYgYXJjaCdzIGxpa2UgQVJNIHdhbnQgYSByYW5nZQo+ID4g Pj4gZmx1c2ggYW5kIHdlIGRvbid0IHdhbnQgdG8gZXhwYW5kIHRoZSBtdWx0aXBsZXhpbmcgYmVo YXZpb3VyIG9mCj4gPiA+PiBtZW1iYXJyaWVyIGV2ZW4gbW9yZSAoc2lnaCkuCj4gPiA+IAo+ID4g PiBUaGUgMzItYml0IEFSTSBzeXNfY2FjaGVmbHVzaCgpIGlzIHRoZXJlIG9ubHkgdG8gc3VwcG9y dCBzZWxmLW1vZGlmeWluZwo+ID4gPiBjb2RlLCBhbmQgdGFrZXMgd2hhdGV2ZXIgYWN0aW9ucyBh cmUgbmVjZXNzYXJ5IHRvIHN1cHBvcnQgdGhhdC4KPiA+ID4gRXhhY3RseSB3aGF0IGFjdGlvbnMg aXQgdGFrZXMgYXJlIGNhY2hlIGltcGxlbWVudGF0aW9uIHNwZWNpZmljLCBhbmQKPiA+ID4gc2hv dWxkIGJlIG9mIG5vIGNvbmNlcm4gdG8gdGhlIGNhbGxlciwgYnV0IHRoZSB1bmRlcmx5aW5nIHRo aW5nIGlzLi4uCj4gPiA+IGl0J3MgdG8gc3VwcG9ydCBzZWxmLW1vZGlmeWluZyBjb2RlLgo+ID4g Cj4gPiAgICBDYXZlYXQKPiA+ICAgICAgICBjYWNoZWZsdXNoKCkgIHNob3VsZCAgbm90ICBiZSB1 c2VkIGluIHByb2dyYW1zIGludGVuZGVkIHRvIGJlIHBvcnRhYmxlLgo+ID4gICAgICAgIE9uIExp bnV4LCB0aGlzIGNhbGwgZmlyc3QgYXBwZWFyZWQgb24gdGhlIE1JUFMgYXJjaGl0ZWN0dXJlLCBi dXQgIG5vd2HigJAKPiA+ICAgICAgICBkYXlzLCBMaW51eCBwcm92aWRlcyBhIGNhY2hlZmx1c2go KSBzeXN0ZW0gY2FsbCBvbiBzb21lIG90aGVyIGFyY2hpdGVj4oCQCj4gPiAgICAgICAgdHVyZXMs IGJ1dCB3aXRoIGRpZmZlcmVudCBhcmd1bWVudHMuCj4gPiAKPiA+IFdoYXQgYSBkaXNhc3Rlci4g QW5vdGhlciBiYWRseSBkZXNpZ25lZCBpbnRlcmZhY2UsIGFsdGhvdWdoIGl0IGRpZG4ndCAKPiA+ IG9yaWdpbmF0ZSBpbiBMaW51eCBpdCBzb3VuZHMgbGlrZSB3ZSB3ZXJlbid0IHRvIGJlIG91dGRv bmUgc28KPiA+IHdlIG1lc3NlZCBpdCB1cCBldmVuIHdvcnNlLgo+ID4gCj4gPiBmbHVzaGluZyBj YWNoZXMgaXMgbmVpdGhlciBuZWNlc3Nhcnkgbm9yIHN1ZmZpY2llbnQgZm9yIGNvZGUgbW9kaWZp Y2F0aW9uCj4gPiBvbiBtYW55IHByb2Nlc3NvcnMuIE1heWJlIHNvbWUgb2xkIE1JUFMgc3BlY2lm aWMgcHJpdmF0ZSB0aGluZyB3YXMgZmluZSwKPiA+IGJ1dCBjZXJ0YWlubHkgYmVmb3JlIGl0IGdy ZXcgdG8gb3RoZXIgYXJjaGl0ZWN0dXJlcywgc29tZWJvZHkgc2hvdWxkIAo+ID4gaGF2ZSB0aG91 Z2h0IGZvciBtb3JlIHRoYW4gMiBtaW51dGVzIGFib3V0IGl0LiBTaWdoLgo+IAo+IFdBUk5JTkc6 IFlvdSBhcmUgYm9yZGVyaW5nIG9uIGJlaW5nIG9iamVjdGlvbmFibGUgYW5kIG9mZmVuc2l2ZSB3 aXRoCj4gdGhhdCBjb21tZW50Lgo+IAo+IFRoZSBBUk0gaW50ZXJmYWNlIHdhcyBkZXNpZ25lZCBi eSBtZSBiYWNrIGluIHRoZSB2ZXJ5IGVhcmx5IGRheXMgb2YKPiBMaW51eCwgcHJvYmFibHkgd2hp bGUgeW91IHdlcmUgc3RpbGwgaW4gZHlwZXJzLCBiYXNlZCBvbiB3aGF0IHdhcwo+IGtub3duIGF0 IHRoZSB0aW1lLiAgQmFjayBpbiB0aGUgZWFybHkgMjAwMHMsIGlkZWFzIHN1Y2ggYXMgcmVsYXhl ZAo+IG1lbW9yeSBvcmRlcmluZyB3ZXJlIG5vdCBrbm93bi4gIEFsbCB0aGVyZSB3YXMgd2FzIG9u ZSBsZXZlbCBvZgo+IGhhcnZhcmQgY2FjaGUuCgpTb3JyeSwgSSBnb3QgdGhhdCBzbGlnaHRseSB3 cm9uZy4gSXRzIG9yaWdpbnMgb24gQVJNIHdlcmUgZnJvbSAxMiBEZWMKMTk5ODoKCmh0dHA6Ly93 d3cuYXJtbGludXgub3JnLnVrL2RldmVsb3Blci9wYXRjaGVzL3ZpZXdwYXRjaC5waHA/aWQ9ODgv MQoKYnkgUGhpbGlwIEJsdW5kZWxsLCBhbmQgZmlyc3QgYXBwZWFyZWQgaW4gdGhlIEFSTQpwcmUt cGF0Y2gtMi4xLjEzMS0xOTk4MTIxNC0xLmd6LiBJdCB3YXMgc3Vic2VxdWVudGx5IGRvY3VtZW50 ZWQgaW4gdGhlCmtlcm5lbCBzb3VyY2VzIGJ5IG1lIGluIEp1bHkgMjAwMSBpbiBBUk0gcGF0Y2gt Mi40LjYtcm1rMi5nei4gSXQgaGFzCmEgc2xpZ2h0bHkgZGlmZmVyZW50IHNpZ25hdHVyZTogdGhl IHRoaXJkIGFyZ3VtZW50IG9uIEFSTSBpcyBhIGZsYWdzCmFyZ3VtZW50LCB3aGVyZWFzIHRoZSBN SVBTIGNvZGUsIGl0IGlzIHNvbWUgdW5kb2N1bWVudGVkICJjYWNoZSIKcGFyYW1ldGVyLgoKV2hl dGhlciB0aGUgQVJNIHZlcnNpb24gcHJlIG9yIHBvc3QgZGF0ZXMgdGhlIE1JUFMgY29kZSwgSSBj b3VsZG4ndCBzYXkuCldoZXRoZXIgaXQgd2FzIHVsdGltYXRlbHkgdGFrZW4gZnJvbSB0aGUgTUlQ UyBpbXBsZW1lbnRhdGlvbiwgYWdhaW4sIEkKY291bGRuJ3Qgc2F5LgoKSG93ZXZlciwgcGxlYXNl IHN0b3AgaW5zdWx0aW5nIHlvdXIgZmVsbG93IGRldmVsb3BlcnMgYWJpbGl0eSB0byB0aGluay4K Ci0tIApSTUsncyBQYXRjaCBzeXN0ZW06IGh0dHBzOi8vd3d3LmFybWxpbnV4Lm9yZy51ay9kZXZl bG9wZXIvcGF0Y2hlcy8KRlRUUCBpcyBoZXJlISA0ME1icHMgZG93biAxME1icHMgdXAuIERlY2Vu dCBjb25uZWN0aXZpdHkgYXQgbGFzdCEKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCmxpbnV4LWFybS1rZXJuZWwgbWFpbGluZyBsaXN0CmxpbnV4LWFybS1r ZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWls bWFuL2xpc3RpbmZvL2xpbnV4LWFybS1rZXJuZWwK