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 C9A9CC433EF for ; Fri, 6 May 2022 12:49:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 452106B0072; Fri, 6 May 2022 08:49:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3D86C6B0073; Fri, 6 May 2022 08:49:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2A0986B0074; Fri, 6 May 2022 08:49:19 -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 1B5026B0072 for ; Fri, 6 May 2022 08:49:19 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id D83A2210AE for ; Fri, 6 May 2022 12:49:18 +0000 (UTC) X-FDA: 79435298796.15.646ADC3 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf30.hostedemail.com (Postfix) with ESMTP id 1F8A680030 for ; Fri, 6 May 2022 12:49:03 +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 7F52F61FFC; Fri, 6 May 2022 12:49:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2C896C385A9; Fri, 6 May 2022 12:49:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651841356; bh=Xzlxw967//wBeStYvKhZYB7jk1h07mUTrZFlBGFoCHA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=UISa522hmvLJFGBu0ZpKyZLyoARMMIxPG5cDyEdayRF19L/JqMK3p7TLsTNrPc6rj 9TmEsj0U6bCcHMGpD5jpStmwedqeZX+frJzjCnYtL495sT4ltNoGFZqRMIExbPU8Ip +uT+EtV+qy4BCDw8FXO/vhkWN1tVoJVfGCwK2fdmsgIibAl2z5+LAI+K5tAEGLlCae 2y/G72s0f+iZD+UWIT7SzkOUGKcL1UqijDx3oKrMmi3lITymHd1X9NUkUqZCtHahDL 73yZoNt7GxAYUCPGUV24iv9POtZTQ9qLJ7uJHZDRpWN3rT9NHycvxWWKS+71SoJYrj mJULqljNh3eNg== Date: Fri, 6 May 2022 13:49:11 +0100 From: Will Deacon To: Steve Capper Cc: Catalin Marinas , David Hildenbrand , Mike Kravetz , "linux-mm@kvack.org" , anshuman.khandual@arm.com, "Aneesh Kumar K . V" , Peter Zijlstra , nd@arm.com Subject: Re: VM_BUG_ON(!tlb->end) on munmap() with CONT hugetlb pages Message-ID: <20220506124909.GA22892@willie-the-truck> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <881efece-c362-af41-4dea-77db71ec9928@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 1F8A680030 X-Stat-Signature: qtsb4o81xkpkxubs3xweusntocntkyfa X-Rspam-User: Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=UISa522h; spf=pass (imf30.hostedemail.com: domain of will@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=will@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-HE-Tag: 1651841343-392410 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 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? Will