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 E7601C369DC for ; Wed, 30 Apr 2025 21:44:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A26BC6B00CD; Wed, 30 Apr 2025 17:44:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9D3556B00CF; Wed, 30 Apr 2025 17:44:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 89D026B00D0; Wed, 30 Apr 2025 17:44:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 6D1FF6B00CD for ; Wed, 30 Apr 2025 17:44:53 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id D1F4BC0F1A for ; Wed, 30 Apr 2025 21:44:54 +0000 (UTC) X-FDA: 83392040508.23.C6D083B Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) by imf05.hostedemail.com (Postfix) with ESMTP id ED8FA100003 for ; Wed, 30 Apr 2025 21:44:52 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=BtR+en3m; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf05.hostedemail.com: domain of jannh@google.com designates 209.85.208.46 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746049493; a=rsa-sha256; cv=none; b=IhTIdBNl8djJV72kM0rRTSrKNr0Ua7nuw97PPmioGjOJ7yJpdN43dM4GmtiCzjlkLpM9gl OZ7oVIX/BZ/2t64uWZ2AwM8NzHPCVqgd3pcFizamUBITs2FlMbTpuiLbaW2pAXIZsF596a xZMdaHh2rfmUQw0GqQ/njHVIKhOuFcU= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=BtR+en3m; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf05.hostedemail.com: domain of jannh@google.com designates 209.85.208.46 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746049493; 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=q4h9txxyVkNdC6jvewm0aNetCP9eOddzybErf3K9z8I=; b=EPBPk8PA41BX95o4sIdsrpG3UwWWiaP2IFTMG5VP888KkgzOfweanJCYL/Nwn9SoJjNREQ TC2M6QfOdHyf0UNhHrehvddLFh1CZNla3JNIzXuDAHTmYiBDPjHBz/YcG0lXfwxpJsA7xJ PXOuZgAwzviKRX1IpohqAxJonkOgpio= Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-5f632bada3bso1048a12.1 for ; Wed, 30 Apr 2025 14:44:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1746049491; x=1746654291; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=q4h9txxyVkNdC6jvewm0aNetCP9eOddzybErf3K9z8I=; b=BtR+en3mzT19WkWk+6M0NWbsZtZQ8exCLzgfQk/LQ7eMdXdJeHbQS5uIRWVaB7Nexo vTf8Dggd3l35Dylmi/TVn1wpCywjAvKtZMIxyKvcrnCShvfnlmvQIj7F6XHqmh1AQXRc vAcRP5teTbS2SlObxKKmx/NQyNO1bcmSExq4Fs9bLq0nE15Cv0rSsb02LgUVr+K2Ul2i fVkfY+GkxmJAtKlzDovqyt1YxsWMqvU0UGHcVCltJmm+jm7U68vpNxaCWFqjJUKIRZyd oZPubweABOazScfotI6hbGPUx6xRyhY8w6sknL44Z2Pz3DAAW0meP98cIkKWsqiHhe2e IFeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746049491; x=1746654291; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=q4h9txxyVkNdC6jvewm0aNetCP9eOddzybErf3K9z8I=; b=kVDgGAms1Xh5yenHI00oKShhImQdCzvHliBmcTjeqTn11zPOGMvSdA3H5ICZdYt7Ub BY+Wr0qn4UL/RaUTOlI2hzYLjpsmt7C9hKfpirUqsIu1xmomygoiF4fK4DFxaeHpPReC jRaunCWktlx4Lef96mwCojgfNEzmw+OS91COS2LXiDRxA44JG62S84pAX1Axnm/Bd4Yy AzevcjKdVVhWPIi6MUvnHB7AisHYHOmTa2yxYhyCHDf39IVLXZSScKjggOiQCAvPMedM 2dHlwYhewxudxaNpiUlmsCjvZpHEg2YN3QlsZeGP/WFVpuGh/8f9yxNkOG3YU4Rc8QzC jejw== X-Forwarded-Encrypted: i=1; AJvYcCVp3r0ZgoAFjqDl8y76L09DyD6wHEB66mdW/EbRvClRisnxlhgHXjz0fH9oRU9xfaaxh5J+s/MkTQ==@kvack.org X-Gm-Message-State: AOJu0YwCYJjBH5RHoES2DRseZcFSY3Z9VMqYDotqyV6W4etsxy4KBPZE iPMQw2Fqvv2BKOYE1O8AEiTaBMiEPyFh4UiwgGx/rkBc9uE+A8sEQOK4Gj8OYIlsZSUdk4euN08 2gFhb035faO1ECpDT1rDFLqs+c/Bc6yxC27+b X-Gm-Gg: ASbGncsCe5s5FF/rRtc3uRARfhT4kJyED1EuJrDbQ9aYISuaBfXCXcSgu3d96zBFgqz w/7pML8plAYuMl650TABVb1/3ed7fImjk8gjOQw1GJiQzsjzsGIThUHMfuF2Nu5bWCGTPlqV/rb rY3ftQlMhejNPPsrm1xetQr1eBiRwmpw0N17VTCyKige6G2/pduLY= X-Google-Smtp-Source: AGHT+IHa+YOIrnKiFDXDrrt4yu+9fdIONVUCemFPAqVKkKRm3U9fwx/l3LrvAFu7aPljtxYzM7ACp9bkPJ/XkR4pYL0= X-Received: by 2002:a50:d556:0:b0:5e6:15d3:ffe7 with SMTP id 4fb4d7f45d1cf-5f918c2a177mr8356a12.7.1746049491126; Wed, 30 Apr 2025 14:44:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jann Horn Date: Wed, 30 Apr 2025 23:44:15 +0200 X-Gm-Features: ATxdqUHF1o6EwfzKPJMttuEXJySFho1Hj_S7BrlihxHfp-SM2NszLl-GiZD1uH0 Message-ID: Subject: Re: [RFC PATCH 1/3] mm: introduce new .mmap_proto() f_op callback To: Lorenzo Stoakes Cc: Andrew Morton , David Hildenbrand , "Liam R . Howlett" , Vlastimil Babka , Mike Rapoport , Pedro Falcato , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Alexander Viro , Christian Brauner , Jan Kara Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: ED8FA100003 X-Rspamd-Server: rspam04 X-Stat-Signature: aeonkf5ih56q4c5qcowbattyiehmb4bj X-HE-Tag: 1746049492-513324 X-HE-Meta: U2FsdGVkX19TVXI4tU/p/Ky+eizVCRfNucD2kHevjd5yUXPfOTnizQeepFNQt9CPQMSdZuHcgFWRfU9XrkT/OeKIVmxT9Zz41ggFrtXV8hg3Ope/JN7jncGblD2wMg6P5VHPw2jkYoJBbdZGkeTD/K62FxvA/2dHNgQN3Xc4de5P2hDSXxu5owdYbeTOGAYi6TxnQSl3iSKPY3rNXXRT8PKS9Vf9pHX3dM7e/sDBS9OddEbSGDUkaOn+ZgdEeTZaEEfD9rMMtdZ0hnPtlrLPzZRGBMeDZbp+LO+uawp3AFYmJePK2/aS+nkFCta0FLiTR61okVG165PNGiNSRJesdXSrSeel/QrLrveoNhBJa0R4sMxvXzaJ2A9eiQD4tifHv5oqE9Sp6VkCru/1sx79oldHxBppRAjJSoI3lZXBg8AgtMptBAG0U1xY4bp0jfx2gabURH73F2JwkUtv7aK5sBn6KR+FviRMgm52GbsntY2eiO8wRnmhXuu35Cf+apI9tYc1txypsFE1jisjTjJYrSLiSOxq3OPL+lLIz9E2q7iDqjbAYwutSolr4BuH/pizob8WXkh6rD3sGSx3U/vOP1gf5AOvcAjEzsy9D/O1M7Q7eE41xzDlAbaI17inrXCBRvyd7LaI+huqkjvUSoO2FMUrgR2G78tzR86GkxR5obdPqpR1SbDFcYb2FrRZ5sOWbzTSLymo+UZTXfyJebR2oAqIHMRBPCL9w4hr4t4tvKfsbuH2v8P75eJTHbEDaCO3+90+4qiW1qlnkJ+qgd6FXrCF29LdBB1SsCo480FpAIu5gLW65wXZK/diL6ByevHtb0orDKnSHyGAh2BnQSaaNg7fuHC3c2N0WDvFH3/EKdl0SrlbBevzjnjRM+B96w51SuUY73Bbhow/xAH6qX/jkh0e54asuDZGGGYYAStTlFDjh7Ewm12R5/1IOs1LpLf5oIPhFObqSpMx2Qd+fOE dwe7quXF nlqABSdHWWdXbT+3VtfO55ui7AQc3I0WJ31h9V1NdU8Tul+5m6hI0AEGcOUTyfyRcvpIQEmutc+e5EpgH46hNJoVUJ/eisT5+rizPBDH7Kp4AJswg7Z2XDFVVsd36ODYfGwIWpebWEusChKzo8S9ySg1U6Bn1VI3IHDGDwjvMJEZUt1HJZsTeFUrGWWJNkf+6Vbu1DYw8DrCzeAJthIte592yr9Ak6jTwPurQGvmPJazIIeUZ4JRfiECom+Eg7tB3WuWRfrJaGsDeZE4= 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 9:54=E2=80=AFPM 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 n= ew > 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 heavi= ly > restrict what can actually be modified, and being invoked very early in t= he > mmap() process, error handling can be performed safely with very little > unwinding of state required. I wonder if this requires adjustments to the existing users of call_mmap() that use call_mmap() for forwarding mmap operations to some kind of backing file. In particular fuse_passthrough_mmap(), which I think can operate on fairly arbitrary user-supplied backing files (for context, I think fuse_backing_open() allows root to just provide an fd to be used as backing file). I guess the easiest approach would be to add bailouts to those if an ->mmap_proto handler exists for now, and revisit this if we ever want to use ->mmap_proto for more normal types of files?