From patchwork Fri Nov 5 20:38:21 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 12605505 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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9E366C433F5 for ; Fri, 5 Nov 2021 20:38:24 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 54DE56056B for ; Fri, 5 Nov 2021 20:38:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 54DE56056B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id DFD44940043; Fri, 5 Nov 2021 16:38:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D84F394003D; Fri, 5 Nov 2021 16:38:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C4FA3940043; Fri, 5 Nov 2021 16:38:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0124.hostedemail.com [216.40.44.124]) by kanga.kvack.org (Postfix) with ESMTP id AD04094003D for ; Fri, 5 Nov 2021 16:38:23 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 6375F18037D3A for ; Fri, 5 Nov 2021 20:38:23 +0000 (UTC) X-FDA: 78776039286.22.A5B8F2B Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf28.hostedemail.com (Postfix) with ESMTP id EC6CD90000B4 for ; Fri, 5 Nov 2021 20:38:22 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id C457C60174; Fri, 5 Nov 2021 20:38:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1636144702; bh=/5P1kFsDt2rnxtQraJN9QoS2RlQR3nyp2CXKI0+oaHw=; h=Date:From:To:Subject:In-Reply-To:From; b=KeV+hYAGxCpYKI9ECVB5KlYlEoNOivfvMPUE1KHHntJs8ZCyAClWepw7phznmJEYE 9c/vnj6gymOID0vKwUcEd66y0PIwneU4Fq7bYprnEyGYFgSRLIfkWqslNPS227eGYj 43N+dWR3JO/jYVdnhRqjh8nSAEDIU3PLWjV38WEY= Date: Fri, 05 Nov 2021 13:38:21 -0700 From: Andrew Morton To: aarcange@redhat.com, akpm@linux-foundation.org, andrew.cooper3@citrix.com, dave.hansen@linux.intel.com, linux-mm@kvack.org, luto@kernel.org, mm-commits@vger.kernel.org, namit@vmware.com, npiggin@gmail.com, peterz@infradead.org, tglx@linutronix.de, torvalds@linux-foundation.org, will@kernel.org, yuzhao@google.com Subject: [patch 071/262] mm/memory.c: use correct VMA flags when freeing page-tables Message-ID: <20211105203821.mV5HWKCGr%akpm@linux-foundation.org> In-Reply-To: <20211105133408.cccbb98b71a77d5e8430aba1@linux-foundation.org> User-Agent: s-nail v14.8.16 Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=KeV+hYAG; dmarc=none; spf=pass (imf28.hostedemail.com: domain of akpm@linux-foundation.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: EC6CD90000B4 X-Stat-Signature: dhbmiy7iyp6xpqi1uhw78tx9f1hs771w X-HE-Tag: 1636144702-512037 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: From: Nadav Amit Subject: mm/memory.c: use correct VMA flags when freeing page-tables Consistent use of the mmu_gather interface requires a call to tlb_start_vma() and tlb_end_vma() for each VMA. free_pgtables() does not follow this pattern. Certain architectures need tlb_start_vma() to be called in order for tlb_update_vma_flags() to update the VMA flags (tlb->vma_exec and tlb->vma_huge), which are later used for the proper TLB flush to be issued. Since tlb_start_vma() is not called, this can lead to the wrong VMA flags being used when the flush is performed. Specifically, the munmap syscall would call unmap_region(), which unmaps the VMAs and then frees the page-tables. A flush is needed after the page-tables are removed to prevent page-walk caches from holding stale entries, but this flush would use the flags of the VMA flags of the last VMA that was flushed. This does not appear to be right. Use tlb_start_vma() and tlb_end_vma() to prevent this from happening. This might lead to unnecessary calls to flush_cache_range() on certain arch's. If needed, a new flag can be added to mmu_gather to indicate that the flush is not needed. Link: https://lkml.kernel.org/r/20211021122322.592822-1-namit@vmware.com Signed-off-by: Nadav Amit Cc: Andrea Arcangeli Cc: Andrew Cooper Cc: Andy Lutomirski Cc: Dave Hansen Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Will Deacon Cc: Yu Zhao Cc: Nick Piggin Signed-off-by: Andrew Morton --- mm/memory.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/mm/memory.c~mm-use-correct-vma-flags-when-freeing-page-tables +++ a/mm/memory.c @@ -412,6 +412,8 @@ void free_pgtables(struct mmu_gather *tl unlink_anon_vmas(vma); unlink_file_vma(vma); + tlb_start_vma(tlb, vma); + if (is_vm_hugetlb_page(vma)) { hugetlb_free_pgd_range(tlb, addr, vma->vm_end, floor, next ? next->vm_start : ceiling); @@ -429,6 +431,8 @@ void free_pgtables(struct mmu_gather *tl free_pgd_range(tlb, addr, vma->vm_end, floor, next ? next->vm_start : ceiling); } + + tlb_end_vma(tlb, vma); vma = next; } }