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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6B3CCC433F5 for ; Mon, 9 May 2022 12:12:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B20A26B0071; Mon, 9 May 2022 08:12:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ACFB86B0073; Mon, 9 May 2022 08:12:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 996C06B0074; Mon, 9 May 2022 08:12:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 89D516B0071 for ; Mon, 9 May 2022 08:12:03 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 602CD610E1 for ; Mon, 9 May 2022 12:12:03 +0000 (UTC) X-FDA: 79446091326.21.560AFF4 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf11.hostedemail.com (Postfix) with ESMTP id 737424009B for ; Mon, 9 May 2022 12:11:57 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 58209612E8; Mon, 9 May 2022 12:12:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 77630C385A8; Mon, 9 May 2022 12:11:59 +0000 (UTC) Date: Mon, 9 May 2022 13:11:55 +0100 From: Catalin Marinas To: Anshuman Khandual Cc: Will Deacon , Steve Capper , David Hildenbrand , Mike Kravetz , "linux-mm@kvack.org" , "Aneesh Kumar K . V" , Peter Zijlstra , nd@arm.com Subject: Re: VM_BUG_ON(!tlb->end) on munmap() with CONT hugetlb pages Message-ID: References: <811c5c8e-b3a2-85d2-049c-717f17c3a03a@redhat.com> <993f1258-6550-e5d7-1e6f-72e2a24b60f0@oracle.com> <3ba18a1d-d5d8-558f-9576-8119c210e98a@oracle.com> <881efece-c362-af41-4dea-77db71ec9928@arm.com> <20220506124909.GA22892@willie-the-truck> <84b579b2-7528-3d3c-02e4-29586791432f@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84b579b2-7528-3d3c-02e4-29586791432f@arm.com> X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 737424009B X-Stat-Signature: tjrkezrbi4w7osmsjn1u1ia1jybq3658 Authentication-Results: imf11.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf11.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org X-Rspam-User: X-HE-Tag: 1652098317-210021 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, May 09, 2022 at 04:49:25PM +0530, Anshuman Khandual wrote: > On 5/6/22 18:19, Will Deacon wrote: > > On Wed, Mar 23, 2022 at 04:34:26PM +0000, Steve Capper wrote: > >> On 23/03/2022 16:21, Catalin Marinas wrote: > >>> On Wed, Mar 23, 2022 at 11:51:25AM +0000, Steve Capper wrote: > >>>> On 22/03/2022 17:56, Catalin Marinas wrote: > >>>>> At a quick look, we wouldn't have a problem with missing TLB flushing > >>>>> since huge_ptep_get_and_clear() does this for contiguous PTEs. Not sure > >>>>> why it needs this though, Steve added it in commit d8bdcff28764. I think > >>>>> we can defer this flushing to tlb_remove_page_size(). > >>>> > >>>> The TLB flush in huge_ptep_get_and_clear() was added because it was called > >>>> by hugetlb_change_protection() without any flushing. The concern was that, > >>>> without the flush, it would be possible to get to different views of the > >>>> same contiguous huge page. (Being contiguous they were not changed en masse > >>>> atomically). > >>> > >>> Maybe the code paths have been changed since but looking at > >>> hugetlb_change_protection(), we have huge_ptep_modify_prot_start() > >>> calling huge_ptep_get_and_clear() which AFAICT only needs to clear the > >>> ptes. huge_ptep_modify_prot_commit() calls set_huge_pte_at() which does > >>> another pte clearing + TLBI (clear_flush()) before setting the new ptes. > >>> So we do the pte clearing and TLBI twice already. > >>> > >> > >> Thanks, yeah indeed the code has changed and the flush should be removed > >> from the arm64 huge_ptep_get_and_clear. > > > > Did anybody send a patch for this? > > Planning to send a patch which drops TLB flushing from get_clear_flush() and > also renames it as required. Something like this but just slightly tested. The diff looks fine to me. I think this only works if we also have commit 697a1d44af8b ("tlb: hugetlb: Add more sizes to tlb_remove_huge_tlb_entry"), otherwise we risk missing some TLBIs on the unmap path. -- Catalin