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 18F91C77B7C for ; Wed, 2 Jul 2025 17:39:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A91C06B00C7; Wed, 2 Jul 2025 13:39:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A40F56B00CA; Wed, 2 Jul 2025 13:39:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 930416B00C9; Wed, 2 Jul 2025 13:39:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 7EBE86B00B1 for ; Wed, 2 Jul 2025 13:39:45 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 502C4B8A49 for ; Wed, 2 Jul 2025 17:39:45 +0000 (UTC) X-FDA: 83620037130.17.037D62D Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf15.hostedemail.com (Postfix) with ESMTP id 79847A0004 for ; Wed, 2 Jul 2025 17:39:43 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=u+ntSw21; spf=pass (imf15.hostedemail.com: domain of rppt@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751477983; 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=aZU0Wthv3o2d2DMNe9u3Vpe5xZXHIgdPtCS2QxdaqMo=; b=YzK1R9IX0Oaj5Wv0HUdt4LDHtuzSGfSaFXGxv1T3ZGuWNsQ1EfK+LvSgyBtXVfGOFohUFj 6MAFIjmzn8ct6xoTljEVmfrcm8DUDBDaHhgWwx9gEFGgBgctTPdmzPmeC0+LPPqe/Q208k 1h/Y6cuIJrhDgr2YI6hoRgR3fUPOk68= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=u+ntSw21; spf=pass (imf15.hostedemail.com: domain of rppt@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751477983; a=rsa-sha256; cv=none; b=v/+soAbITxT5YDThreFiGcKWYk8VN6ih93/cxj+m4VnhjArjvC+JdQoGD/ZxSRBLBbx+jZ l4fmorBlzz0HkObpDTQ6rCm0D7fyV0aV5TXx0brHFttOSOS1UziMKT5HcdSqgUpIHxZ7c5 +P8Fx4rocMWylkiZpZ+G4EY46uB8vcg= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 680164580C; Wed, 2 Jul 2025 17:39:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4728FC4CEEE; Wed, 2 Jul 2025 17:39:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1751477982; bh=xC3trem29ncFpuycDPOC2wg+V9X41tPuhVqtAoFYkYE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=u+ntSw21v6rPldOShijw2I+MeAYUVSV88G0JQn/QT9BfNjbjzF4oenOkjWVlpzTVw Vbb+QywarWTsx+IVZcVfITHm3dvrGVFVej6QeH1XLpJgjVeUE4ycFdGqanPylKuS// KvYw33vFlrIZeMtynP0AxtsseOspnKIK60lu9MQhzkjSsRy+ovaov5PymFyNZN62zY 66VUPIURWcBkEmZqnCBxD0e+SskBux43MOobTVHNsk25v94Ehpjo2PY5qybyyci0bv GOOEi10XLNJ/8qwqanhnAjrtv5p30Vf2K6if9Hwu/RNd8czKbWX18agwMVhnOd1l5Y 1E+kZD2amJtJA== Date: Wed, 2 Jul 2025 20:39:32 +0300 From: Mike Rapoport To: Nikita Kalyazin Cc: Lorenzo Stoakes , Suren Baghdasaryan , Peter Xu , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Vlastimil Babka , Muchun Song , Hugh Dickins , Andrew Morton , James Houghton , "Liam R . Howlett" , Michal Hocko , David Hildenbrand , Andrea Arcangeli , Oscar Salvador , Axel Rasmussen , Ujwal Kundur Subject: Re: [PATCH v2 1/4] mm: Introduce vm_uffd_ops API Message-ID: References: <20250627154655.2085903-1-peterx@redhat.com> <20250627154655.2085903-2-peterx@redhat.com> <982f4f94-f0bf-45dd-9003-081b76e57027@lucifer.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Stat-Signature: ku8gb66hjhanzf9rkozfdirz8ofjr7cy X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 79847A0004 X-Rspam-User: X-HE-Tag: 1751477983-918443 X-HE-Meta: U2FsdGVkX1/4b3ZipAVt86ikuukc9Qu7YROJjdkOIsyy5BnkOMiMzN59Q6Ms+0mzcAMIL+IkoPKMzJmFkFfS6KKfYOxfGAdYMnJKlG89xppzip2s10NA0usVoPJeZUtnKgB7v388qiZXwvuanB+hZIalrrK21TMbRwMeYvgHFu5nKd2fwRC47WCSs08QJJBJhMVWcwpwqFdR5C8hywk1/Zj3gy7xylAEzQJSu+JxJ1MHKnsRfarint1DyzSTncGIUFUyClbh1M6lEp9v/VxXX/gO01kPvHWPQb6VLI/oYmv5J6aeE/31/+cI7CgaapfaAVzLzYVSePTxvn1rt6NVyTd17pWuLojXafPEXtutVVqIEJQvfvLIr+OOfDynvv2fYsFEAtmOUacTK/nCSFszJ4t+WH6Jot0YFoKMEKV9Eva85nDJ7xJaoNCBm4svQZsR8T9A9xbSSXp5Zj5V+RT/cDXgQQ65Pp+mjrR8YZX/7ZUTqQJq0+mXqAWRJiRkCYFuLVXbQF3450hW03gs1MDJsgvVPXxFi9eao7m/ShCcce9oRfBGiNhrYvYkb3nVLPVO0UvYBP5D8evVOemzhl8guknl+GUgd6ocXX6jYWFLvaEH8AepBtHdqx1mqtvAlgD5Ojomp5UKezbyQMKk+I3YfQ7ThpO+iDe23WoTjxpPQPrSYR8G81US730Uhe5euEl780YhcpmvCfE/7adLW/MzYjjA5PoANyGaSukxfSTGlJPyoxMtY9kCLFMit++qOa3ytos5Gij81cNxEqpR+EDxXK4M5YwYUdCErDUsjoM8pVawU+GHglykbZ3smjVHOLJiELegQ1G2JvG4BdIrbU0da+zWrg483HkuICwItR9BFn5Tm48DKHG/x9n+jMqiF1bWgdQeeoumCmZmfQ3+DgeGPeBdHEHPB1tB9QptwE+3sv9Mn6sGCOloa2vIaQg/byEt7J80PuGwWOLbPCz/BZX TVVuPaTH z0+/ib8a/hDE1TMZm46TfmbTzlFg0KTPWpDk8JW+8BTVHV+yXgG3I9Y8tosTL3u0+PBOhTwaC8QGadZNv233LiQYsXTA0fRAw4xFucI2Xa39l4LiogEd4HdNbcFaKnqUNj+MapKUMDNSPXhyeKNSh3PpzthtSxzulpz428gkErDMA8JA3f1f1s1Ookoqj1N1I1UNbZqLkJ9IUQg1GS5F1Hx3PO3ATWqOFj27CNvvL3e0tmUO23TftwhnhnCoZVqa3Qvj22llAtYOQ/4Jpgm75MpSUJKOQpZWk5ZkMPs0YIZJIFznYs/PSg2xNmOfQAJEjLHVxy4J+84Exhgk3+n1Fnre1ZPjem4+FNWis5q7t+72x8MoiNFxJrEF+L3OXCGfVKbZ72rqwcrvtFxEg1cJy2zx1nb7kK/0vgF3xg2uljsVVF0Ph/IBxicOc3w== 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, Jul 02, 2025 at 06:08:44PM +0100, Nikita Kalyazin wrote: > > > On 02/07/2025 16:56, Lorenzo Stoakes wrote: > > On Tue, Jul 01, 2025 at 10:04:28AM -0700, Suren Baghdasaryan wrote: > > > On Mon, Jun 30, 2025 at 3:16 AM Lorenzo Stoakes > > > wrote: > > > > This feels like you're trying to put mm functionality outside of mm? > > > > > > To second that, two things stick out for me here: > > > 1. uffd_copy and uffd_get_folio seem to be at different abstraction > > > levels. uffd_copy is almost the entire copy operation for VM_SHARED > > > VMAs while uffd_get_folio is a small part of the continue operation. > > > 2. shmem_mfill_atomic_pte which becomes uffd_copy for shmem in the > > > last patch is quite a complex function which itself calls some IMO > > > pretty internal functions like mfill_atomic_install_pte(). Expecting > > > modules to implement such functionality seems like a stretch to me but > > > maybe this is for some specialized modules which are written by mm > > > experts only? > > > > To echo what Liam said - I don't think we can truly rely on expertise here > > (we make enough mistakes in core mm for that to be a dubious proposition > > even tere :) and even if experts were involved, having core mm > > functionality outside of core mm carries significant risk - we are > > constantly changing things, including assumptions around sensitive topics > > such as locking (think VMA locking) - having code elsewhere significantly > > increases the risk of missing things. > > > > I am also absolutely, to be frank, not going to accept us EXPORT()'ing > > anything core. > > > > Page table manipulation really must rely in core mm and arch code only, it > > is easily some of the most subtle, confusing and dangerous code in mm (I > > have spent subtantial hours banging my head against it recently), and again > > - subject to constant change. > > > > But to come back to Liam's comments and to reiterate what I was referring > > to earlier, even permitting drivers to have access to VMAs is _highly_ > > problematic and has resulted in very real bugs and subtle issues that took > > many hours, much stress + gnashing of teeth to adress. > > The main target of this change is the implementation of UFFD for > KVM/guest_memfd (examples: [1], [2]) to avoid bringing KVM-specific code > into the mm codebase. We usually mean KVM by the "drivers" in this context, > and it is already somewhat "knowledgeable" of the mm. I don't think there > are existing use cases for other drivers to implement this at the moment. > > Although I can't see new exports in this series, there is now a way to limit > exports to particular modules [3]. Would it help if we only do it for KVM > initially (if/when actually needed)? There were talks about pulling out guest_memfd core into mm, but I don't remember patches about it. If parts of guest_memfd were already in mm/ that would make easier to export uffd ops to it. > [1] > https://lore.kernel.org/all/114133f5-0282-463d-9d65-3143aa658806@amazon.com/ > [2] > https://lore.kernel.org/all/7666ee96-6f09-4dc1-8cb2-002a2d2a29cf@amazon.com/ > [3] https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=kbuild&id=707f853d7fa3ce323a6875487890c213e34d81a0 > > Thanks, > Nikita > > > > > The very thing of: > > > > xxx > > > > yyy > > > > Means that between xxx and yyy we can make literally no assumptions about > > what just happened to all handed off state. A single instance of this has > > caused mayhem, if we did this in such a way as to affect the _many_ uffd > > hooks we could have a realy serious problem. > > > > So - what seems really positive about this series is the _generalisation_ > > and _abstraction_ of uffd functionality. > > > > That is something I appreciate and I think uffd sorely needs, in fact if we > > could find a way to not need to do: > > > > if (some_uffd_predicate()) > > some_uffd_specific_fn(); > > > > That'd be incredible. > > > > So I think the answer here is to do something like this, and to keep all > > the mm-specific code in core mm. > > > > Thanks, Lorenzo > -- Sincerely yours, Mike.