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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 32154C433FE for ; Tue, 2 Nov 2021 08:33:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0EAA360F70 for ; Tue, 2 Nov 2021 08:33:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231136AbhKBIgV (ORCPT ); Tue, 2 Nov 2021 04:36:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45656 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229505AbhKBIgU (ORCPT ); Tue, 2 Nov 2021 04:36:20 -0400 Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 45036C061714; Tue, 2 Nov 2021 01:33:45 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id y26so41323781lfa.11; Tue, 02 Nov 2021 01:33:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IIbhqQ166KuY0HqjYi0SoZGpqG4hrHANtgC7gv/B4qE=; b=a2lkPtso9VSJtQKipU7sC99tkqQ0OotHLpbbtKDRwXJ8/FlMphMARe+W9ZykQ/EqH3 pvHw8SUBCv4OHNMaZVPzKzPC1o59GSm1kNgEgRnoZV+H4KScYM5uYgItIxW12WAHI3mF 76EUwcmQ50N7NyszRdSFLb/4FdJBYl1DLc5O9iibxGx4627nOnM82de4WQxiWoEZjCz7 Q6QOgt9k9XgpfbhM6zjqUws8v2TnrQ/I0gEL96L8OMKt0+l8pMu/SEAvy0+Bp9pLB6bq U+pn1YjezcL0s09Ly4pL2H+UCIO5Edh1xlgoIN/+p+gopy66ZJkjKhLBIQgya9apGjAs w5/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IIbhqQ166KuY0HqjYi0SoZGpqG4hrHANtgC7gv/B4qE=; b=DtbE6Zu9r7ju6qRMn8aIo3g21Noptp0LxkBh5CUxTJu/xBt/ncf4UiQJtESDwEUZzg H8j4yEblL3VPLSi4wUzTYIwIyTv+Ae8/4hwv6SZfuWy3izx6ZE6sz7NrG3rJZhpi5cqQ oyOouCWtDedrXe+WrianF+ra6kfsBrdkAhJM02S1mSJTwIsOKG/aPZpu1OCJNk3WBN4w xmQyw+jxA34BUe6fQXQXZ/yhnn+/WS/1ZA3dj3an/RjYUnUUkpzO/dum6yY+S2yr4Oaq LYl/982vqXye3v+nxH1uY3VzhJFCsmJClj2NgsxVH7qDbRwvBr/ln7S/Y2qa5V4/sZRs J4aw== X-Gm-Message-State: AOAM533/DwEYQdy1/pgUwHS5bIirsjEC65l0RW6vwonP5pykw1ZjZIMc OFd+bEDEDLz2bbRcImzBXABfmzBrkS3rGGZvSQ== X-Google-Smtp-Source: ABdhPJzY1QYptzKxQ2dc9ZaB2dqJyb92U1gZE8xwtirNR1GtQGV0LjhT3+DOv5Tfb+KU1f7uH+LfjPc1eXAx/krB22A= X-Received: by 2002:a05:6512:3c9e:: with SMTP id h30mr2145698lfv.93.1635842023510; Tue, 02 Nov 2021 01:33:43 -0700 (PDT) MIME-Version: 1.0 References: <20211028141938.3530-1-lukas.bulwahn@gmail.com> <20211028141938.3530-12-lukas.bulwahn@gmail.com> In-Reply-To: From: Avi Fishman Date: Tue, 2 Nov 2021 10:33:32 +0200 Message-ID: Subject: Re: [PATCH 11/13] arm: npcm: drop selecting non-existing ARM_ERRATA_794072 To: Lukas Bulwahn Cc: Joel Stanley , Arnd Bergmann , Tomer Maimon , Russell King , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Sekhar Nori , Bartosz Golaszewski , Linus Walleij , Imre Kaloz , Krzysztof Halasa , Tali Perry , Patrick Venture , Nancy Yuen , Benjamin Fair , Dinh Nguyen , Linux ARM , OpenBMC Maillist , kernel-janitors , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 2, 2021 at 10:22 AM Avi Fishman wrote: > > Hi, > > At Nuvoton we implied this WA in the past, not because we encountered > a specific problem but since the errata says so and we saw this in > other patches like: > https://patchwork.kernel.org/project/linux-arm-kernel/patch/1396298072-13254-2-git-send-email-nitin.garg@freescale.com/ > But we didn't upstream the arch/arm/mm/proc-v7.S > > From the errata document. > "794072 A short loop including a DMB instruction might cause a denial > of service on > another processor which executes a CP15 broadcast operation > Status > Affects: > Fault Type: > Fault Status: Cortex-A9 MPCore. > Programmer Category B > Present in: All r1, r2, r3 and r4 revisions Open > Description > A processor which continuously executes a short loop containing a DMB > instruction might prevent a CP15 > operation broadcast by another processor making further progress, > causing a denial of service. > Configurations affected > This erratum affects all Cortex-A9 MPCore processors with two or more > processors. > Conditions > The erratum requires the following conditions: > - Two or more processors are working in SMP mode (ACTLR.SMP=1) > - One of the processors continuously executes a short loop containing > at least one DMB instruction. > - Another processor executes a CP15 maintenance operation that is > broadcast. This requires that this > processor has enabled the broadcasting of CP15 operations (ACTLR.FW=1) > For the erratum to occur, the short loop containing the DMB > instruction must meet all of the following additional > conditions: > - No more than 10 instructions other than the DMB are executed between each DMB > - No non-conditional Load or Store, or conditional Load or Store which > pass the condition code check, are > executed between each DMB > When all the conditions for the erratum are met, the short loop > creates a continuous stream of DMB instructions. > This might cause a denial of service, by preventing the processor > executing the short loop from executing the > received broadcast CP15 operation. As a result, the processor that > originally executed the broadcast CP15 > operation is stalled until the execution of the loop is interrupted. > Note that because the process issuing the CP15 broadcast operation > cannot complete operation, it cannot enter > any debug-mode, and cannot take any interrupt. If the processor > executing the short loop also cannot be > interrupted, for example if it has disabled its interrupts, or if no > interrupts are routed to this processor, this > erratum might cause a system livelock. > Implications > The erratum might create performance issues, or in the worst case it > might cause a system livelock if the > processor executing the DMB is in an infinite loop that cannot be interrupted. > Workaround > This erratum can be worked round by setting bit[4] of the undocumented > Diagnostic Control Register to 1. This > register is encoded as CP15 c15 0 c0 1. > This bit can be written in Secure state only, with the following > Read/Modify/Write code sequence: > MRC p15,0,rt,c15,c0,1 > ORR rt,rt,#0x10 > MCR p15,0,rt,c15,c0,1 > When it is set, this bit causes the DMB instruction to be decoded and > executed like a DSB. > Using this software workaround is not expected to have any impact on > the overall performance of the processor > on a typical code base. > Other workarounds are also available for this erratum, to either > prevent or interrupt the continuous stream of > DMB instructions that causes the deadlock. For example: > - Inserting a non-conditional Load or Store instruction in the loop > between each DMB > - Inserting additional instructions in the loop, such as NOPs, to > avoid the processor seeing back to back > DMB instructions. > - Making the processor executing the short loop take regular interrupts." > > Avi > > On Tue, Nov 2, 2021 at 9:31 AM Lukas Bulwahn wrote: > > > > On Fri, Oct 29, 2021 at 8:36 AM Joel Stanley wrote: > > > > > > On Thu, 28 Oct 2021 at 14:57, Arnd Bergmann wrote: > > > > > > > > On Thu, Oct 28, 2021 at 4:19 PM Lukas Bulwahn wrote: > > > > > > > > > > There is no and never was a Kconfig for ARM_ERRATA_794072 in the kernel > > > > > tree. So, there is no need to select ARM_ERRATA_794072 in > > > > > ./arch/arm/mach-npcm/Kconfig. > > > > > > > > > > Simply drop selecting the non-existing ARM_ERRATA_794072. > > > > > > > > > > This issue was discovered with ./scripts/checkkconfigsymbols.py. > > > > > > > > > > Signed-off-by: Lukas Bulwahn > > > > > --- > > > > > > > > Could this be a typo? Maybe we need to enable a different errata workaround > > > > here, or maybe that code is actually needed and has to get sent. > > > > > > Doing some searching, u-boot had a workaround for something called > > > ARM_ERRATA_794072. > > > > > > https://github.com/u-boot/u-boot/commit/f71cbfe3ca5d2ad20159871700e8e248c8818ba8 > > > > > > Lore has the review history for that patch: > > > > > > https://lore.kernel.org/all/6be32e0b5b454ed7b609317266a8e798@BLUPR03MB358.namprd03.prod.outlook.com/ > > > > > > It looks like it's the same workaround as ARM_ERRATA_742230, which the > > > kernel does implement. > > > > > > It would be good to hear from the Nuvoton people, or an Arm person. > > > > > > > I will happily update the patch to select ARM_ERRATA_742230 instead of > > the dead non-existing ARM_ERRATA_794072. > > > > In contrast to the current patch that basically only cleans up "dead > > config" and has no effective functional change, the new patch would > > change the behaviour. I cannot test this patch (beyond some basic > > compile test) on the hardware; so, we certainly need someone to have > > that hardware, knows how to test it or confirm otherwise that we > > should select the ARM_ERRATA_742230 fix for this hardware. Note that ARM_ERRATA_742230 is applied in code up-to CORTEX-A9 r2p2 but while ARM_ERRATA_794072 exist also in CORTEX-A9 r4p1 https://github.com/torvalds/linux/blob/322a3b843d7f475b857646ed8f95b40431d3ecd0/arch/arm/mm/proc-v7.S#L347 > > > > The current patch should be subsumed by the new patch; the submission > > of the new patch is deferred until that person shows up. Let's see. > > > > Lukas > > > > -- > Regards, > Avi -- Regards, Avi 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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E025AC433F5 for ; Tue, 2 Nov 2021 08:34:31 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (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 5DFCD60E98 for ; Tue, 2 Nov 2021 08:34:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 5DFCD60E98 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.ozlabs.org Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4Hk39K48dNz2yJM for ; Tue, 2 Nov 2021 19:34:29 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=a2lkPtso; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gmail.com (client-ip=2a00:1450:4864:20::134; helo=mail-lf1-x134.google.com; envelope-from=avifishman70@gmail.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=a2lkPtso; dkim-atps=neutral Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4Hk38Z1Lj0z2xD8 for ; Tue, 2 Nov 2021 19:33:48 +1100 (AEDT) Received: by mail-lf1-x134.google.com with SMTP id d21so1851053lfg.7 for ; Tue, 02 Nov 2021 01:33:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IIbhqQ166KuY0HqjYi0SoZGpqG4hrHANtgC7gv/B4qE=; b=a2lkPtso9VSJtQKipU7sC99tkqQ0OotHLpbbtKDRwXJ8/FlMphMARe+W9ZykQ/EqH3 pvHw8SUBCv4OHNMaZVPzKzPC1o59GSm1kNgEgRnoZV+H4KScYM5uYgItIxW12WAHI3mF 76EUwcmQ50N7NyszRdSFLb/4FdJBYl1DLc5O9iibxGx4627nOnM82de4WQxiWoEZjCz7 Q6QOgt9k9XgpfbhM6zjqUws8v2TnrQ/I0gEL96L8OMKt0+l8pMu/SEAvy0+Bp9pLB6bq U+pn1YjezcL0s09Ly4pL2H+UCIO5Edh1xlgoIN/+p+gopy66ZJkjKhLBIQgya9apGjAs w5/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IIbhqQ166KuY0HqjYi0SoZGpqG4hrHANtgC7gv/B4qE=; b=2Uv5tBz8oEswc1RgmYIwtWD70pjSfTGckKCHrYNor3jVlqhTJNTUhcislgs0Un29ms tHrEO2XEFLg9vF28usvAsEEdn1aMcoT67AAuD/NZjDZK6TlkwBp4Z2lEK5OWlqpfDuiB a1SDjrGswjAjeRFiSl3wjbEzg4PJR/N7SwP65VNl1OtM0+lxkoAIRO0+e3swbiZxrJJp nNtMArt59PzruDg2AB98seXzZbjUWUuAFE3mPEo6tVQ6n0Q8LyCev9Ct4LXpkUyPZdlf kkm6Kdi7hKaYn6i8JV1pfF4+evDsVx0YL4nJ7ozjhb7JCM090icT8nkE08tbcQUoRVDL wvoQ== X-Gm-Message-State: AOAM531pXBmdA6sK9vFvpvsYKV8q1oikkj0B0fQLCZPiVROs/16WxqAK oCdsDSilmnAYrA0JUz25nPa+qpGXSGwh/k6Siw== X-Google-Smtp-Source: ABdhPJzY1QYptzKxQ2dc9ZaB2dqJyb92U1gZE8xwtirNR1GtQGV0LjhT3+DOv5Tfb+KU1f7uH+LfjPc1eXAx/krB22A= X-Received: by 2002:a05:6512:3c9e:: with SMTP id h30mr2145698lfv.93.1635842023510; Tue, 02 Nov 2021 01:33:43 -0700 (PDT) MIME-Version: 1.0 References: <20211028141938.3530-1-lukas.bulwahn@gmail.com> <20211028141938.3530-12-lukas.bulwahn@gmail.com> In-Reply-To: From: Avi Fishman Date: Tue, 2 Nov 2021 10:33:32 +0200 Message-ID: Subject: Re: [PATCH 11/13] arm: npcm: drop selecting non-existing ARM_ERRATA_794072 To: Lukas Bulwahn Content-Type: text/plain; charset="UTF-8" X-BeenThere: openbmc@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development list for OpenBMC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Tomer Maimon , kernel-janitors , Tali Perry , Fabio Estevam , Benjamin Fair , OpenBMC Maillist , Russell King , Arnd Bergmann , Sekhar Nori , Sascha Hauer , Krzysztof Halasa , Linux ARM , Patrick Venture , Linus Walleij , Linux Kernel Mailing List , Dinh Nguyen , Pengutronix Kernel Team , Imre Kaloz , Shawn Guo , Bartosz Golaszewski Errors-To: openbmc-bounces+openbmc=archiver.kernel.org@lists.ozlabs.org Sender: "openbmc" On Tue, Nov 2, 2021 at 10:22 AM Avi Fishman wrote: > > Hi, > > At Nuvoton we implied this WA in the past, not because we encountered > a specific problem but since the errata says so and we saw this in > other patches like: > https://patchwork.kernel.org/project/linux-arm-kernel/patch/1396298072-13254-2-git-send-email-nitin.garg@freescale.com/ > But we didn't upstream the arch/arm/mm/proc-v7.S > > From the errata document. > "794072 A short loop including a DMB instruction might cause a denial > of service on > another processor which executes a CP15 broadcast operation > Status > Affects: > Fault Type: > Fault Status: Cortex-A9 MPCore. > Programmer Category B > Present in: All r1, r2, r3 and r4 revisions Open > Description > A processor which continuously executes a short loop containing a DMB > instruction might prevent a CP15 > operation broadcast by another processor making further progress, > causing a denial of service. > Configurations affected > This erratum affects all Cortex-A9 MPCore processors with two or more > processors. > Conditions > The erratum requires the following conditions: > - Two or more processors are working in SMP mode (ACTLR.SMP=1) > - One of the processors continuously executes a short loop containing > at least one DMB instruction. > - Another processor executes a CP15 maintenance operation that is > broadcast. This requires that this > processor has enabled the broadcasting of CP15 operations (ACTLR.FW=1) > For the erratum to occur, the short loop containing the DMB > instruction must meet all of the following additional > conditions: > - No more than 10 instructions other than the DMB are executed between each DMB > - No non-conditional Load or Store, or conditional Load or Store which > pass the condition code check, are > executed between each DMB > When all the conditions for the erratum are met, the short loop > creates a continuous stream of DMB instructions. > This might cause a denial of service, by preventing the processor > executing the short loop from executing the > received broadcast CP15 operation. As a result, the processor that > originally executed the broadcast CP15 > operation is stalled until the execution of the loop is interrupted. > Note that because the process issuing the CP15 broadcast operation > cannot complete operation, it cannot enter > any debug-mode, and cannot take any interrupt. If the processor > executing the short loop also cannot be > interrupted, for example if it has disabled its interrupts, or if no > interrupts are routed to this processor, this > erratum might cause a system livelock. > Implications > The erratum might create performance issues, or in the worst case it > might cause a system livelock if the > processor executing the DMB is in an infinite loop that cannot be interrupted. > Workaround > This erratum can be worked round by setting bit[4] of the undocumented > Diagnostic Control Register to 1. This > register is encoded as CP15 c15 0 c0 1. > This bit can be written in Secure state only, with the following > Read/Modify/Write code sequence: > MRC p15,0,rt,c15,c0,1 > ORR rt,rt,#0x10 > MCR p15,0,rt,c15,c0,1 > When it is set, this bit causes the DMB instruction to be decoded and > executed like a DSB. > Using this software workaround is not expected to have any impact on > the overall performance of the processor > on a typical code base. > Other workarounds are also available for this erratum, to either > prevent or interrupt the continuous stream of > DMB instructions that causes the deadlock. For example: > - Inserting a non-conditional Load or Store instruction in the loop > between each DMB > - Inserting additional instructions in the loop, such as NOPs, to > avoid the processor seeing back to back > DMB instructions. > - Making the processor executing the short loop take regular interrupts." > > Avi > > On Tue, Nov 2, 2021 at 9:31 AM Lukas Bulwahn wrote: > > > > On Fri, Oct 29, 2021 at 8:36 AM Joel Stanley wrote: > > > > > > On Thu, 28 Oct 2021 at 14:57, Arnd Bergmann wrote: > > > > > > > > On Thu, Oct 28, 2021 at 4:19 PM Lukas Bulwahn wrote: > > > > > > > > > > There is no and never was a Kconfig for ARM_ERRATA_794072 in the kernel > > > > > tree. So, there is no need to select ARM_ERRATA_794072 in > > > > > ./arch/arm/mach-npcm/Kconfig. > > > > > > > > > > Simply drop selecting the non-existing ARM_ERRATA_794072. > > > > > > > > > > This issue was discovered with ./scripts/checkkconfigsymbols.py. > > > > > > > > > > Signed-off-by: Lukas Bulwahn > > > > > --- > > > > > > > > Could this be a typo? Maybe we need to enable a different errata workaround > > > > here, or maybe that code is actually needed and has to get sent. > > > > > > Doing some searching, u-boot had a workaround for something called > > > ARM_ERRATA_794072. > > > > > > https://github.com/u-boot/u-boot/commit/f71cbfe3ca5d2ad20159871700e8e248c8818ba8 > > > > > > Lore has the review history for that patch: > > > > > > https://lore.kernel.org/all/6be32e0b5b454ed7b609317266a8e798@BLUPR03MB358.namprd03.prod.outlook.com/ > > > > > > It looks like it's the same workaround as ARM_ERRATA_742230, which the > > > kernel does implement. > > > > > > It would be good to hear from the Nuvoton people, or an Arm person. > > > > > > > I will happily update the patch to select ARM_ERRATA_742230 instead of > > the dead non-existing ARM_ERRATA_794072. > > > > In contrast to the current patch that basically only cleans up "dead > > config" and has no effective functional change, the new patch would > > change the behaviour. I cannot test this patch (beyond some basic > > compile test) on the hardware; so, we certainly need someone to have > > that hardware, knows how to test it or confirm otherwise that we > > should select the ARM_ERRATA_742230 fix for this hardware. Note that ARM_ERRATA_742230 is applied in code up-to CORTEX-A9 r2p2 but while ARM_ERRATA_794072 exist also in CORTEX-A9 r4p1 https://github.com/torvalds/linux/blob/322a3b843d7f475b857646ed8f95b40431d3ecd0/arch/arm/mm/proc-v7.S#L347 > > > > The current patch should be subsumed by the new patch; the submission > > of the new patch is deferred until that person shows up. Let's see. > > > > Lukas > > > > -- > Regards, > Avi -- Regards, Avi 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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8E68AC433EF for ; Tue, 2 Nov 2021 08:35:14 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 5B61D60F70 for ; Tue, 2 Nov 2021 08:35:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 5B61D60F70 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org 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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=LdiLzOeOfilnMQQo5aZz86y6UO5lZQoNpyPoi9Z9s0Y=; b=XFYrq6zkcHRR+0 G0Ltaja5/FyId83A/kOAeTfHOGVkFHDbbBxtf1tUYTxxjoJMvJhsYlgMxOmQqJL+hpK/HIc9gIWuY hM4bXdO2CyTlCDQnP84fo7TMDyDhf09mwSJaJ+U+KakYgdTB1K2TAjW69haI0EHQDK0m5af+u17Ct 4NnAdIwqe7gA/O/0ro01c1FkHOVCOqTeGKWl1mbewhdHmBfiEMvPSjVCYYUuIz91g27Wh7On6iUH/ Eyoml+S+YIq51y9EQj+1+4aOpWVBcIs/J76TAoC3QeAj2YrV7EZ0rZUagbUsdn57/yQLEcxn87xrq 7KRxLBvOqPIdtHT8KSgQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mhpEt-000wGd-CJ; Tue, 02 Nov 2021 08:33:51 +0000 Received: from mail-lf1-x132.google.com ([2a00:1450:4864:20::132]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mhpEp-000wFX-61 for linux-arm-kernel@lists.infradead.org; Tue, 02 Nov 2021 08:33:49 +0000 Received: by mail-lf1-x132.google.com with SMTP id u11so41461222lfs.1 for ; Tue, 02 Nov 2021 01:33:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IIbhqQ166KuY0HqjYi0SoZGpqG4hrHANtgC7gv/B4qE=; b=a2lkPtso9VSJtQKipU7sC99tkqQ0OotHLpbbtKDRwXJ8/FlMphMARe+W9ZykQ/EqH3 pvHw8SUBCv4OHNMaZVPzKzPC1o59GSm1kNgEgRnoZV+H4KScYM5uYgItIxW12WAHI3mF 76EUwcmQ50N7NyszRdSFLb/4FdJBYl1DLc5O9iibxGx4627nOnM82de4WQxiWoEZjCz7 Q6QOgt9k9XgpfbhM6zjqUws8v2TnrQ/I0gEL96L8OMKt0+l8pMu/SEAvy0+Bp9pLB6bq U+pn1YjezcL0s09Ly4pL2H+UCIO5Edh1xlgoIN/+p+gopy66ZJkjKhLBIQgya9apGjAs w5/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IIbhqQ166KuY0HqjYi0SoZGpqG4hrHANtgC7gv/B4qE=; b=w4HjAxccOr2NeokNzzsU9VdEVucNVEPOS9xckWIBXxvm3kQbFhDjxVf/3hSQmlyf/E Fm8xauPOtkVGlTnqj0eDrfgh5nQPFKnDjvu7cqUH7rAXQDwBli6G2q8r/JjRZ45hpU/z smPLA2U2onG6vXvZyJYWeMKhyAOu3NmO58yzUxfDZDDi/08xc6xj3moxRVkgMK7/YrMw WB03da3oAChEJ9Hg6Ad9vMbBK+KZSRlUJWH/qesLnIDMNcEz2u6ZmBNVzitYRFCd1PpT IBqig1moRx2iHa537jqDRK1nPzvKzLnrA01rqfFyi58sx5/25nmzhf4x/sag+w5Ay+rZ fHwA== X-Gm-Message-State: AOAM533PjDTj5YVQiM58kQOCzgv1tkx0pDVnDAxo1kI85WNGrE9tY5mw BdXuSdOXQ3zr0f1BxzuKO0zyt6HYTkB0f2A8uA== X-Google-Smtp-Source: ABdhPJzY1QYptzKxQ2dc9ZaB2dqJyb92U1gZE8xwtirNR1GtQGV0LjhT3+DOv5Tfb+KU1f7uH+LfjPc1eXAx/krB22A= X-Received: by 2002:a05:6512:3c9e:: with SMTP id h30mr2145698lfv.93.1635842023510; Tue, 02 Nov 2021 01:33:43 -0700 (PDT) MIME-Version: 1.0 References: <20211028141938.3530-1-lukas.bulwahn@gmail.com> <20211028141938.3530-12-lukas.bulwahn@gmail.com> In-Reply-To: From: Avi Fishman Date: Tue, 2 Nov 2021 10:33:32 +0200 Message-ID: Subject: Re: [PATCH 11/13] arm: npcm: drop selecting non-existing ARM_ERRATA_794072 To: Lukas Bulwahn Cc: Joel Stanley , Arnd Bergmann , Tomer Maimon , Russell King , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Sekhar Nori , Bartosz Golaszewski , Linus Walleij , Imre Kaloz , Krzysztof Halasa , Tali Perry , Patrick Venture , Nancy Yuen , Benjamin Fair , Dinh Nguyen , Linux ARM , OpenBMC Maillist , kernel-janitors , Linux Kernel Mailing List X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211102_013347_261316_BEF7EACB X-CRM114-Status: GOOD ( 51.22 ) 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, Nov 2, 2021 at 10:22 AM Avi Fishman wrote: > > Hi, > > At Nuvoton we implied this WA in the past, not because we encountered > a specific problem but since the errata says so and we saw this in > other patches like: > https://patchwork.kernel.org/project/linux-arm-kernel/patch/1396298072-13254-2-git-send-email-nitin.garg@freescale.com/ > But we didn't upstream the arch/arm/mm/proc-v7.S > > From the errata document. > "794072 A short loop including a DMB instruction might cause a denial > of service on > another processor which executes a CP15 broadcast operation > Status > Affects: > Fault Type: > Fault Status: Cortex-A9 MPCore. > Programmer Category B > Present in: All r1, r2, r3 and r4 revisions Open > Description > A processor which continuously executes a short loop containing a DMB > instruction might prevent a CP15 > operation broadcast by another processor making further progress, > causing a denial of service. > Configurations affected > This erratum affects all Cortex-A9 MPCore processors with two or more > processors. > Conditions > The erratum requires the following conditions: > - Two or more processors are working in SMP mode (ACTLR.SMP=1) > - One of the processors continuously executes a short loop containing > at least one DMB instruction. > - Another processor executes a CP15 maintenance operation that is > broadcast. This requires that this > processor has enabled the broadcasting of CP15 operations (ACTLR.FW=1) > For the erratum to occur, the short loop containing the DMB > instruction must meet all of the following additional > conditions: > - No more than 10 instructions other than the DMB are executed between each DMB > - No non-conditional Load or Store, or conditional Load or Store which > pass the condition code check, are > executed between each DMB > When all the conditions for the erratum are met, the short loop > creates a continuous stream of DMB instructions. > This might cause a denial of service, by preventing the processor > executing the short loop from executing the > received broadcast CP15 operation. As a result, the processor that > originally executed the broadcast CP15 > operation is stalled until the execution of the loop is interrupted. > Note that because the process issuing the CP15 broadcast operation > cannot complete operation, it cannot enter > any debug-mode, and cannot take any interrupt. If the processor > executing the short loop also cannot be > interrupted, for example if it has disabled its interrupts, or if no > interrupts are routed to this processor, this > erratum might cause a system livelock. > Implications > The erratum might create performance issues, or in the worst case it > might cause a system livelock if the > processor executing the DMB is in an infinite loop that cannot be interrupted. > Workaround > This erratum can be worked round by setting bit[4] of the undocumented > Diagnostic Control Register to 1. This > register is encoded as CP15 c15 0 c0 1. > This bit can be written in Secure state only, with the following > Read/Modify/Write code sequence: > MRC p15,0,rt,c15,c0,1 > ORR rt,rt,#0x10 > MCR p15,0,rt,c15,c0,1 > When it is set, this bit causes the DMB instruction to be decoded and > executed like a DSB. > Using this software workaround is not expected to have any impact on > the overall performance of the processor > on a typical code base. > Other workarounds are also available for this erratum, to either > prevent or interrupt the continuous stream of > DMB instructions that causes the deadlock. For example: > - Inserting a non-conditional Load or Store instruction in the loop > between each DMB > - Inserting additional instructions in the loop, such as NOPs, to > avoid the processor seeing back to back > DMB instructions. > - Making the processor executing the short loop take regular interrupts." > > Avi > > On Tue, Nov 2, 2021 at 9:31 AM Lukas Bulwahn wrote: > > > > On Fri, Oct 29, 2021 at 8:36 AM Joel Stanley wrote: > > > > > > On Thu, 28 Oct 2021 at 14:57, Arnd Bergmann wrote: > > > > > > > > On Thu, Oct 28, 2021 at 4:19 PM Lukas Bulwahn wrote: > > > > > > > > > > There is no and never was a Kconfig for ARM_ERRATA_794072 in the kernel > > > > > tree. So, there is no need to select ARM_ERRATA_794072 in > > > > > ./arch/arm/mach-npcm/Kconfig. > > > > > > > > > > Simply drop selecting the non-existing ARM_ERRATA_794072. > > > > > > > > > > This issue was discovered with ./scripts/checkkconfigsymbols.py. > > > > > > > > > > Signed-off-by: Lukas Bulwahn > > > > > --- > > > > > > > > Could this be a typo? Maybe we need to enable a different errata workaround > > > > here, or maybe that code is actually needed and has to get sent. > > > > > > Doing some searching, u-boot had a workaround for something called > > > ARM_ERRATA_794072. > > > > > > https://github.com/u-boot/u-boot/commit/f71cbfe3ca5d2ad20159871700e8e248c8818ba8 > > > > > > Lore has the review history for that patch: > > > > > > https://lore.kernel.org/all/6be32e0b5b454ed7b609317266a8e798@BLUPR03MB358.namprd03.prod.outlook.com/ > > > > > > It looks like it's the same workaround as ARM_ERRATA_742230, which the > > > kernel does implement. > > > > > > It would be good to hear from the Nuvoton people, or an Arm person. > > > > > > > I will happily update the patch to select ARM_ERRATA_742230 instead of > > the dead non-existing ARM_ERRATA_794072. > > > > In contrast to the current patch that basically only cleans up "dead > > config" and has no effective functional change, the new patch would > > change the behaviour. I cannot test this patch (beyond some basic > > compile test) on the hardware; so, we certainly need someone to have > > that hardware, knows how to test it or confirm otherwise that we > > should select the ARM_ERRATA_742230 fix for this hardware. Note that ARM_ERRATA_742230 is applied in code up-to CORTEX-A9 r2p2 but while ARM_ERRATA_794072 exist also in CORTEX-A9 r4p1 https://github.com/torvalds/linux/blob/322a3b843d7f475b857646ed8f95b40431d3ecd0/arch/arm/mm/proc-v7.S#L347 > > > > The current patch should be subsumed by the new patch; the submission > > of the new patch is deferred until that person shows up. Let's see. > > > > Lukas > > > > -- > Regards, > Avi -- Regards, Avi _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel