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=-6.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable 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 530FEC3A5A6 for ; Thu, 19 Sep 2019 22:05:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 236E8218AF for ; Thu, 19 Sep 2019 22:05:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1568930748; bh=ro/DfseQWuleAb42UbshDMMqKMna8V4KQSpoc7RJ3Zk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=v4mLWSn34waoJL2bGoDQ7SLqLvTwjDKmA5IBIKLg1W1uDD6bd+ALoQkwSrx810inR +zWhjlhC/kri8G2L7BLP9WdlmfXbjHq4ELAl9T9nwTMmlcy1arrQvFVBdwTnyWcCen W6cD7VS2PepA8sEX4j2yUkVvn90XdSI9e6Kdgr5U= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2405038AbfISWFr (ORCPT ); Thu, 19 Sep 2019 18:05:47 -0400 Received: from mail.kernel.org ([198.145.29.99]:42782 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404999AbfISWFg (ORCPT ); Thu, 19 Sep 2019 18:05:36 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 0C11B218AF; Thu, 19 Sep 2019 22:05:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1568930735; bh=ro/DfseQWuleAb42UbshDMMqKMna8V4KQSpoc7RJ3Zk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tgl7nQQSRGA8xwNpi5l/RbAQLY6dThIt65ugZs6FDbMJ5G/7MxLX3MMd7Luh8bV/H 1mISvwZnCkSVqvFjN9JMZ+xAwyfOUThh410tJ+UpEHNYgR+jfWl82NZllyS882JoTp Ei8XH1GxOfT8E1QcxQamEcojlH5WxYlR19XoQMoY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mark Rutland , Will Deacon Subject: [PATCH 5.3 17/21] Revert "arm64: Remove unnecessary ISBs from set_{pte,pmd,pud}" Date: Fri, 20 Sep 2019 00:03:18 +0200 Message-Id: <20190919214710.964400249@linuxfoundation.org> X-Mailer: git-send-email 2.23.0 In-Reply-To: <20190919214657.842130855@linuxfoundation.org> References: <20190919214657.842130855@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Will Deacon commit d0b7a302d58abe24ed0f32a0672dd4c356bb73db upstream. This reverts commit 24fe1b0efad4fcdd32ce46cffeab297f22581707. Commit 24fe1b0efad4fcdd ("arm64: Remove unnecessary ISBs from set_{pte,pmd,pud}") removed ISB instructions immediately following updates to the page table, on the grounds that they are not required by the architecture and a DSB alone is sufficient to ensure that subsequent data accesses use the new translation: DDI0487E_a, B2-128: | ... no instruction that appears in program order after the DSB | instruction can alter any state of the system or perform any part of | its functionality until the DSB completes other than: | | * Being fetched from memory and decoded | * Reading the general-purpose, SIMD and floating-point, | Special-purpose, or System registers that are directly or indirectly | read without causing side-effects. However, the same document also states the following: DDI0487E_a, B2-125: | DMB and DSB instructions affect reads and writes to the memory system | generated by Load/Store instructions and data or unified cache | maintenance instructions being executed by the PE. Instruction fetches | or accesses caused by a hardware translation table access are not | explicit accesses. which appears to claim that the DSB alone is insufficient. Unfortunately, some CPU designers have followed the second clause above, whereas in Linux we've been relying on the first. This means that our mapping sequence: MOV X0, STR X0, [Xptep] // Store new PTE to page table DSB ISHST LDR X1, [X2] // Translates using the new PTE can actually raise a translation fault on the load instruction because the translation can be performed speculatively before the page table update and then marked as "faulting" by the CPU. For user PTEs, this is ok because we can handle the spurious fault, but for kernel PTEs and intermediate table entries this results in a panic(). Revert the offending commit to reintroduce the missing barriers. Cc: Fixes: 24fe1b0efad4fcdd ("arm64: Remove unnecessary ISBs from set_{pte,pmd,pud}") Reviewed-by: Mark Rutland Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman --- arch/arm64/include/asm/pgtable.h | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) --- a/arch/arm64/include/asm/pgtable.h +++ b/arch/arm64/include/asm/pgtable.h @@ -220,8 +220,10 @@ static inline void set_pte(pte_t *ptep, * Only if the new pte is valid and kernel, otherwise TLB maintenance * or update_mmu_cache() have the necessary barriers. */ - if (pte_valid_not_user(pte)) + if (pte_valid_not_user(pte)) { dsb(ishst); + isb(); + } } extern void __sync_icache_dcache(pte_t pteval); @@ -484,8 +486,10 @@ static inline void set_pmd(pmd_t *pmdp, WRITE_ONCE(*pmdp, pmd); - if (pmd_valid(pmd)) + if (pmd_valid(pmd)) { dsb(ishst); + isb(); + } } static inline void pmd_clear(pmd_t *pmdp) @@ -543,8 +547,10 @@ static inline void set_pud(pud_t *pudp, WRITE_ONCE(*pudp, pud); - if (pud_valid(pud)) + if (pud_valid(pud)) { dsb(ishst); + isb(); + } } static inline void pud_clear(pud_t *pudp)