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 53284C433F5 for ; Wed, 11 May 2022 03:41:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A5DE66B0073; Tue, 10 May 2022 23:41:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9E5CD6B0075; Tue, 10 May 2022 23:41:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 85EA36B0078; Tue, 10 May 2022 23:41:14 -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 6FCBF6B0073 for ; Tue, 10 May 2022 23:41:14 -0400 (EDT) Received: from smtpin31.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 43E52328D2 for ; Wed, 11 May 2022 03:41:14 +0000 (UTC) X-FDA: 79452061668.31.F114673 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf06.hostedemail.com (Postfix) with ESMTP id 3C6D41800AB for ; Wed, 11 May 2022 03:41:11 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8E430106F; Tue, 10 May 2022 20:41:12 -0700 (PDT) Received: from [192.168.0.8] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6AA323F5A1; Tue, 10 May 2022 20:41:09 -0700 (PDT) Message-ID: <916dde5f-8ffd-95ca-0dfd-6777d2ef8498@arm.com> Date: Wed, 11 May 2022 09:12:14 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: VM_BUG_ON(!tlb->end) on munmap() with CONT hugetlb pages Content-Language: en-US To: Catalin Marinas Cc: Will Deacon , Steve Capper , David Hildenbrand , Mike Kravetz , "linux-mm@kvack.org" , "Aneesh Kumar K . V" , Peter Zijlstra , nd@arm.com 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> From: Anshuman Khandual In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Authentication-Results: imf06.hostedemail.com; dkim=none; spf=pass (imf06.hostedemail.com: domain of anshuman.khandual@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=anshuman.khandual@arm.com; dmarc=pass (policy=none) header.from=arm.com X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 3C6D41800AB X-Stat-Signature: 4hmq4ggtdia6p7ohgjyfj764n8jupsau X-HE-Tag: 1652240471-316847 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 5/9/22 17:41, Catalin Marinas wrote: > 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. FYI, posted here. https://lore.kernel.org/all/20220510043930.2410985-1-anshuman.khandual@arm.com/