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 20066C7EE30 for ; Thu, 26 Jun 2025 19:13:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9E6C88D000C; Thu, 26 Jun 2025 15:13:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9978E8D0001; Thu, 26 Jun 2025 15:13:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8862A8D000C; Thu, 26 Jun 2025 15:13:03 -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 712E08D0001 for ; Thu, 26 Jun 2025 15:13:03 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id C6028103D5E for ; Thu, 26 Jun 2025 19:13:02 +0000 (UTC) X-FDA: 83598499404.20.C87A4C9 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.10]) by imf11.hostedemail.com (Postfix) with ESMTP id BAD3040006 for ; Thu, 26 Jun 2025 19:13:00 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Fj2yjgTZ; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf11.hostedemail.com: domain of vivek.kasireddy@intel.com designates 198.175.65.10 as permitted sender) smtp.mailfrom=vivek.kasireddy@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750965181; a=rsa-sha256; cv=none; b=F4ZxZRmQrhdNZy+q6OcJaqzPjhs31pVfuvDN38jB9aTUI/eW4XL4B0mSAc825XGmxAMseC 37AIBmxpBkQTQ+nVOUBCZCplaIBpBjhXJUwk6ngl1QNcsEsAiCXZuxW3os7puCt19wHsJN VVOPGBmu+/GneVTwATKZ6LeaiFKMQVY= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Fj2yjgTZ; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf11.hostedemail.com: domain of vivek.kasireddy@intel.com designates 198.175.65.10 as permitted sender) smtp.mailfrom=vivek.kasireddy@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750965181; 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=a5mbSjWnPF0rW8poHPsUsx56mIIe6KGHF+68lbe9ebg=; b=rqjWwunIIWDq4pU7V4VCqLWNF0E3zWiCEVfNzcgz+Q+QKmBS8T2mRxJGfPbKAV+82P5aCv G+Dta1VCRNi5VqDtTJp89GBnZlnQX0T8XHoZy7as7yoIlpsVCGsGkTbq/sP993xDH6fxyz aWT8DnXRex7ym2dLLYXlfomrRVmqwfo= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1750965181; x=1782501181; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=FndfxWS1YeFWxReAAV8nrkQod2f/3VNZrcZSbE2kFYk=; b=Fj2yjgTZ2ETP2i4S9UELGNS7HrPFifkWgXuG7Mk6dNVPPAKT5oxBJSz5 FA7SwWvjsbhX47//X83V4Ax9bAPQ0Bjlr7tn0vYCBvG8a8KHEnqvpsgvD gHCsFtd0L4oaWEoBfAy5Ni08bdACMU+dk8IfKCm0a+Zjh2oY6ejT36+93 puDgeFX3l9qSeEwlTfpUChf4hNOr2KKy0IQ/k+nfIK5ZSFTQ1jJQNZjyF /5BWrYHHw8aVSZNpPTUJQa9yAsicOcJz+Puv5tIv9WFHp15dzcJNnqPHk gL26Mxtl1+XX7zsiDE5491UvRzcqNmf1YqJ864/tsiE0BB5p05v5JaiYr g==; X-CSE-ConnectionGUID: /hG1JReuQ52hjam9l8VWzw== X-CSE-MsgGUID: IPd6zHcSRAuLx984KKg0YQ== X-IronPort-AV: E=McAfee;i="6800,10657,11476"; a="70706658" X-IronPort-AV: E=Sophos;i="6.16,268,1744095600"; d="scan'208";a="70706658" Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by orvoesa102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Jun 2025 12:12:59 -0700 X-CSE-ConnectionGUID: Bi2FFmnQSvO1JnUYCtDxaA== X-CSE-MsgGUID: SPY3scn5QcKvwcyVrjAnmw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,268,1744095600"; d="scan'208";a="156628635" Received: from vkasired-desk2.fm.intel.com ([10.105.128.132]) by fmviesa003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Jun 2025 12:12:59 -0700 From: Vivek Kasireddy To: dri-devel@lists.freedesktop.org, linux-mm@kvack.org Cc: Vivek Kasireddy , syzbot+a504cb5bae4fe117ba94@syzkaller.appspotmail.com, Steve Sistare , Muchun Song , David Hildenbrand , Andrew Morton , Anshuman Khandual , Oscar Salvador Subject: [PATCH v2] mm/hugetlb: Don't crash when allocating a folio if there are no resv Date: Thu, 26 Jun 2025 12:11:16 -0700 Message-ID: <20250626191116.1377761-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-Queue-Id: BAD3040006 X-Rspamd-Server: rspam10 X-Stat-Signature: 4us75gp5x7sfnzik84t8ugntmj6soxnx X-HE-Tag: 1750965180-623818 X-HE-Meta: U2FsdGVkX19Q63fbamsHZdTwGG6zokLXvuNUxA17hxaIyxvvGrB8UliM+WZgq3UTQwsLhAqQxAwIyH3zJLu2DeK2zZLoKz057lvzx+59T+Gm7nstpmKn7RD8JcIimqvcHA4esHRf/pMtL/uZDjrqAoKTyOj/0x9ml2Fxj2dVsH5xf0v9GNdSxeM/kz5Zr+oZBk7Z/uk41psInHdQDlSgipTctUFX6R9PnPnUOxM3gPtdiBATKUkqJpjyJlrNBMzr5u/ZTXU/8d/L66DU5alrznP3nRKEnK+56rL9+AXK2xCLsSfZpAabyxK/hfkV1YIDF0SiBc9WCAtweItQdo05cW2eKQIECAXlPA+krXxaWozQwvYVD2FJmhvxRrB37hnPHJP0f8ex6lAWtV/vjdEMQnJLW4ep4X3rcDkxHYJ0tUVd49M+imjClWaHO3+TBnRHLCsKfRhpFE6F1O4hF7yPWOypi397xe6Xegt1nPzAuEzn9frXcLPL4mF3ih8DuI7uEC5MTfhkRtQPXPBuzMvBdUxoA86SVfBj54PHfvDbc65GwQ1zpWVPnK9hit31Y8Bdrqf34zmBBH0mqpHgSjsJXtKHQ+6caVYbJ+rlyYt2ejRyWaHl+82apyzKqyTWAmpEpd8LNRY+VVZDKVqS07FyTBS3Np6e1KoajlbSnfUPrSUNnwPKi+Q2pRQerkTzn2PLYQ1rCP+bnnh1TdfA+XAEsryXshpWte4eo3VMfaMweGlCpVkRdeTn7s1dPLnrMNkpqFO/Y8bhGgZpvCTtiC/Q7HNXJ5pcgKNlCmSci+3bTMlp7MpMYm3CluXne4Bbl1NMc85yEOwvzC1dGfTV+4iUDeeZfNCnXQVJGEBJQ/xFwsgGBUyVw/qms3LR6svDLXSu0ZqHk8xali6EvvC+hHXZhtqh64lDUJHvs0Bjpw9elpkE4daaSab4Fbwhu6FX1+6MneyX/2cmPNvZm2lrthD S7GqdIJe ydLBX7ioOynSzQFyUy7L2c+t/m7jcS4IqQFzmiB35id7vZkXKsZXySj7TXkhWpQfH4DFbI61EAPPzDfgOqX7jJa6vVyAcg/NLuBybaT+snoB5z5JbPM4DCKktFFrGZ+C69kfJrIh4CHjdVsNUyKqKjV2zgywgCiK4TGfGnCjpPLsNHyc7PDO2YHcjCrjN3FiEww1skDrn5up0GFPdyzwLFv/IHFGJYjLplA+2FXOfBd9y+0Y2HMxWuQQ6QUEljYhJZx2N48JPnZH5OnY0n5ghL5bePTcl4ygUjdGmGcRyrm9zWBsneUJ+azNTRQoQYpQcUIqRI0tj4pcbRN3qCCZ5sH1UshYO9X4GPUSjZnpyyPPNLiiq4sKKtkJbIKDED6xi7nL+9TdzO9Y0nf+MrPiH24EVw0w+Se/KoPKo4TcWtVARZ2fLOIWxaWfMdS48GI8uy2qx6oTOB6ILh6eRWYf/3M/UcZa3E9by+TAoIDZu+he5HgmqW9GDvCPYT5pwvl8GmkMfYFL9gaM/4km1191XDcMAaO/UrdXmHMxG+NYXIkZINZmzBww1cb187r4B4L64xM0xRWjPVBDHabffwBsFLMY1urMX7gvbe2ZaKQE/A7c7jJ8l+lDxdNC/rSU4fE6WKYN3 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 there is a chance that we might encounter a fatal crash/failure (VM_BUG_ON(!h->resv_huge_pages) in alloc_hugetlb_folio_reserve()) if there are no active reservations at that instant. This issue was reported by syzbot: kernel BUG at mm/hugetlb.c:2403! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 UID: 0 PID: 5315 Comm: syz.0.0 Not tainted 6.13.0-rc5-syzkaller-00161-g63676eefb7a0 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:alloc_hugetlb_folio_reserve+0xbc/0xc0 mm/hugetlb.c:2403 Code: 1f eb 05 e8 56 18 a0 ff 48 c7 c7 40 56 61 8e e8 ba 21 cc 09 4c 89 f0 5b 41 5c 41 5e 41 5f 5d c3 cc cc cc cc e8 35 18 a0 ff 90 <0f> 0b 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f RSP: 0018:ffffc9000d3d77f8 EFLAGS: 00010087 RAX: ffffffff81ff6beb RBX: 0000000000000000 RCX: 0000000000100000 RDX: ffffc9000e51a000 RSI: 00000000000003ec RDI: 00000000000003ed RBP: 1ffffffff34810d9 R08: ffffffff81ff6ba3 R09: 1ffffd4000093005 R10: dffffc0000000000 R11: fffff94000093006 R12: dffffc0000000000 R13: dffffc0000000000 R14: ffffea0000498000 R15: ffffffff9a4086c8 FS: 00007f77ac12e6c0(0000) GS:ffff88801fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f77ab54b170 CR3: 0000000040b70000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: memfd_alloc_folio+0x1bd/0x370 mm/memfd.c:88 memfd_pin_folios+0xf10/0x1570 mm/gup.c:3750 udmabuf_pin_folios drivers/dma-buf/udmabuf.c:346 [inline] udmabuf_create+0x70e/0x10c0 drivers/dma-buf/udmabuf.c:443 udmabuf_ioctl_create drivers/dma-buf/udmabuf.c:495 [inline] udmabuf_ioctl+0x301/0x4e0 drivers/dma-buf/udmabuf.c:526 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Therefore, prevent the above crash by removing the VM_BUG_ON() as there is no need to crash the system in this situation and instead we could just fail the allocation request. Furthermore, as described above, the specific situation where this happens is when we try to pin memfd folios before they are faulted-in. Although, this is a valid thing to do, it is not the regular or the common use-case. Let us consider the following scenarios: 1) hugetlbfs_file_mmap() memfd_alloc_folio() hugetlb_fault() 2) memfd_alloc_folio() hugetlbfs_file_mmap() hugetlb_fault() 3) hugetlbfs_file_mmap() hugetlb_fault() alloc_hugetlb_folio() 3) is the most common use-case where first a memfd is allocated followed by mmap(), user writes/updates and then the relevant folios are pinned (memfd_pin_folios()). The BUG this patch is fixing occurs in 2) because we try to pin the folios before hugetlbfs_file_mmap() is called. So, in this situation we try to allocate the folios before pinning them but since we did not make any reservations, resv_huge_pages would be 0, leading to this issue. --- v1 -> v2: - Remove the WARN_ON_ONCE in alloc_hugetlb_folio_reserve() if resv_huge_pages is 0 and instead just return NULL to indicate that that the allocation failed. Otherwise, tools such as Syzbot would continue to report this as a bug. Additionally, since this issue occurs during a situation that is not very common as described in the commit message, it probably does not make sense to emit the warning. Fixes: 26a8ea80929c ("mm/hugetlb: fix memfd_pin_folios resv_huge_pages leak") Reported-by: syzbot+a504cb5bae4fe117ba94@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=a504cb5bae4fe117ba94 Closes: https://lore.kernel.org/all/677928b5.050a0220.3b53b0.004d.GAE@google.com/T/ Cc: Steve Sistare Cc: Muchun Song Cc: David Hildenbrand Cc: Andrew Morton Cc: Anshuman Khandual Cc: Oscar Salvador Signed-off-by: Vivek Kasireddy --- mm/hugetlb.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 8746ed2fec13..a181c55f268b 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -2340,12 +2340,15 @@ struct folio *alloc_hugetlb_folio_reserve(struct hstate *h, int preferred_nid, struct folio *folio; spin_lock_irq(&hugetlb_lock); + if (!h->resv_huge_pages) { + spin_unlock_irq(&hugetlb_lock); + return NULL; + } + folio = dequeue_hugetlb_folio_nodemask(h, gfp_mask, preferred_nid, nmask); - if (folio) { - VM_BUG_ON(!h->resv_huge_pages); + if (folio) h->resv_huge_pages--; - } spin_unlock_irq(&hugetlb_lock); return folio; -- 2.49.0