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 921ABC77B7C for ; Mon, 23 Jun 2025 17:20:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 227D96B00B2; Mon, 23 Jun 2025 13:20:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1FF8B6B00C1; Mon, 23 Jun 2025 13:20:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0EEB46B00C3; Mon, 23 Jun 2025 13:20:43 -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 F2AB36B00B2 for ; Mon, 23 Jun 2025 13:20:42 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 8D658140ABB for ; Mon, 23 Jun 2025 17:20:42 +0000 (UTC) X-FDA: 83587329924.05.B7F9641 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf10.hostedemail.com (Postfix) with ESMTP id 382E2C0006 for ; Mon, 23 Jun 2025 17:20:40 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="A/Mlnk+m"; spf=pass (imf10.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=quarantine) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750699240; 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=FUTCLfxa/GJlejCeDGSbw2C8zKhkZlTCU7NYv1Imp18=; b=50waF4hZXDVsVnhRzg4J3+qN0FiXteK8fnwqeoYhGtEtiaM+0fUYlwFIJkR1eM8dzmNo/8 9xy2cYDASmBVee/QKiHG1xG43AzAAXSmOXB0DRihIaJTsPtxT91jE80LS5g9wbRgh53fmZ Bft1cDVN+Uh2WxQSj7QFt56BzgcOCf0= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="A/Mlnk+m"; spf=pass (imf10.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=quarantine) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750699240; a=rsa-sha256; cv=none; b=RhtLRKyVK6K84iiR7sR0waOYlO036+ltVTEbjJKhz9nOWRg1S8L69EOdx2m8Tg2ONN3lfW acKE0RWJ93dTNNKtGgkoRYhc6iOO7lNiJvronJKtl4I1YPuh6UxvYyLtUw8zfNpcdy2oI8 PJVdtEdWPbrmXJbJQr05vO9FYQ+UGFQ= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1750699239; 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=FUTCLfxa/GJlejCeDGSbw2C8zKhkZlTCU7NYv1Imp18=; b=A/Mlnk+moDXGa/cAn+a02NnnjxUqhtp4k1tc4tofc/ENsafAvusOakAnNOJdqFE5HYHN8D VneX+7GXWNqDl7GBYVSMUjg8PhvTHytilIBseFXnZ93Datjw2ZPe1d9xgUbIVOLE/EOjKm FOdjw+7M3eMUs3sF29H1UcMIeH5nnyM= Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-281-AROgVreoOqqFZ-hzdnKvKg-1; Mon, 23 Jun 2025 13:20:38 -0400 X-MC-Unique: AROgVreoOqqFZ-hzdnKvKg-1 X-Mimecast-MFC-AGG-ID: AROgVreoOqqFZ-hzdnKvKg_1750699238 Received: by mail-qt1-f198.google.com with SMTP id d75a77b69052e-4a44e608379so131764861cf.2 for ; Mon, 23 Jun 2025 10:20:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750699238; x=1751304038; 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=FUTCLfxa/GJlejCeDGSbw2C8zKhkZlTCU7NYv1Imp18=; b=s3uX6QjZ4/p1SZ7YygZTXy4l9Ygwf868hD7aru/aa9COzSLoyf+d+3m+hSEUPQG7px 3xfTkuvqbmlt580Fg2H05FPdPqec5dHck6j1DcJrE+scCkAW0hdX7xsN5QkLpE8aBQpE 45OK5aq79s4V1COw1DgMyZ3QMMWh52ujdmuSr5b9vADI13HKVVd0ubMvJXKrfuWBt2ux nZB/UJOGzoYvAiw35kBIhPzVRbovv5/lq0BHp3QZCWkWO6XQ8362S+Y/zwdBZO2/DQIQ 43XPK/crRmTKoTf4sdiy87RHEtXF9a6rYtt7DqojnjinHvmM1ox9TJUjr2ItAQ9Efb5K VQoA== X-Gm-Message-State: AOJu0YyjljJRf2rMcwaG+n4ZNHWybvUU2Lk5tBNwc+JFqBopFRHWPaNh hALMBGAIkjGoVHmWo4h3Vg44u+LCBg5HdZffBgFJEDn/Jf47frwtA9QgxJCB9VBlmwt1NwXbaaN 1Yiu1lDiVITMftrFphWYC8TDrZepp4a6SniPLEN2KwlcBTGGswErYWWJC/x4b X-Gm-Gg: ASbGncuc73phHQT2LjDxMpb0rOKtyT2KakPzf9zR5rB6cLzJB3CtDrXrirrLyxIpO7+ ooneBAhlezPsu77jqdQILEpHMT4vr7dnqh87ZuOl5kEWR6+FCl3vkN7AxafTYOj4295aNcWF1BE Q5NSKFlhtWSdr60usAQmX3xjJ6E5lvyRUzapFuiGMJ/7ctB2kATsu/PPneCU4xcPsXkHQ8g5Iir /LaTkZh0iNzZpythwG2dg80WAY5qAOjFQYYbcZ5Db4KmKk9+YdxEE9GdvQMxZ0aU7UKdRUTyR0i DvvmmDHaVerZ5A== X-Received: by 2002:a05:622a:81:b0:4a4:2d36:51cc with SMTP id d75a77b69052e-4a77a24bc8dmr232678211cf.14.1750699237596; Mon, 23 Jun 2025 10:20:37 -0700 (PDT) X-Google-Smtp-Source: AGHT+IE4wi9tQAc/9yif3JCRlqRs0yHTLl1j19VTwOMdX0XNBBM+LuCzlVmiA8DDT3807WworT2SIg== X-Received: by 2002:a05:622a:81:b0:4a4:2d36:51cc with SMTP id d75a77b69052e-4a77a24bc8dmr232677781cf.14.1750699237252; Mon, 23 Jun 2025 10:20:37 -0700 (PDT) Received: from x1.local ([85.131.185.92]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-4a779e5d262sm40388491cf.50.2025.06.23.10.20.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Jun 2025 10:20:36 -0700 (PDT) Date: Mon, 23 Jun 2025 13:20:33 -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> <0126fa5f-b5aa-4a17-80d6-d428105e45c7@redhat.com> MIME-Version: 1.0 In-Reply-To: <0126fa5f-b5aa-4a17-80d6-d428105e45c7@redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 0dGQr9r0FFhlSMcQvG3orRta6vzn2snRTwGrkOZdWY4_1750699238 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 382E2C0006 X-Stat-Signature: 5pb7xdh8fmz4gc15dr3aiddd4mwowk1h X-HE-Tag: 1750699240-421648 X-HE-Meta: U2FsdGVkX19ILq116u8PSDD8xTCPSLaIpVlZNmDUtr8+wF+ASFIPodOsAD2PsiDkJ3wsslCEo01ei0n+rnh6xGYMfQ6yU0exsDJKKvoV5jSi/hmfkRTAnrhypkORQgl0wPCSmOMYvSi7Kf1Hi2CuebWT0f24qcmqk1gEij9dwCtSQ4HMGwjdvmuDbrSAsh8pkPc1EPeJZjDk/kox3GXLkMiu4v15XIRCkTxhrnWaXS66qkkfuqd6dChrlpC3TzmnbQuHb65VAZqm/AtFTA19A3IbbGBVTMgCOpUReEfd6AqxRaxxulPqjDcRbuR+Hsf3Y7fC4dEt4p5h8KWrZH+wLqU1umEqnIQpcvuScLi/kczmgXRVkEomFZ4QCTbewknJNpFc1ifk7rQLxRK/lGR1sSlrGF6w4hcpTOdElac/LKxhhbpunFkHxaiC03qpZy9rDNY6WRhGuJnEFbwElHi5HW6cmH1PSz9zvBqVpbCzyrGfc67Wd1s3BuSTeBmcobLE2oUN6aiwaF+Mse7u25uKJB9zrd6ax7aTTf5YDPBIcWbWpuF0k5JLZjZKsppI9RgRxvmZFUi8uTpCvpRO3YKIn394JnueOrODOmGsBD6PVnD7aghQfcb0YdtYFDN+qflIgAB9ut6g9bcIwZndS0VD1GNV9Z0IqrzjBpYN5rcomX0ingvn5lEH1RYk7UfGbCgCb8SCzFvGBSp6ijZvUFmndDDrpNulg0zb4oxKvMmU9s8FdYrBtZwchlTdnYkFEXRC2qczv6j0JbuKoNRSflyUWOXni3G/sc/w9u/nEMMlW1t/ZF5Q8AX/PDmGmv79N+c/d9/BTi2CJlnNXE4UyLvO/yX3rnoPZvIh9xtD1Zzb0jaFXHSUr19iIwgebriW4SeDHy3S+vp9vxDll/+FAvm8I5ZLATgeEIMxM6jsYJKBfxfS24VSGfwFXIO7snrFjaQtrAwBngZi1gGQfMUlgn/ cFDJRDFj ccP8IpSfw13ax4K9xLXoKDabE26B/w/+j35OhfpNyGa23blAO8ISkyAIdcswxkMzwEUD0De0ei8GSLItGa8EOCbJW9wszLdpEw0IKjggRECim6/KXzfybakQCivky49kz34dKoqXfrjcZhQbLz+FLSPXKU2GsRVmjTXosDzunNtlTx2lsErA+AntJ7Rqm+C0DE+c9qqLkcHQLRII9dB9MSsMuYRo2PdHAfRn5XQ7oZlLWpQhIUkV9fThhLxuqafRn08IE+At7RJLZ34A8eeQOpnM5qGUOOG4+9XrGLmpNyJ8f3+9zubTcQemG4BumTEnuNMa4SmhNM2SZvwDdWg5ZI+xTLHis6uDXrXXkjbawpN6sIekad1Jh73XYw2296PFaQEp5WAxVWgn+PLKYLkJJanWRUcMVkeS4NuQ9T/UaABou3+c= 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 06:50:42PM +0200, David Hildenbrand wrote: > On 23.06.25 15:59, Peter Xu wrote: > > 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. > > I thought one of the challenges of supporting guest_memfd on anything that > is not a special in-memory file system is also related to how the pagecache > handles readahead. > > So ... See uffd_disable_fault_around(). We should make sure no such happens into pgtables when some special type of file is suppoorted, if it ever happens, besides shmem. IIUC readahead on page caches are fine for non-MISSING traps. So a file can support MINOR, for example, but then it'll also need to make sure all those aspected are well considered. > > > > > 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. > > .... is it really "any file" ? I doubt it, but you likely have a better idea > on how it all could just work with "any file". > > > > > 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 files and modules is still confusing I'm afraid. It's really a > special-purpose file (really, not any ordinary files on ordinary > filesystems), no? One major reason I wanted to avoid the term "in-memory" is that we already support most of the files on WP_ASYNC, so emphasizing on in-memory might be misleading, even though WP_ASYNC isn't much taken into the picture of the vm_uffd_ops being proposed. The other thing is, besides the original form of userfaultfd (which is the MISSING traps), almost all the rest (sync-wp, continue, poison, maybe even MOVE but that's still more special) should be at least logically doable on most of the files like WP_ASYNC. When proposing this API, I wanted to make it as generic as possible when people reading about it. Hope that makes sense. Thanks, -- Peter Xu