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 B1556C71157 for ; Wed, 18 Jun 2025 05:36:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2FA3A6B0088; Wed, 18 Jun 2025 01:36:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2AAF76B0089; Wed, 18 Jun 2025 01:36:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1C0C16B008A; Wed, 18 Jun 2025 01:36:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 0D1D76B0088 for ; Wed, 18 Jun 2025 01:36:32 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 8CC2AC0502 for ; Wed, 18 Jun 2025 05:36:31 +0000 (UTC) X-FDA: 83567411382.20.E16DE6E Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.9]) by imf30.hostedemail.com (Postfix) with ESMTP id AAC0B80004 for ; Wed, 18 Jun 2025 05:36:29 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=AbBfgYWy; spf=pass (imf30.hostedemail.com: domain of vivek.kasireddy@intel.com designates 198.175.65.9 as permitted sender) smtp.mailfrom=vivek.kasireddy@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750224989; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=fGo71n5bpcGZF9l3aCR61haypIOFNg8/XnxMs3BX2xU=; b=UgfhFhzWXEoEOl49/lGAALoQNGNyBelBuimwn9/5tjQ9uq63lCFp8uHFph281h8YrS7PD3 Vb5uNr6JcfdZdfrQrffw76ysfDvyRbBX520K5SUYNKK5OOIGMwl5N5jpWplHxY9bBmxdCh Y2JEDZkYt45K1hiaauESnbbL5n+MLxY= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=AbBfgYWy; spf=pass (imf30.hostedemail.com: domain of vivek.kasireddy@intel.com designates 198.175.65.9 as permitted sender) smtp.mailfrom=vivek.kasireddy@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750224989; a=rsa-sha256; cv=none; b=je7HIWvQit2YM56ei18Ny+bXTqWql+7m7MfHLG2kLNSb515YeQcF4KULXeHKBEMGdVWkPS ZZaT+DZig1Azu6YDo4do7+uHq9olHuICiHH72MMFuWeypZk+aPZ+WvQNfPDPSjA4vTGd40 Ir0S2jBVVbfjKYvive4SA4h75W6vyS0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1750224990; x=1781760990; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=m88kqVNqnnDUVjj5Atyst3lKGSUQZUmWCqaEkDepKE8=; b=AbBfgYWyouS7JWlwUtGoXLGe2D5VqwrQRxax1t2X7GXe3AoJ44lkpfai BbAm1obY5rv/B8p1qFywmY7SsI7f2B7xyg1pJkDi1ENN+5Mv+MMtZGAaS 6jMwV9d6u1GGxIo0hIoALHR+UV+BqpLbcX2XzlhgE3RCsNU8XEDPAZlWe 6b1HoDQjvKLGiANz18v4vFWjir3iZMunK4+1yotMdtoz0tCBddSxxPylQ W5ajtiZ+UPKvBVQ26xBYkGmZJFaZ8jiV2fmoJ+1N3engodpsrZQ24Brx3 gnBruBWVIT/xz6RP9eGEJYTcjiK235ngtTEU62HuSWuGPznWXTdZTHLv1 g==; X-CSE-ConnectionGUID: aa1gLUTpQs2Gn2BbbmorPg== X-CSE-MsgGUID: xe7SVNxGRrCAecrWTG7C1A== X-IronPort-AV: E=McAfee;i="6800,10657,11467"; a="74960302" X-IronPort-AV: E=Sophos;i="6.16,245,1744095600"; d="scan'208";a="74960302" Received: from fmviesa007.fm.intel.com ([10.60.135.147]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jun 2025 22:36:29 -0700 X-CSE-ConnectionGUID: 9a50KhduROytwV1Bgs2gfA== X-CSE-MsgGUID: MAcqMJLQTcKDhgCVTIlClQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,245,1744095600"; d="scan'208";a="149052928" Received: from vkasired-desk2.fm.intel.com ([10.105.128.132]) by fmviesa007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jun 2025 22:36:27 -0700 From: Vivek Kasireddy To: dri-devel@lists.freedesktop.org, linux-mm@kvack.org Cc: Vivek Kasireddy , Gerd Hoffmann , Steve Sistare , Muchun Song , David Hildenbrand , Andrew Morton Subject: [PATCH v4 0/3] mm/memfd: Reserve hugetlb folios before allocation Date: Tue, 17 Jun 2025 22:30:52 -0700 Message-ID: <20250618053415.1036185-1-vivek.kasireddy@intel.com> X-Mailer: git-send-email 2.49.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: AAC0B80004 X-Stat-Signature: 9mstqjr1xiee9t5ahmtbsk5a1xzbaate X-HE-Tag: 1750224989-887034 X-HE-Meta: U2FsdGVkX1+5OpAeWpll6go7m+Q0zXeodzQuvJSwENymJwzyyGvaKngr1uusvqyjNPz0NCLKcpTQvE+yNZVeUC+AXUv1loNjygInF+V7Zwu42fbKgBJM4Hv1DT2UHTsBGL5gogVkI65GO2veCMNzoVyTDIEj7hrLT0coVZEpFDeNBp2Klc/kwBbPA4na5mpaulYuHGGPoe+wT204y6MJj6bozLsZIhjAegXoQTrxnJVat1wxDIML3fx1TEk9n92bk9uQEXDCqnTf72kIQON6nSDH2a0Qx98vIjAoIA/MO1SMPwNNOuMySuCKAqiSbBD/Zha7I+/7x9NPp+TjO2b9Cw2PaoLjHokaDQK0hOrnMvsgrp72Zcz6a3UFX55NoTL+h1MEBhDzSyfDoHWARPQkLq5r8M44FoQyafCtP+jQLxI9Ag95tGwfPHPiykTKEZLus0Iq9Uk8A6ZIgYHOVXaRlDAQ1VYqO1rRqgEZ99CrdpsA1+sTJU/C65M+JdMvTH9eUD6ybrx5BquTM9OVx6ZixBFmjvnIr0rN1exMOyZSq+O1zxrSoLSltH2et8gf4CGmNUU7Tk5gJuEk/zy2l4NPiDtQHhTByxrolRE5v7X4sPiD0QTq6xCaraLqi7mrxx9K9y/0nImJSZR3kD3IlOSh0jm34fWLCpjqfPaJWWIWJ9HJkNzQh5feSuf5K+ZVKO4vbcccUiuMoyN6z7qs1+76lyE8wTc9d75XmHaX64aXv8rX7dM142m7ZKKuM9+flhTnZ/rhpYiducqVj257FTcHoL4so4PLv//Ga1UipndML7SyKcX+BCABE5FOLgRId2i9QU05NhhpS1OV2girLj386pybPbpWc59utMmamKAaJYNqcH9RKElSEBw5kNMnfmU0 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: There are cases when we try to pin a folio but discover that it has not been faulted-in. So, we try to allocate it in memfd_alloc_folio() but the allocation request may not succeed if there are no active reservations in the system at that instant. Therefore, making a reservation (by calling hugetlb_reserve_pages()) associated with the allocation will ensure that our request would not fail due to lack of reservations. This will also ensure that proper region/subpool accounting is done with our allocation. ----------------------------- Patchset overview: Patch 1: Return nr of updated entries from hugetlb_reserve_pages() Patch 2: Make reservation (hugetlb_reserve_pages) in memfd_alloc_folio() Patch 3: New udmabuf selftest to invoke memfd_alloc_folio() This series is tested by running the new udmabuf selftest introduced in patch #3 along with the other selftests. Changelog: v3 -> v4: - Create a standalone patch to fix the BUG reported by syzbot that can be backported to stable kernels (Andrew) - Split the changes in memfd_alloc_folio() that add a call to hugetlb_reserve_pages() into a separate patch v2 -> v3: - Call hugetlb_unreserve_pages() only if the reservation was actively (and successfully) made from memfd_alloc_folio() (David) v1 -> v2: - Replace VM_BUG_ON() with WARN_ON_ONCE() in the function alloc_hugetlb_folio_reserve() (David) - Move the inline function subpool_inode() from hugetlb.c into the relevant header (hugetlb.h) - Call hugetlb_unreserve_pages() if the folio cannot be added to the page cache as well - Added a new udmabuf selftest to exercise the same path as that of syzbot Cc: Gerd Hoffmann Cc: Steve Sistare Cc: Muchun Song Cc: David Hildenbrand Cc: Andrew Morton Vivek Kasireddy (3): mm/hugetlb: Make hugetlb_reserve_pages() return nr of entries updated mm/memfd: Reserve hugetlb folios before allocation selftests/udmabuf: Add a test to pin first before writing to memfd fs/hugetlbfs/inode.c | 8 +++---- include/linux/hugetlb.h | 7 +++++- mm/hugetlb.c | 24 ++++++++++--------- mm/memfd.c | 17 ++++++++++--- .../selftests/drivers/dma-buf/udmabuf.c | 20 +++++++++++++++- 5 files changed, 56 insertions(+), 20 deletions(-) -- 2.49.0