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 40AC9C7115B for ; Mon, 23 Jun 2025 13:59:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D819C6B008A; Mon, 23 Jun 2025 09:59:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D59046B008C; Mon, 23 Jun 2025 09:59:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C6F016B00C4; Mon, 23 Jun 2025 09:59:57 -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 BB2606B008A for ; Mon, 23 Jun 2025 09:59:57 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 6D90410377E for ; Mon, 23 Jun 2025 13:59:57 +0000 (UTC) X-FDA: 83586824034.25.4B6794B Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf17.hostedemail.com (Postfix) with ESMTP id 4371A40002 for ; Mon, 23 Jun 2025 13:59:55 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=GD3FMML4; dmarc=pass (policy=quarantine) header.from=redhat.com; spf=pass (imf17.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750687195; a=rsa-sha256; cv=none; b=m5mtTzWx7+giIiSf00GnkBHtMPwP0qmcJ8ZV1ILsVU+rbEGP5PIWH/Sl26xY+OW79Rhhy1 v0j6qsvk9vYpBn7zNSe4lvkefVpSZfeDKEz9PpO+37G/lj5ulH1FOqgFocm2fXa3e7NpJK JShMK7VBJzIK4npbN5V1aexKH5prVeU= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=GD3FMML4; dmarc=pass (policy=quarantine) header.from=redhat.com; spf=pass (imf17.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750687195; 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=rFCUtCrZI3XwUjRd1RBQUfCJP6Am/fmHwP0If9UTQAU=; b=Hmb2gZPAy0IWdjuuJvLppw8GLVqaSPI1gwR0heiF6afv2D/IlHbg0JU/1vjcRfuurW29On GG2/vz1UqWvScDb16Z+1hfI7DM+zycXHUPCgD5xpg/9n5SBT47Zm2J6PE/+jnKfBSKDUHv ZAVLOdfQ/ivqLuEYtkwPSX/OMyDiaYs= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1750687194; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=rFCUtCrZI3XwUjRd1RBQUfCJP6Am/fmHwP0If9UTQAU=; b=GD3FMML4iNrAgm6jAKrlzXrNJOHn4mV0vQ3fz0v4S699yF/0xohfY238FO/7JhUUUBjcPK PToyH5IHWnLy4gJbSEuP+EwqMgRnICLsexPlwWFvWqeFLAj9FuchQcIe7C2bAb7kzW14GZ ipg6we3WyCi9+xs5jc8ENKz6VrWR2JU= Received: from mail-pf1-f198.google.com (mail-pf1-f198.google.com [209.85.210.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-379-JkerNIbFPzuFHkmcdLjLqQ-1; Mon, 23 Jun 2025 09:59:52 -0400 X-MC-Unique: JkerNIbFPzuFHkmcdLjLqQ-1 X-Mimecast-MFC-AGG-ID: JkerNIbFPzuFHkmcdLjLqQ_1750687191 Received: by mail-pf1-f198.google.com with SMTP id d2e1a72fcca58-748e6457567so2871095b3a.1 for ; Mon, 23 Jun 2025 06:59:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750687191; x=1751291991; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=rFCUtCrZI3XwUjRd1RBQUfCJP6Am/fmHwP0If9UTQAU=; b=AuoN9mKLdmxYbgASa60LNP08GhzvZkI4z/ogQ47lG6LNpYZIcdtDEW20hciUpUwe83 RCNn7PfNDALBUAlSs6PlErEz6MRebHpOhd9qkPmZP1Y7isCM3zaJaGeO3vAypF2AKoHE TKfcVJvZ8KDxr4e3qTv9pJ5sZGwvIQqeguOAJfhWmOHZSsRSTy29MWuw+yJApxwrRQyo vZhgag6i3lKXaOFZLZ7yC28zvR/dv4BdFi68nJhV3Q7hmOX5XXVi9qjY1qI8QMbHkmlv hG2bZ5muHdD9ahfxppG9RfX7zCaunDjf88XNxk4laahDmJULMBzc1gzl7qBecv5NMlXT R+Cw== X-Gm-Message-State: AOJu0YyqtM0aekzjB2Y6Ubnvdu30inW8G2fHlCcRyLnrXz2f3Nw9QGU0 x81xvdU3Yc2jVGDErkh5BT/oUQl+oxQCkIOcJ8mviv1yU/R1hF1JhQpp/vvc30BiG90L/HJnK6T UgyZbloU/5a/jZokE4n/8ZzXv1SsnfiUYzze+ZrYuvLb1N5UBBWwi X-Gm-Gg: ASbGncvIPzY92W8cFCWBY5jacTAlMnuOC+DgK9gNRjo4CT2xwTny+VE6DGb7xU3WdJP OtFlzseXKsgayPiylhJrOkecei7s8Eai9gYrFDdEKWduBd/mzygHYH6S+ONud6NbJoquPj3dily qXoRrBMhUyW9kjl9U8bji/5/ImQiV9DOBAKRVBF6VlBh7ktLLjEVG3mUob/0b2dIif34m74xswX Z9sQN4dBR94R6GDT+RYN5gYyls6ISNy8NmucSScdD+L7pvSf+QUfUNdIMHVpm+W8jFX/QOYNl6Y F5jRgGRDSPhtWA== X-Received: by 2002:a05:6300:4041:b0:21f:5283:4fa5 with SMTP id adf61e73a8af0-2202915816fmr18004413637.3.1750687190998; Mon, 23 Jun 2025 06:59:50 -0700 (PDT) X-Google-Smtp-Source: AGHT+IE6NpXKYqUvcSGG47iYa+FuC9QWAsS+KzKQzU8hUE6O+IEN8c6C91PazULTEaTIjQTXiq6Egg== X-Received: by 2002:a05:6300:4041:b0:21f:5283:4fa5 with SMTP id adf61e73a8af0-2202915816fmr18004375637.3.1750687190506; Mon, 23 Jun 2025 06:59:50 -0700 (PDT) Received: from x1.local ([85.131.185.92]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-b31f12423e3sm6894018a12.47.2025.06.23.06.59.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Jun 2025 06:59:50 -0700 (PDT) Date: Mon, 23 Jun 2025 09:59:44 -0400 From: Peter Xu To: David Hildenbrand Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Nikita Kalyazin , Hugh Dickins , Oscar Salvador , Michal Hocko , Muchun Song , Andrea Arcangeli , Ujwal Kundur , Suren Baghdasaryan , Andrew Morton , Vlastimil Babka , "Liam R . Howlett" , James Houghton , Mike Rapoport , Lorenzo Stoakes , Axel Rasmussen Subject: Re: [PATCH 1/4] mm: Introduce vm_uffd_ops API Message-ID: References: <20250620190342.1780170-1-peterx@redhat.com> <20250620190342.1780170-2-peterx@redhat.com> <1e6fcebf-f74e-46ad-912b-d7df13527aea@redhat.com> MIME-Version: 1.0 In-Reply-To: <1e6fcebf-f74e-46ad-912b-d7df13527aea@redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: G2oHJ1HSSH4bnhIURhloOO3ZUICAJoDnbM06mXZEci8_1750687191 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspam-User: X-Rspamd-Queue-Id: 4371A40002 X-Rspamd-Server: rspam10 X-Stat-Signature: 8y7fd199wfgze9cydkdjsmiz87xgksie X-HE-Tag: 1750687195-798801 X-HE-Meta: U2FsdGVkX1/stDSZ+Vo7PLPTZDSFWEzuAsv2w/oGX2WrIiZ96eteDND9Co0K+Fxu5Qv9PfoGtQd28V2/xiolS1EpJnv836mfU/DT+U/jyEjpcyPS8DGesTagHRT8vfEdOyoQtJmHDKy1kWrZ8wtywrcjA/bpNuoDB4hIDLBdW/4hyLTMWnydLmv/CL9+QB4TI7Ssk7T+KUmp48UO6+ts6+3p/iV9Izq3ZE1u6zFeyLtqJKKR3nW654geXRe5o/IfLYSiGottBM9b5fn3N1wpmOq6V/qKOG5XCv+Zd/HDH/e8YtniL89+Mz5aO32rlTgHCgQwDmYlmU2Lk5YatiSlvcR7OMefCCOrt3BCtJ7c+xQl32PSlxuR2/e7zs6vh+D6MaUbuDGZSouT2CYodDfH+PmVVaxfmW1qpXkX60y1Q/QblWa5dODfeI0duzPvOrE5soHooR/U29THzK6JK1/9sgwENngCZPeAjIiCF0MkG/vH3z02WYLcu8lrYypoZbl+qeO6SjyiafijRSxgTO3kjGJQku3XETwMmjjIznUAylV51jm7XgoRluiarKbsIyz5tsDwLg5FYQw1LNu/XSdNFXjZBpvdYZ0iwUlCjIbiNUy/Uy6tM3eTwr3fPQ2gMuMV1AHkavvKzen+Lrlj5q4/BKn/1BwEZo6uJafA4FhkVehs//e7FfwSpm6cEWnd6Yp+mVBbO94wC7Lrxqau+i4dIi4ggtRhcVMRrMOc5oQWg80YTlWFWxnVD83nAaJPdZogEaHZ4LHM75zUPYE3t8d6D4cqeifNYGVqA90b7/Sn0M2cwAi4cOS0nvogXtKN7SutfDBkRynX7q9IYg1Cw/jUTwyY59R7dxc1VH7eowdiGZ6p0574Nfg3mRaKGbJ1UgcjikHe7eNOG3OBM9DwH4Q15BbStEmxxO3E3kjSQkje1uniaNf38njmmS6IHrn6EspMPTH8zH94t19ORoCg8tn l0FGgR5X gPF1Of7qV9YlkIHOfyala/60daTQXT4CsHrj19zxEv6FSMztJHQRoxa58m5kAMqlxk9ih1Egv1F0iDRFZ31HQYnJ+X2n5c1EdCMonTQP1U4f9ekln2cLe90xMB1X2M4wIB9szyO4tHumlS1SkApgamX7K7Y+JhHZ3V4dWanPYYek6Lz4QPkyp6Yi7D3n9MfVBaXCGcAvVHLNX4FXjtPGhmQAvFJxrcsphO9IDODUG7QxROA7mmASEDt/UF0MvivLU+MahlJDPVNV28tP0eSUagnIh2MbF/yukPWMndaf00krko9XP2pR3wqP1Ga7ghiBorOwqD3MGf0Sqe3xjBmhaMkajuaVJC2tU3zuaZjW4OdwuusEDdaGxk5IPa4fj1OWseH2xiiX4vUrs8Bkl09ZcQSYZi0/ZrGw/P1ESy50kN52uEBsn1CD1WhpuiW7VVY/eZ3WA73AtupmQVE0= 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 Mon, Jun 23, 2025 at 10:25:33AM +0200, David Hildenbrand wrote: > On 20.06.25 21:03, Peter Xu wrote: > > Hi Peter, Hey David, > > > Introduce a generic userfaultfd API for vm_operations_struct, so that one > > vma, especially when as a module, can support userfaults without modifying > > The sentence is confusing ("vma ... as a module"). > > Did you mean something like ".. so that a vma that is backed by a > special-purpose in-memory filesystem like shmem or hugetlb can support > userfaultfd without modifying the uffd core; this is required when the > in-memory filesystem is built as a module." I wanted to avoid mentioning of "in-memory file systems" here. How about an updated commit like this? Currently, most of the userfaultfd features are implemented directly in the core mm. It will invoke VMA specific functions whenever necessary. So far it is fine because it almost only interacts with shmem and hugetlbfs. This patch introduces a generic userfaultfd API for vm_operations_struct, so that any type of file (including kernel modules that can be compiled separately from the kernel core) can support userfaults without modifying the core files. After this API applied, if a module wants to support userfaultfd, the module should only need to touch its own file and properly define vm_uffd_ops, instead of changing anything in core mm. ... > > > the core files. More importantly, when the module can be compiled out of > > the kernel. > > > > So, instead of having core mm referencing modules that may not ever exist, > > we need to have modules opt-in on core mm hooks instead. > > > > After this API applied, if a module wants to support userfaultfd, the > > module should only need to touch its own file and properly define > > vm_uffd_ops, instead of changing anything in core mm. > > Talking about modules that much is a bit confusing. I think this is more > about cleanly supporting in-memory filesystems, without the need to > special-case each and every one of them; can be viewed a cleanup independent > of the module requirement from guest_memfd. Yes. But if we don't need to support kernel modules actually we don't need this.. IMHO it's so far really about cleanly support kernel modules, which can even be out-of-tree (though that's not my purpose of the change..). Please help check if above updated commit message would be better. > > > > > Note that such API will not work for anonymous. Core mm will process > > anonymous memory separately for userfault operations like before. > > > > This patch only introduces the API alone so that we can start to move > > existing users over but without breaking them. > > > > Currently the uffd_copy() API is almost designed to be the simplistic with > > minimum mm changes to move over to the API. > > > > Is there a way to move part of the actual implementation (how this is all > wired up) from patch #4 into this patch, to then only remove the old > shmem/hugetlb hooks (that are effectively unused) in patch #4? Not much I really removed on the hooks, but I was trying to reuse almost existing functions. Here hugetlb is almost untouched on hooks, then I reused the shmem existing function for uffd_copy() rather than removing it (I did need to remove the definition in the shmem header though becuse it's not needed to be exported). The major thing got removed in patch 4 was some random checks over uffd ops and vma flags. I intentionally made them all in patch 4 to make review possible. Otherwise it can be slightly awkward to reason what got removed without knowing what is protecting those checks. Thanks, -- Peter Xu