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 9059BC02181 for ; Fri, 24 Jan 2025 08:22:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1EF88280039; Fri, 24 Jan 2025 03:22:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 19E17280025; Fri, 24 Jan 2025 03:22:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 03EE1280039; Fri, 24 Jan 2025 03:22:58 -0500 (EST) 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 D81FB280025 for ; Fri, 24 Jan 2025 03:22:58 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 5541E47A4D for ; Fri, 24 Jan 2025 08:22:58 +0000 (UTC) X-FDA: 83041654836.17.573EF33 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf30.hostedemail.com (Postfix) with ESMTP id 2D3048000B for ; Fri, 24 Jan 2025 08:22:55 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=ubxncmQq; dmarc=none; spf=none (imf30.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=peterz@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737706976; a=rsa-sha256; cv=none; b=ehi5PcLakQhuB172LNUPTgywYqVsIS89hPIN2+EfOPqirC+tVEg7JGR+wcSHZbZoH0ByVZ jKhJZq0Nfqf+GBHERgZmdy7+02fApbtgaHk+DkmGFNuMLpjDmnSPjnSABzlU1myjwgn2YL Ov41op980TyyRZduK829/oMFudpgeOQ= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=ubxncmQq; dmarc=none; spf=none (imf30.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=peterz@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737706976; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=binYfpzYbTrV0P3XYTLlLA8s1eJr7PdgVILx4bbckQQ=; b=f5NiZIul6Ja6qx0vkBjmDfIfuxTQ355NP2AiOuRQ3NQ4hBextjubAiRgIkBTo5hOcvXQCV F+36HSn2hm3CWbEftQGSZQakIJglImVInuRaSK34OLrlDrS4UNpK/ybHT4R4ispjZzMMgS XDt+rvTkyZFNOJsmp/QgXWTYxlzE/3s= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=binYfpzYbTrV0P3XYTLlLA8s1eJr7PdgVILx4bbckQQ=; b=ubxncmQqIdSg3CjTbED6mL6Okn hgWnal1SYpkPYvNFJTwXzdQvD/LvqLR+jEH1VdrMQfOts+dXROUI8Z2KBaqN0nI5+agHuBI+oTIAl SBw/kbPhzV2Yb45wIFktxtIQP01s87m2tDbjTI3rIwmIc2lEciiTtVQHboxinOYQm3jIyhDJ2niIR f7ZEGJGSvsU5rlu1E1oLNYdhAGyRTebYuNVRyQ/COINoEfeVw+kjtCbbq6UplNprUQsxn1hdDWclp FZSokTx69MEp1GGb/To3ohpty5ovbX2ixE0PH25WEuXmhoCpbhadzZB5iYfn6+0XicPSwB2rqaD/1 ptpRk/0g==; Received: from 77-249-17-89.cable.dynamic.v4.ziggo.nl ([77.249.17.89] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux)) id 1tbExn-0000000ERhO-3kmZ; Fri, 24 Jan 2025 08:22:52 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 1D590300619; Fri, 24 Jan 2025 09:22:51 +0100 (CET) Date: Fri, 24 Jan 2025 09:22:50 +0100 From: Peter Zijlstra To: Roman Gushchin Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Jann Horn , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Hugh Dickins , linux-arch@vger.kernel.org Subject: Re: [PATCH v2] mmu_gather: move tlb flush for VM_PFNMAP/VM_MIXEDMAP vmas into free_pgtables() Message-ID: <20250124082250.GA13226@noisy.programming.kicks-ass.net> References: <20250122232716.1321171-1-roman.gushchin@linux.dev> <20250123214531.GA969@noisy.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 2D3048000B X-Stat-Signature: 3s848m836rod8tikrnnwgtqoti3xatty X-HE-Tag: 1737706975-66174 X-HE-Meta: U2FsdGVkX18C1/WLYKbEVJG+6iZ5M64XA7u7t58xIP06VbPt3CjsB4Q7ypwQlfx/ewXOpeeQbZf54VjfFeNjxXWmhIY1NADHRWOI0QBUg6M3yFhdt8ol304vHyhwY6bRs8r8MqvLb8/G0/YY+kTTJ8AI7jymg0T4XgMjv8ZonfcItSslIuE54IKjdIXbo8oqRyABCd9ZRoDKwJQailsUcWYrmOsXecs7y2+9ZN2Adjdy9buUiFNrWL7aopv85cVqt3KSZG05ltiIsIPYXNBdCH6g4U96mYg3KY5XvLF/7j1F2pq6v7rL2mtVrdegdDygPOjxMxHBGJ0AiLkCq0EVr176ePMMO6SY9I1HPR/OVMeLmsL111VHgeb6M5qU3kw1THVCwK0OqQiRmyfH8QXXoEa2jkxlV9VM/Q0omoY7lKz5WWBMOqals9ZKLpkAKjmQARjUoquV/Rq3f2R2JjR9vdcYu9dAaFq0UHkjlDzMir+8yam2Tpv1/8vfTKUTYK7bkrhpex24Tr7/zonFXi5BJ/PohXSEIjf5HtgSCSYzleu1rd5z8GA9OE1rq6Ez0gb1MZryaZYbzDmx/FLjfir3sJoCMXpeDF2VUwJplJI3rPIlX1BRTAtjjd7yauhhhrvAsSMSV1tC5lF9rhTAQTAaGzJM0BzowVGUaqAIhRHZ+TvjVIWliPnwTL0A/mAib9tHslKxzM0N1FDO/pG6y8ITtJdpoW5iP71XhHzAYxIaSiHs1Ff5JKCxMYVZpE+G6Oc3ABT7iQcWjEkG4uO9iNZowfYFRe1Ro8vlc77l+UqX6wIDQgyXHCNMc0KYrwoYUQ06I5MbWlaBJZizeDSSidG5O9cOkcwpINSSPbxQeyTDW+RcItXf2YsGjMtVZnHxD2QfIfvamaibIQKCyWJH0DUqbHLJ4e80XDw2Lm9t5g3MtIxrotwyMm3bhndpiOWlqMkj9gOeU8Q6LjS8ugown5D 7u4eS4vl /n8l/W0h424W+/FvwEtvMiQQg3y6Yo8aOvVzyH7S9NB/brTXONFDLf2vQg88yZwJ+Qp/ceyrKe56hyYfsZQg7DakS2H0UFixOFvgw1rhtPXTFEo8Xp6lrWOZXqPIokO8xWDvy2SRp7+RQyqkemNnl0DkHCClVxBtzbMD8WI9UB0et8+61G/wqxTuleGZAqvkJ3naCDMbMX4KdGKV5HNEwJwIuiKV6ei/8rwFol3NSD2g7t9E= 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: List-Subscribe: List-Unsubscribe: On Thu, Jan 23, 2025 at 11:12:33PM +0000, Roman Gushchin wrote: > > +static inline void tlb_free_vma(struct mmu_gather *tlb, struct vm_area_struct *vma) > > { > > if (tlb->fullmm) > > return; > > > > /* > > * VM_PFNMAP is more fragile because the core mm will not track the > > + * page mapcount -- there might not be page-frames for these PFNs > > + * after all. > > + * > > + * Specifically() there is a race between munmap() and > > + * unmap_mapping_range(), where munmap() will unlink the VMA, such > > + * that unmap_mapping_range() will no longer observe the VMA and > > + * no-op, without observing the TLBI, returning prematurely. > > + * > > + * So if we're about to unlink such a VMA, and we have pending > > + * TLBI for such a vma, flush things now. > > */ > > + if ((vma->vm_flags & (VM_PFNMAP|VM_MIXEDMAP)) && tlb->vma_pfn) > > tlb_flush_mmu_tlbonly(tlb); > > Why do we need to re-check vma->vm_flags & (VM_PFNMAP|VM_MIXEDMAP) here? No need, but an opportunity. > In free_pgtables() we're iterating over multiple vma's. What if the first has > no VM_PFNMAP set, but some other do? Idk if it's even possible, but it's not > obvious that it's not possible either. If we only need to flush PFN entries before unlinking PFN VMAs, then: - if there are no PFNs pending (vma_pfn), we don't need to flush; - if no PFN vma is being freed (vm_flags), we don't need to flush. Notably, if an earlier flush has already issued the TLBI, there is no need to issue one again, but also, if we end up not actually freeing the PFN vma, we also don't care.