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 A52F1C433F5 for ; Wed, 23 Mar 2022 16:21:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E39296B0072; Wed, 23 Mar 2022 12:21:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DC1A86B0073; Wed, 23 Mar 2022 12:21:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C62036B0074; Wed, 23 Mar 2022 12:21:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0179.hostedemail.com [216.40.44.179]) by kanga.kvack.org (Postfix) with ESMTP id B43FC6B0072 for ; Wed, 23 Mar 2022 12:21:47 -0400 (EDT) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 66D9AA15F9 for ; Wed, 23 Mar 2022 16:21:47 +0000 (UTC) X-FDA: 79276167054.16.CA0C968 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf06.hostedemail.com (Postfix) with ESMTP id CB002180014 for ; Wed, 23 Mar 2022 16:21:46 +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 ams.source.kernel.org (Postfix) with ESMTPS id 31967B81FA1; Wed, 23 Mar 2022 16:21:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 404CEC340EE; Wed, 23 Mar 2022 16:21:42 +0000 (UTC) Date: Wed, 23 Mar 2022 16:21:38 +0000 From: Catalin Marinas To: Steve Capper Cc: David Hildenbrand , Mike Kravetz , "linux-mm@kvack.org" , anshuman.khandual@arm.com, Will Deacon , "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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: CB002180014 X-Stat-Signature: p9fej6gt3ruyw3f4jpy83s8z64wj3j5q Authentication-Results: imf06.hostedemail.com; dkim=none; spf=pass (imf06.hostedemail.com: domain of cmarinas@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) X-Rspam-User: X-HE-Tag: 1648052506-938933 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 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. -- Catalin