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 46DAFC3ABAA for ; Mon, 5 May 2025 13:29:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B9A656B0085; Mon, 5 May 2025 09:29:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B6EFF6B0089; Mon, 5 May 2025 09:29:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A379A6B008A; Mon, 5 May 2025 09:29:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 822416B0085 for ; Mon, 5 May 2025 09:29:15 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id CEB04BF9EB for ; Mon, 5 May 2025 13:29:16 +0000 (UTC) X-FDA: 83408935512.28.45F47DA Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf09.hostedemail.com (Postfix) with ESMTP id 37684140008 for ; Mon, 5 May 2025 13:29:15 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=dnKa1edm; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf09.hostedemail.com: domain of brauner@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=brauner@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746451755; a=rsa-sha256; cv=none; b=gjHFQa+uLvsDuu3SctNS+5cJkDwtUF3ed036pxU4vyALgM/em1OD8kcgjoSxqxG+TtTvey 8sQHQ/6NU7EVvcT0HqDvTdad3SsnAyQlnFCzh4gFmATuyCR2ewzSMUr/pegZXd4l3GZ4b3 BR22z5ytOd2x8vSlkxAzgYtDaAPG+8o= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=dnKa1edm; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf09.hostedemail.com: domain of brauner@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=brauner@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746451755; 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=m76TEMztu/U+9bUcvVpJdhZTQXtPorkQ5r8m/0LXqHs=; b=Oxsy56tQ3RPmV8GxYgdof8QdyIZlbdYUsVEeLex/Y3JIrZtbtZvE1nzdCeXXnmvpNaJnEO Q3yc2NE5v1PidvJoCKTis7bEWflizLScgJ9FVJLlK9xeqBrOxuRrSNoejhlQFrjN+Glc3A kLrWPgvY4hb+FDNAF/hndG3e8NW2gd0= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id CB52EA4AC39; Mon, 5 May 2025 13:23:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0EE50C4CEE4; Mon, 5 May 2025 13:29:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746451754; bh=B3/FRvlQ4Ek+yQv/ze582YtVqXmXHDnQWRaAtVxCn8A=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=dnKa1edmjn1Cn2AsWiz8IKivzXXO6qPQ9v4dBHB4S+nNyFlvbRWKTlsZsWX/Lsqgg f+omQXZhpmhCWtT6p/zJ7aRS6x/7n+vFZ3whQ+v/cfyoSDzKE11JUbZrfYy1yq+tg9 k1e6IRASfwrs8zrH6nxfF4CHhFRMNMHcQV44wdluXOQzQ/gH5+//YYDJRWpM537/ue eI99p/dOow/mLjMPwkXd3CL7YmzM7mxCxTG4mhew3qQTiz9ZPAvVxottlMAmp849gK UT/msChtLHn0vDX+PMq9dCaO5/1K/4hKYohCzsy6emg0XBjJCIp02mtYj3bidDjKQl S6oC6fA7PxJeA== Date: Mon, 5 May 2025 15:29:08 +0200 From: Christian Brauner To: David Hildenbrand Cc: Lorenzo Stoakes , Andrew Morton , "Liam R . Howlett" , Vlastimil Babka , Mike Rapoport , Jann Horn , Pedro Falcato , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Alexander Viro , Jan Kara , Suren Baghdasaryan , Michal Hocko Subject: Re: [RFC PATCH 1/3] mm: introduce new .mmap_proto() f_op callback Message-ID: <20250505-woanders-verifizieren-8ce186d13a6f@brauner> References: <7ab1743b-8826-44e8-ac11-283731ef51e1@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <7ab1743b-8826-44e8-ac11-283731ef51e1@redhat.com> X-Rspamd-Queue-Id: 37684140008 X-Stat-Signature: 1b7jter74r8y34m9mrymsixkuardjpky X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1746451755-916845 X-HE-Meta: U2FsdGVkX1/DPELEYDZ5cAlDyXNsBydOF8eE7dqo9SNBJ9yXtTQ7+YI7dsQXc1PmILEMsEUT4lQK/WnRDM8TI1K3njoE4mOV6zO1od479oFbSFyAhlG47AqCoaK19rxR/NgWQe5HJBTnhaxDMoFvBF+JhTrZNLgpRfYdvrn1Ojj52HYmB+qz3yzZhg8E+jnDk0io891KJFelmV1TKyy0Rw1BwYqHwZ+hMZDujw8Az5dOqC8HA2I6cs2ZzgNkyFyAYOF1IMyhwGDOdbPC7WmNzXZ+LoYB5yV7HvH6NW3JlRSDRUvYjVrEsBK64KqYUnkZevy4C7x6Pkl5P6vpiM/+7e7ynAA04LOUjLDckrqtf0opVBErDQHN06p5yHVm6Emytb0T2pO7nF2sSIn3nZby5xjpT3KFlv3GF2/qxurcAhNJnsKPOSmn1psFGnciHgiG1AqZfmKo/nutwc34p/Fr2rOzRgWY0OQWhwDR5C4gXPUQo2LtmTSzU8Gpj2MM4M2miuSxZBCc/422Wo+xL/BkzixKT2OQmbEQhc3G7+UuErBPYaRBoyTARmcawIe8vHK4xv4hSC/hPBlBG94bT2eT3UMpChJmBDk1kwsqYXmpKuayXkRhbbXx0SL5PxB8UcUEga2Zi0xp7cbUPqPjfFOi5Dkz0vkCrCjas0ENJI1d7sgIPSJCzFieLzkhn1GSBB9z12FFbKAWsf4TOzmon1o9qGpS9lsoQlZEvFanU/J6bKMGCFHMIYn9t19CiakHlY+wphDi6KW/VVdMQ01eQ0LxaqhCuFJU3FYaburLt5U8FeU2+0DyLtt8lzp7ubPaxzes3JjNyWc6w4jvofo0wbhE0K05Q4TsSGDgni2g/9d3A3SB7hoLniLpx97h0AJjC4ZH3rqBWoqteDYWf2g4qOYkmiaQaHG0aUdFAoFlNXsxlve11ocyuLtOXrqdC/YToGOmazfq9ToYWqrifOLaWyW xFibj+F9 +5w2RUWYOkQb/DMu7wllc/ktAJ/AJuueXX2ANS/VV9Pe6VEscYaKwPjuE0e6K4Nt5YHtUjggBAIf+zVJMp+vNWFG97KUCW0YvTT2xMB3nkEZ6l0pTPiiYlNhYfQhhP0w/G61Rc0tx4BaKAW4FNsRqhqTFypHrIm4uQMfnZD/DJgd3g9N3p/Bk7Zjk7xbGoU/4FxEexgjLUwRgYtgUJhHMDv7kvB4BpfUtEF8QEviFqzkTN+EjQEq9RYygdqDv/+n71MN/AmVu/1i6XNHbArCIX0W76L9OOoNxAqxFG1imic0SOrKiGOj3AV/2wl2+WPVEyUZhSjdp3rByoOafelxQ9m2NGZuYiqmllmxaWIpzn74LKQ+c3e/gl+Wfow== 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, Apr 30, 2025 at 11:58:14PM +0200, David Hildenbrand wrote: > On 30.04.25 21:54, Lorenzo Stoakes wrote: > > Provide a means by which drivers can specify which fields of those > > permitted to be changed should be altered to prior to mmap()'ing a > > range (which may either result from a merge or from mapping an entirely new > > VMA). > > > > Doing so is substantially safer than the existing .mmap() calback which > > provides unrestricted access to the part-constructed VMA and permits > > drivers and file systems to do 'creative' things which makes it hard to > > reason about the state of the VMA after the function returns. > > > > The existing .mmap() callback's freedom has caused a great deal of issues, > > especially in error handling, as unwinding the mmap() state has proven to > > be non-trivial and caused significant issues in the past, for instance > > those addressed in commit 5de195060b2e ("mm: resolve faulty mmap_region() > > error path behaviour"). > > > > It also necessitates a second attempt at merge once the .mmap() callback > > has completed, which has caused issues in the past, is awkward, adds > > overhead and is difficult to reason about. > > > > The .mmap_proto() callback eliminates this requirement, as we can update > > fields prior to even attempting the first merge. It is safer, as we heavily > > restrict what can actually be modified, and being invoked very early in the > > mmap() process, error handling can be performed safely with very little > > unwinding of state required. > > > > Update vma userland test stubs to account for changes. > > > > Signed-off-by: Lorenzo Stoakes > > > I really don't like the "proto" terminology. :) > > [yes, David and his naming :P ] > > No, the problem is that it is fairly unintuitive what is happening here. > > Coming from a different direction, the callback is trigger after > __mmap_prepare() ... could we call it "->mmap_prepare" or something like > that? (mmap_setup, whatever) > > Maybe mmap_setup and vma_setup_param? Just a thought ... > > > In general (although it's late in Germany), it does sound like an > interesting approach. > > How feasiable is it to remove ->mmap in the long run, and would we maybe > need other callbacks to make that possible? If mm needs new file operations that aim to replace the old ->mmap() I want the old method to be ripped out within a reasonable time frame. I don't want to have ->mmap() and ->mmap_$new() hanging around for the next 5 years. We have enough of that already. And it would be great to be clear whether that replacement can actually happen.