Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp312450rwd; Wed, 14 Jun 2023 16:38:02 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7xfY9xeQJkX4DI9wPIfD3qOFmRUSaezAq9ehOJY40bQUvQMm8AWgECzEmSnM6ieU82kXHG X-Received: by 2002:a05:6402:793:b0:518:793e:1ee9 with SMTP id d19-20020a056402079300b00518793e1ee9mr2938888edy.16.1686785882032; Wed, 14 Jun 2023 16:38:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686785882; cv=none; d=google.com; s=arc-20160816; b=BNAVNP1PLrwLKIObIPhsg0m/7LEVyfDNppA2Nj8Nyz6TBeNx7VRKrB8LYfJCjHSreo lEX7SQ7+2N8bBGKa99hlDaEm+p8wfCk3rSPprTN8T+hlQuINno7nfDVY0/gSFZOraDdQ v3aeyuJ8fp0rj9dWKkQrMRIVBcF8I8XLFOo5IbRAMPYEEb+/S3CBw1iFeYMZKFoUcuza 6c1mi8gd83vEEM68Q6M0sTgj2GU+cG8AeBhC9OVapJKi+9KllNynG/uAVbsMSP9/rGjZ V0P921d7hdmVsJnQE7p4ORHNwZQhh3ZSNaVsmXrq1FV8rJZ0bPVoKueb/IvUcPRtT51H 7I4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=YurStXT9JRWv5q4JhXezG0+JSICRTY1wVUP1Tj/wMtM=; b=ySD0IgzSf5Pv4R4KjeXhBf4UQJIuCh0/1YA37jPC9+lWyAH+tMWafoQo4YbcFyAKIX o6rJT8OPUSfXWyhmoUKDCkFs4XjqDNjCwOY9y4xPdKjoE44iCpwP2OfeK5eGXFpme422 7zH2af03+WLGp1u30RZlhQ+DJ142R1hOxWoZkibEpBaOGwHMgTCkbftn3pQmSgKQUkyp t0NPaAIr9Ow4NWv9sMKF9z97P1OHyWXitJ45P2tbgH3gMIp/H9+0EvkrtoYHjbOfd85O q2ChPQrZl+a0MPtP5TQesYnGuBd6+hbaY4GM+K8jpeDl6fxCRhy7NqRQ/Z9lZfyMdr9L e7Eg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="nv+ldAK/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n21-20020a05640204d500b0051836749133si5478402edw.494.2023.06.14.16.37.37; Wed, 14 Jun 2023 16:38:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="nv+ldAK/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239210AbjFNXSb (ORCPT + 99 others); Wed, 14 Jun 2023 19:18:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54222 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234129AbjFNXSS (ORCPT ); Wed, 14 Jun 2023 19:18:18 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 83B101FEF; Wed, 14 Jun 2023 16:18:03 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (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 dfw.source.kernel.org (Postfix) with ESMTPS id 184266286E; Wed, 14 Jun 2023 23:18:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C9BABC433C8; Wed, 14 Jun 2023 23:17:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1686784682; bh=VtjXUsVFZs1O91NerGvbTs+J8wgXOZF0VffZjoZ8hNE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=nv+ldAK/HpfiYALxKtTzDJ3R1JvD8STlSMxVjZUG5Avyp/mD57nD76jjE3FPXT8AL HCGXEPCkaFUHIfSqWaNABbDD1Al1ADfRLyjDSCn2qAeMIrs+Db1tkl6FNOEpc676Ze l68tWfDummphVfPm7n2mcDB8CWV7pztUvHFE3q0JsE2gCl/zLRclcYygBfyViXXnem gK73cgwRKGUwFnFqEfuSuC2FVqbH9J3ptdq5dhRed4nxnjBXEyDeORkjPQ30CCpF70 QaJdYw8nkViSwe2ZlqF2rBlHvWW/eaJ5JiW0kpHPUcMlEFETbnObgVCONxs2mm8WRC cUQeRdqv61Jyw== Date: Wed, 14 Jun 2023 16:17:58 -0700 From: Nathan Chancellor To: Hugh Dickins Cc: Andrew Morton , Mike Kravetz , Mike Rapoport , "Kirill A. Shutemov" , Matthew Wilcox , David Hildenbrand , Suren Baghdasaryan , Qi Zheng , Peter Zijlstra , Russell King , Catalin Marinas , Will Deacon , Geert Uytterhoeven , Greg Ungerer , Michal Simek , Thomas Bogendoerfer , Helge Deller , John David Anglin , "Aneesh Kumar K.V" , Michael Ellerman , Alexandre Ghiti , Palmer Dabbelt , Heiko Carstens , Christian Borntraeger , Claudio Imbrenda , Alexander Gordeev , John Paul Adrian Glaubitz , "David S. Miller" , Chris Zankel , Max Filippov , x86@kernel.org, linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v2 07/23] mips: update_mmu_cache() can replace __update_tlb() Message-ID: <20230614231758.GA1503611@dev-arch.thelio-3990X> References: <178970b0-1539-8aac-76fd-972c6c46ec17@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <178970b0-1539-8aac-76fd-972c6c46ec17@google.com> X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Hugh, On Thu, Jun 08, 2023 at 12:17:24PM -0700, Hugh Dickins wrote: > Don't make update_mmu_cache() a wrapper around __update_tlb(): call it > directly, and use the ptep (or pmdp) provided by the caller, instead of > re-calling pte_offset_map() - which would raise a question of whether a > pte_unmap() is needed to balance it. > > Check whether the "ptep" provided by the caller is actually the pmdp, > instead of testing pmd_huge(): or test pmd_huge() too and warn if it > disagrees? This is "hazardous" territory: needs review and testing. > > Signed-off-by: Hugh Dickins > --- > arch/mips/include/asm/pgtable.h | 15 +++------------ > arch/mips/mm/tlb-r3k.c | 5 +++-- > arch/mips/mm/tlb-r4k.c | 9 +++------ > 3 files changed, 9 insertions(+), 20 deletions(-) > > diff --git a/arch/mips/include/asm/pgtable.h b/arch/mips/include/asm/pgtable.h > index 574fa14ac8b2..9175dfab08d5 100644 > --- a/arch/mips/include/asm/pgtable.h > +++ b/arch/mips/include/asm/pgtable.h > @@ -565,15 +565,8 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte) > } > #endif > > -extern void __update_tlb(struct vm_area_struct *vma, unsigned long address, > - pte_t pte); > - > -static inline void update_mmu_cache(struct vm_area_struct *vma, > - unsigned long address, pte_t *ptep) > -{ > - pte_t pte = *ptep; > - __update_tlb(vma, address, pte); > -} > +extern void update_mmu_cache(struct vm_area_struct *vma, > + unsigned long address, pte_t *ptep); > > #define __HAVE_ARCH_UPDATE_MMU_TLB > #define update_mmu_tlb update_mmu_cache > @@ -581,9 +574,7 @@ static inline void update_mmu_cache(struct vm_area_struct *vma, > static inline void update_mmu_cache_pmd(struct vm_area_struct *vma, > unsigned long address, pmd_t *pmdp) > { > - pte_t pte = *(pte_t *)pmdp; > - > - __update_tlb(vma, address, pte); > + update_mmu_cache(vma, address, (pte_t *)pmdp); > } > > /* > diff --git a/arch/mips/mm/tlb-r3k.c b/arch/mips/mm/tlb-r3k.c > index 53dfa2b9316b..e5722cd8dd6d 100644 > --- a/arch/mips/mm/tlb-r3k.c > +++ b/arch/mips/mm/tlb-r3k.c > @@ -176,7 +176,8 @@ void local_flush_tlb_page(struct vm_area_struct *vma, unsigned long page) > } > } > > -void __update_tlb(struct vm_area_struct *vma, unsigned long address, pte_t pte) > +void update_mmu_cache(struct vm_area_struct *vma, > + unsigned long address, pte_t *ptep) > { > unsigned long asid_mask = cpu_asid_mask(¤t_cpu_data); > unsigned long flags; > @@ -203,7 +204,7 @@ void __update_tlb(struct vm_area_struct *vma, unsigned long address, pte_t pte) > BARRIER; > tlb_probe(); > idx = read_c0_index(); > - write_c0_entrylo0(pte_val(pte)); > + write_c0_entrylo0(pte_val(*ptep)); > write_c0_entryhi(address | pid); > if (idx < 0) { /* BARRIER */ > tlb_write_random(); > diff --git a/arch/mips/mm/tlb-r4k.c b/arch/mips/mm/tlb-r4k.c > index 1b939abbe4ca..c96725d17cab 100644 > --- a/arch/mips/mm/tlb-r4k.c > +++ b/arch/mips/mm/tlb-r4k.c > @@ -290,14 +290,14 @@ void local_flush_tlb_one(unsigned long page) > * updates the TLB with the new pte(s), and another which also checks > * for the R4k "end of page" hardware bug and does the needy. > */ > -void __update_tlb(struct vm_area_struct * vma, unsigned long address, pte_t pte) > +void update_mmu_cache(struct vm_area_struct *vma, > + unsigned long address, pte_t *ptep) > { > unsigned long flags; > pgd_t *pgdp; > p4d_t *p4dp; > pud_t *pudp; > pmd_t *pmdp; > - pte_t *ptep; > int idx, pid; > > /* > @@ -326,10 +326,9 @@ void __update_tlb(struct vm_area_struct * vma, unsigned long address, pte_t pte) > idx = read_c0_index(); > #ifdef CONFIG_MIPS_HUGE_TLB_SUPPORT > /* this could be a huge page */ > - if (pmd_huge(*pmdp)) { > + if (ptep == (pte_t *)pmdp) { > unsigned long lo; > write_c0_pagemask(PM_HUGE_MASK); > - ptep = (pte_t *)pmdp; > lo = pte_to_entrylo(pte_val(*ptep)); > write_c0_entrylo0(lo); > write_c0_entrylo1(lo + (HPAGE_SIZE >> 7)); > @@ -344,8 +343,6 @@ void __update_tlb(struct vm_area_struct * vma, unsigned long address, pte_t pte) > } else > #endif > { > - ptep = pte_offset_map(pmdp, address); > - > #if defined(CONFIG_PHYS_ADDR_T_64BIT) && defined(CONFIG_CPU_MIPS32) > #ifdef CONFIG_XPA > write_c0_entrylo0(pte_to_entrylo(ptep->pte_high)); > -- > 2.35.3 > I just bisected a crash while powering down a MIPS machine in QEMU to this change as commit 8044511d3893 ("mips: update_mmu_cache() can replace __update_tlb()") in linux-next. Unfortunately, I can still reproduce it with the existing fix you have for this change on the mailing list, which is present in next-20230614. I can reproduce it with the GCC 13.1.0 on kernel.org [1]. $ make -skj"$(nproc)" ARCH=mips CROSS_COMPILE=mips-linux- mrproper malta_defconfig vmlinux $ qemu-system-mipsel \ -display none \ -nodefaults \ -cpu 24Kf \ -machine malta \ -kernel vmlinux \ -initrd rootfs.cpio \ -m 512m \ -serial mon:stdio ... Linux version 6.4.0-rc6-next-20230614 (nathan@dev-arch.thelio-3990X) (mips-linux-gcc (GCC) 13.1.0, GNU ld (GNU Binutils) 2.40) #1 SMP Wed Jun 14 16:13:02 MST 2023 ... Run /init as init process process '/bin/busybox' started with executable stack do_page_fault(): sending SIGSEGV to init for invalid read access from 0000003c epc = 77b893dc in ld-uClibc-1.0.39.so[77b84000+8000] ra = 77b8930c in ld-uClibc-1.0.39.so[77b84000+8000] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]--- The rootfs is available at [2] if it is needed. I am more than happy to provide additional information or test patches if necessary. [1]: https://mirrors.edge.kernel.org/pub/tools/crosstool/ [2]: https://github.com/ClangBuiltLinux/boot-utils/releases/download/20230609-194440/mipsel-rootfs.cpio.zst Cheers, Nathan