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 6B172C27C4F for ; Thu, 27 Jun 2024 01:28:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BD9886B00C0; Wed, 26 Jun 2024 21:28:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B630E6B00C1; Wed, 26 Jun 2024 21:28:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9DC806B00C8; Wed, 26 Jun 2024 21:28:19 -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 7C8616B00C0 for ; Wed, 26 Jun 2024 21:28:19 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 256C614182F for ; Thu, 27 Jun 2024 01:28:19 +0000 (UTC) X-FDA: 82274933118.07.D51A471 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf14.hostedemail.com (Postfix) with ESMTP id CC6F6100012 for ; Thu, 27 Jun 2024 01:28:16 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=PPKdZfSq; spf=pass (imf14.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719451681; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=yovQkK2lk7338SM2N6bhsY0VoxK9Et49OVu+RMi6Mu0=; b=0IpQMg1zQC3RJHmZc//sTbB5B3mUHTEBNwImFIYssSJMhzEp1/2n9DScDMV57Hc3mzJkJ2 seSZZXhjtNHWwmQ/eKHGAiKrsyPPEIFIsMGXHIea4ovqGGYxpsX/hDdfJwLmkC3sG74vQT 3FbPrbKqobG9J2OFr3Iet3SbTj0ge7c= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719451681; a=rsa-sha256; cv=none; b=BZHpDT3yCWNbvfSGd5SEd17JziC9qao67HGVIkGpI/iShEy4xQZxCO4mBv6BzUyCjrQRgx HlaV4Ny4rkv0rQLaA74OYqSyvZrZkRFcam6PyFRe7TvzmIdvOHlw2lN8HOn396i1r16/ci AjHD8rz/3uRLFGAaJ0iSQsCzWBgYV40= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=PPKdZfSq; spf=pass (imf14.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 86D7ACE2BBE; Thu, 27 Jun 2024 01:28:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 664A2C116B1; Thu, 27 Jun 2024 01:28:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1719451692; bh=94WKLEImDrzuXsLyEWQzT3QrnoLJARKqK7LpjuSesRY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=PPKdZfSqtTVbDrXkByiPv/el1lO3mxTUNt5c8JDwKRLgJDC8iyIaDrGNs00riNqRc PF1PxG8R1rJjIgIHvQHf0ACrHsNc/H6wOIS17KLilbGJ2iMdToOmT1U5cBRUDmvOdy yFe0jHykClsuJsX85/2etR5/YbLJnp9FlzyN1op8= Date: Wed, 26 Jun 2024 18:28:11 -0700 From: Andrew Morton To: "Liam R. Howlett" Cc: linux-mm@kvack.org, Suren Baghdasaryan , Vlastimil Babka , Lorenzo Stoakes , Matthew Wilcox , sidhartha.kumar@oracle.com, "Paul E . McKenney" , Bert Karwatzki , Jiri Olsa , linux-kernel@vger.kernel.org, Kees Cook Subject: Re: [PATCH v2 00/15] Avoid MAP_FIXED gap exposure Message-Id: <20240626182811.fa717f7b1051a35af72cebfa@linux-foundation.org> In-Reply-To: References: <20240625191145.3382793-1-Liam.Howlett@oracle.com> <20240626135855.a4b64612a9104ff163e30bd7@linux-foundation.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: CC6F6100012 X-Stat-Signature: 8b9gswhrn1neqc6cu1f4qso8c5z6sw86 X-HE-Tag: 1719451696-739302 X-HE-Meta: U2FsdGVkX18Y4DFB4/gUwAgDVxm8oOTt4c+DCkUYzTPi4WmTNhEyTHLkH4PWjkKlqU7Rbm+oYHBoPR+3cKTNo/KyjLvBtzmAwgnrs6k3/3AjBMgC7LYz8Y+yEEn9KHodExQ4KQOuf8mncJ38iPkVjeza6Gz3Rc1VGhF4Xy6Fb1SmF1lBXdKpDhfPMocSUiBJB0hNKZijhjBBvff2Tx0Yos8UyFBUf6IJ7b1e82jATSmT3Go5MDJ92ivQbhpimnb+6JxRnkWo1rkDQlT9wkHlh4bVMHhkxzB5M9WA8BSeJBIOzSmgvgcEaypdbYXI9S+HwdJoZjD8DHwKdED5TljwY0Wnczr4RSxQTJAsgd1a1m3UF0n0ISVZ9F+xFs7tpzLMfsJCk0pwK1ivgzBt7ij2P6Xca/ax+/tEw5X/R+T+y/e2ItoCOi731F6eQJnTN25ojwhxaJEdEDoLlFWlKjxEurwy+kAxE5SojZ3LGj/3dkIrEvDGzy1B16oA6SJXL7POaC9bOFD6bbnHHDyxHOa4S0FpmWlqspOf0gVwGKvW1VQ2krqrLp2T3SZiq+gStBNnvAjUmPhemgOUtm0FcR60l+/MviXdUxY6ZdQkh/1AcY+miwCsf5IQZ45PmGZIYbWjHE8XQsgFCXfrMgeg2K/rKDHLrZRlb8orxw6j9SXBxrZaK/rwgTG/h6sNS6tKGmOUCp6e9OwC+pq6PCyr14VI3lkHEvsGtslRqA+HB+kwTRHk/PfOzpJnsfTSGhFcQvSYvl1f6qCd5ke3yTWPlyH4mhkgEP2SjID2pgXk1mz6kxViE0otXUkUXZO2FV3izkEaj2Kv8ZO7cuX8uKw/BGF+CoqaL+jbJ7c+wHTtsZplwi6RgWA7AojCyj6lrrti21oUfUAyIZk5BUlmNRQ5EUH0PGLNBcC0tMYNJ2uPl0IHODsLQbv/VU4euuV5umh0t+bX4mv3VKZ7YR/AeGdzE/5 3MG/VDT4 1WbGACfe632jl688FjFyGJImV6tMn+uX7P2VQ3DiNnGw3Jm2kmtEIrsJHheKWBpSQULGIDagypYJSUhZQwe5PcG/HH8xR78/PIw1uu10zN/83KX+TLiwbaJQe+M1QLYisBe46VJ+B+pKz+z/QnkbVVbYwDogBLJuo9tVFo2Yd2p/DNj9JZCckRma4GzF/B5fw4bUlBY4k2oLQqFvu6rjsdF6IL14VsTMAuti+/wRLNQBNZ4+ukUPqL79OYpQp9sIT+NEDZliD10ebu483jWfgR2BkWFoXsO4mzdUeMnGqstDhbBoVOLO5svxQMiqGVoxjjZ9EOjJVZD4/UJkJMacxdieKfqqSo4sv2g5c 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 Wed, 26 Jun 2024 21:15:18 -0400 "Liam R. Howlett" wrote: > * Andrew Morton [240626 16:59]: > > On Tue, 25 Jun 2024 15:11:30 -0400 "Liam R. Howlett" wrote: > > > > > It is now possible to walk the vma tree using the rcu read locks and is > > > beneficial to do so to reduce lock contention. Doing so while a > > > MAP_FIXED mapping is executing means that a reader may see a gap in the > > > vma tree that should never logically exist - and does not when using the > > > mmap lock in read mode. The temporal gap exists because mmap_region() > > > calls munmap() prior to installing the new mapping. > > > > What are the consequences when this race hits? IOW, why do we need to > > change anything? > > > > In the (near) future, we want to walk the vma tree to produce > /proc//maps. Without this change we will see the temporal gap and > expose it to the user. This series was initially sent to Suren as part > of his patch set. > > We also have the new interface for an ioctl request to a vma at or above > an address. I had highlighted that an rcu reader would be ideal, but > proved too difficult at this time. These patches by Andrii are currently > not using the rcu reading method as this and a per-vma locking > clarification are needed. > > Since there were two users for this code, I decided to send it out > before the other patches. OK, thanks. We're approaching -rc6 and things are a bit sketchy so I'm inclined to hold this off until the next cycle, unless there's urgency?