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 A6D77C77B7F for ; Fri, 27 Jun 2025 15:47:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 49E1F6B009A; Fri, 27 Jun 2025 11:47:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 44F336B00A4; Fri, 27 Jun 2025 11:47:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 38C676B00A5; Fri, 27 Jun 2025 11:47:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 2B2056B009A for ; Fri, 27 Jun 2025 11:47:06 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id EEA6D1A0148 for ; Fri, 27 Jun 2025 15:47:05 +0000 (UTC) X-FDA: 83601609210.22.D82D1EF Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf02.hostedemail.com (Postfix) with ESMTP id 8548880014 for ; Fri, 27 Jun 2025 15:47:03 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=UgSHixmw; dmarc=pass (policy=quarantine) header.from=redhat.com; spf=pass (imf02.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751039223; a=rsa-sha256; cv=none; b=fbjAn+zlPWQZkwxDzE3UUoy9DowvIJjZm6F1bQqnMHNVMMIPVyrdJ7+go0qvvR8dgzV99G Wp6XzQuxKHH/JeTbDtbFfM3QR3HBzm2cv0S9AINAHHWqTm4wTqsjA6WcnJI3GB82CpX8VC lF1IfUHjqWEknpzmTyhbVihiZ0+UOTE= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=UgSHixmw; dmarc=pass (policy=quarantine) header.from=redhat.com; spf=pass (imf02.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.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=1751039223; 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: references:dkim-signature; bh=0bdFHs9p3a9DLGABFFRxwJzNp5SY4wkEnyk5Yb2CJC0=; b=HliGmNELY6IGRU7nnWx2lVBucS7NHp19ObYXoUOykpj7o8lyHPcVqu/QS399J2QHckqDhf fxj7a6/TfTvK8qR0yk8tqxpmkB7NPAXAP7tnhKef1PPeu9PuXHTBhyPZ+cmsp8B7OEVLIr JuoXnO4TK8W17vil/Z7pe5wASb/a9XA= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1751039222; 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: content-transfer-encoding:content-transfer-encoding; bh=0bdFHs9p3a9DLGABFFRxwJzNp5SY4wkEnyk5Yb2CJC0=; b=UgSHixmwA4DrbNE2ynV+vnNU6tYrU+TK04PSOxoS3vvCvxkpbQg143trJOYZN0QJC4nTxH zyIQ/VAUv5JO6jIniypbj4YqKmPKOJAmmW1rtNtBhSBWkavDftXjRaRaloCSQly+04nlWI JRczW6LQ/zFl0Qa2evk8Vwq+Ci2/d/8= Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-484--Z69AqkDMxSfg8Jj8Iip-g-1; Fri, 27 Jun 2025 11:47:01 -0400 X-MC-Unique: -Z69AqkDMxSfg8Jj8Iip-g-1 X-Mimecast-MFC-AGG-ID: -Z69AqkDMxSfg8Jj8Iip-g_1751039221 Received: by mail-qv1-f69.google.com with SMTP id 6a1803df08f44-6fe182a48acso36509686d6.1 for ; Fri, 27 Jun 2025 08:47:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751039220; x=1751644020; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=0bdFHs9p3a9DLGABFFRxwJzNp5SY4wkEnyk5Yb2CJC0=; b=qF++YIOKEjNsKUIdZstnR7Z4dmRBQ3VwQfD3C5XUfBbA3x9NuujylyZvoLOq5TwV6L iNhEe2L3kJwTtsZM6+C8zE8yMb/IRZcCOVCR2ovjVzxklBSjlgQPTn+xr+LdjBXR2wSS DzEispXIgw5htYH9lJrSGVkHKeiLQG6IsyhuVxJTY+RgNiNjqtyq7wG3GDf+wFZI/ES/ DRkZKmioGsrd79PIavTvHT88IXkZXS8UghKOofZW9x2mGmPCmmHlFCDpheRjh5bc7FFX wgfjY5bcLcHhDLUDWhtkBvZH+N0W4ZZozJASaRlC67sv7bZpZftKiOsppgF6Q1MpZFDO JD2A== X-Gm-Message-State: AOJu0Yxe60p2sWg0CCUC32c7b9KLhLOVqzPcjREzI1I+YyslOIrjdWdF EqEFtl1khWFV+F3iIdGdQ8FRbYI7Upl3CBVtYmxbShiPG9vhRvVzs22fcVpcprwOCCWaLmtrEND 4Qf2fJ2uPobqx+PUK16Lu54dUvlWGPCOgzvKUHpYHe4v7nkHKlK4uEat8kDf1yXx3F4mPNe8R0x rratmB2J8PPzsY3TcyrPQv69IB68XYz1/WAw== X-Gm-Gg: ASbGncvKS/SABBoGmavmW0ToTQxUbxU0eA/0DsRWcB2+7UusC3/HJtoyXDDMsv6og2q viHw5b3UlLh0iMtyOGMzvP2eOJsuqYyjxIk4khZ6OnUXaKfDJlkoSfwrzCLRwzG0Gi/fVNArG4F hAofoPCyuuY+uvtHZCuEPE97XwMOMsO+1PZyiU+mwenimkVLxZV0gi30iIyZunO+jE4PFkVQEuf qYLi3CPhe0hA75UHC9eZTaXhAD1lQn3QqXC9jPOJXSEbx6bWGEjdRUgdl6R+aWFlj/br4GqHR3h 8Ef+FZXO2eg= X-Received: by 2002:a05:6214:5e02:b0:6f8:c773:26e with SMTP id 6a1803df08f44-6fd753ef035mr119155416d6.18.1751039220363; Fri, 27 Jun 2025 08:47:00 -0700 (PDT) X-Google-Smtp-Source: AGHT+IG44eVw4vUj2kFFXrMBgV5/0Vh4Tk1pXdy+4X+Wqxm96LVr3x614NuzYADZbznjUe20Rx+BZw== X-Received: by 2002:a05:6214:5e02:b0:6f8:c773:26e with SMTP id 6a1803df08f44-6fd753ef035mr119154796d6.18.1751039219759; Fri, 27 Jun 2025 08:46:59 -0700 (PDT) Received: from x1.com ([85.131.185.92]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6fd772e4fddsm22296066d6.65.2025.06.27.08.46.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Jun 2025 08:46:59 -0700 (PDT) From: Peter Xu To: linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Vlastimil Babka , Suren Baghdasaryan , Muchun Song , Mike Rapoport , Lorenzo Stoakes , Hugh Dickins , Andrew Morton , James Houghton , peterx@redhat.com, "Liam R . Howlett" , Nikita Kalyazin , Michal Hocko , David Hildenbrand , Andrea Arcangeli , Oscar Salvador , Axel Rasmussen , Ujwal Kundur Subject: [PATCH v2 0/4] mm/userfaultfd: modulize memory types Date: Fri, 27 Jun 2025 11:46:51 -0400 Message-ID: <20250627154655.2085903-1-peterx@redhat.com> X-Mailer: git-send-email 2.49.0 MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: sfFtGsOUJlv7AzH-N3BQrQCllU7bgYz7ttFdb_WPzeU_1751039221 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Queue-Id: 8548880014 X-Rspamd-Server: rspam10 X-Stat-Signature: w4ewk1jfmnn59dfpem7kiiixoygx7d4z X-HE-Tag: 1751039223-715444 X-HE-Meta: U2FsdGVkX19vMGxJhxbrh1z4Huzi6r0YjzLa1CQw6wrPCpDemoPUdhlxyFCE0c+Pwe1lKgf+gh+AqGot+mFhAl+sKkMU8JxCA75h/QX4krPpUs+ttxy077ZVM+9c2dFucT5X/9naa4WBQaIggyIOy1poGPXCqdwwIQr4Z19ApltDQ5W6oVljuoCPXyxgFKKRfdLqPzXJzlgCNnhvpcfZfU7OeIkl6lHGf2LkQwmfV9Oem95YFTHSCyqLvJpqDs6tEsNWXCuX3NT26z+C+nOPmpJLZ3wvfVcfyY2vaj15CDtDeLB690fRR5c+P+P+QCucWwXt5Q6j2TauKEEAAVzk+dI5IH8/WTOKUYcMi3j7OEt0XQnSeJ22FFmInI5ukJ7rKivbiJ+zR846FqcjdcJ82K2VAcGCJuoO0m5C11k1ByAqOGXYm+em/I6LwrayBso7C5pctSxiPQOEPy4jE4rmZNeeoEH0VqJjxM7appQN6w8+G0nawH4NM2q+tEojv0zJ2BFcM9bm2LVrkTj2tw2vFscEv0Oh6qMfJsNSsm/bScYl6+lnJesourhGQ3SrnHkenP8lUwyyMHcutu/0OgO5jjgNHIna2M7r7V4ddUs9a3i0RqpdgE3SOOtw37dVvzboPXEuWrpTlLy0icTgtyioyOoi8fXESvJuQrPs91fEBL7Iwl3bSPesY4VPPZMyaqx5heWK98z+/yOAxaFBi3f23pBRsrn7EbBZdvgBy/dUyAJDX46hIZTixJvVlelvjoN6a3NIV/jBdK0SiclE7L8H2+LhxglUDMTlICMbtFti7NjcwF/RLZ/lWVZ7Kov9sq/SWlUMee2tWFip+QZ3MEfZwNMq3vN9x7JW82qeTxuCq5cnFhdXHZn9jHT5SGm8sabpF+m+IggGxPP2j76oUdOCrgOD1dpESDR61vzkOBZ/MwEJGmiLxnJL+nlsHUkT9eT6NC0ISu3ltMRCtr7kYEV XzJ2Rl1v 3d2wd4vwDRLnw0SMVvmqzgHK0cDfRH2MqJJFZ1X7bq0Dn3YKHDF8VbyO9DNuCzXdm9Nt27K41LYlQlt48Q6D743IxsX3+AnFQaQ1amYGR+4qLkeGa3KtUG14xY/YS0dcBre4fRSWRIuVZrfLc6RkTh+jv5htdVGTWz7EqZlzL1eLMCrBK4x8Tt3a+4Wai1R3cj6hnPZUoMIsWV/72TVI2y/qH/XyS1cyronn/tF0MpI6VX62CihZz5c/VCOTnmQe5OY2tapp3sy7KfVTvZgfvAb4R/xvU6lBoPfPtSRxElvf0J211y8/zFD0qSXp99XFuObU34bH9wVNzqZVMjMAcGjP3eEfbmpCKh5wPGY8Dp6B3MX54sO3fpzfK9v84gsEkjNhkbgkjO94DCgo3sPa6fO9lWa9Qf1vtHpsL41lbYW7tukTvGfSeO3y6s0eheQ15VKMOPzA7OXz5ahc2k/ABBkkPbrQNXN7mKksusYKtOXYZ9oI= 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: [based on latest akpm/mm-new of June 27th, commit 9be7387ae43f] v2 changelog: - Patch 1 - update English in commit log [David] - move vm_uffd_ops definition to userfaultfd_k.h [Mike] - Patch 4 - fix sparse warning on bitwise type conversions [syzbot] - Commit message updates on explanation of vma_can_userfault check [James] v1: https://lore.kernel.org/r/20250620190342.1780170-1-peterx@redhat.com This series is an alternative proposal of what Nikita proposed here on the initial three patches: https://lore.kernel.org/r/20250404154352.23078-1-kalyazin@amazon.com This is not yet relevant to any guest-memfd support, but paving way for it. Here, the major goal is to make kernel modules be able to opt-in with any form of userfaultfd supports, like guest-memfd. This alternative option should hopefully be cleaner, and avoid leaking userfault details into vm_ops.fault(). It also means this series does not depend on anything. It's a pure refactoring of userfaultfd internals to provide a generic API, so that other types of files, especially RAM based, can support userfaultfd without touching mm/ at all. To achieve it, this series introduced a file operation called vm_uffd_ops. The ops needs to be provided when a file type supports any of userfaultfd. With that, I moved both hugetlbfs and shmem over. Hugetlbfs is still very special that it will only use partial of the vm_uffd_ops API, due to similar reason why hugetlb_vm_op_fault() has a BUG() and so far hard-coded into core mm. But this should still be better, because at least hugetlbfs is still always involved in feature probing (e.g. where it used to not support ZEROPAGE and we have a hard-coded line to fail that, and some more). Meanwhile after this series, shmem will be completely converted to the new vm_uffd_ops API; the final vm_uffd_ops for shmem looks like this: static const vm_uffd_ops shmem_uffd_ops = { .uffd_features = __VM_UFFD_FLAGS, .uffd_ioctls = BIT(_UFFDIO_COPY) | BIT(_UFFDIO_ZEROPAGE) | BIT(_UFFDIO_WRITEPROTECT) | BIT(_UFFDIO_CONTINUE) | BIT(_UFFDIO_POISON), .uffd_get_folio = shmem_uffd_get_folio, .uffd_copy = shmem_mfill_atomic_pte, }; As I mentioned in one of my reply to Nikita, I don't like the current interface of uffd_copy(), but this will be the minimum change version of such API to support complete extrenal-module-ready userfaultfd. Here, very minimal change will be needed from shmem side to support that. Meanwhile, the vm_uffd_ops is also not the only place one will need to provide to support userfaultfd. Normally vm_ops.fault() will also need to be updated, but that's a generic function and it'll play together with the new vm_uffd_ops to make everything fly. No functional change expected at all after the whole series applied. There might be some slightly stricter check on uffd ops here and there in the last patch, but that really shouldn't stand out anywhere to anyone. For testing: besides the cross-compilation tests, I did also try with uffd-stress in a VM to measure any perf difference before/after the change; The static call becomes a pointer now. I really cannot measure anything different, which is more or less expected. Comments welcomed, thanks. Peter Xu (4): mm: Introduce vm_uffd_ops API mm/shmem: Support vm_uffd_ops API mm/hugetlb: Support vm_uffd_ops API mm: Apply vm_uffd_ops API to core mm include/linux/mm.h | 9 +++ include/linux/shmem_fs.h | 14 ----- include/linux/userfaultfd_k.h | 98 +++++++++++++++++++---------- mm/hugetlb.c | 19 ++++++ mm/shmem.c | 28 ++++++++- mm/userfaultfd.c | 115 +++++++++++++++++++++++++--------- 6 files changed, 207 insertions(+), 76 deletions(-) -- 2.49.0