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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D9260C433EF for ; Fri, 22 Oct 2021 03:06:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6DEC861503 for ; Fri, 22 Oct 2021 03:06:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 6DEC861503 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 08B1E94000D; Thu, 21 Oct 2021 23:06:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 039D8900002; Thu, 21 Oct 2021 23:06:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E91CF94000D; Thu, 21 Oct 2021 23:06:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0044.hostedemail.com [216.40.44.44]) by kanga.kvack.org (Postfix) with ESMTP id DC0D3900002 for ; Thu, 21 Oct 2021 23:06:47 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 928992D3A2 for ; Fri, 22 Oct 2021 03:06:47 +0000 (UTC) X-FDA: 78722586054.24.900B536 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf03.hostedemail.com (Postfix) with ESMTP id 6A57630000B1 for ; Fri, 22 Oct 2021 03:06:44 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id C367E61507; Fri, 22 Oct 2021 03:06:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1634872006; bh=hehnqJ0TdJ0oTumpWm2Z7IQhH3FhJbTA99K6hy2daDk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=lL9M+IUOIWxlAjIje/cXUcaqf4psXejtDNY2+TcyvMervYHdDAT+EWywSAmKL2NYG ZrNpKGFzs1nBub0D4XyexXytz9beAgi6j7lhzyOOTIxQUphoIf02tzHvuh7YkCJs0E tYklmMvz6OcoYQhA5j4kBupaSCNwU8MN2120YzwY= Date: Thu, 21 Oct 2021 20:06:43 -0700 From: Andrew Morton To: Nadav Amit Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Nadav Amit , Andrea Arcangeli , Andrew Cooper , Andy Lutomirski , Dave Hansen , Peter Zijlstra , Thomas Gleixner , Will Deacon , Yu Zhao , Nick Piggin , x86@kernel.org Subject: Re: [PATCH] mm: use correct VMA flags when freeing page-tables Message-Id: <20211021200643.770f9d7bd3469b2ec9d6c401@linux-foundation.org> In-Reply-To: <20211021122322.592822-1-namit@vmware.com> References: <20211021122322.592822-1-namit@vmware.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 6A57630000B1 X-Stat-Signature: qqm9wkxdtb44rp4xbccw654n8btsn7tk Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=lL9M+IUO; dmarc=none; spf=pass (imf03.hostedemail.com: domain of akpm@linux-foundation.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org X-HE-Tag: 1634872004-575537 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 Thu, 21 Oct 2021 05:23:22 -0700 Nadav Amit wrote: > From: Nadav Amit > > 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. Any thoughts on what the worst-case end-user cisible effects of this would be? Again, I'm wondering about the desirability of a -stable backport. > 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.