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 A78EDC7115B for ; Wed, 18 Jun 2025 06:44:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2DF2E6B0088; Wed, 18 Jun 2025 02:44:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 28F986B0089; Wed, 18 Jun 2025 02:44:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1CCEA6B008A; Wed, 18 Jun 2025 02:44:59 -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 10BB16B0088 for ; Wed, 18 Jun 2025 02:44:59 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id A7748BBAAD for ; Wed, 18 Jun 2025 06:44:58 +0000 (UTC) X-FDA: 83567583876.03.77A3139 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf28.hostedemail.com (Postfix) with ESMTP id 9D5DCC0007 for ; Wed, 18 Jun 2025 06:44:56 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=none; spf=pass (imf28.hostedemail.com: domain of anshuman.khandual@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=anshuman.khandual@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750229097; a=rsa-sha256; cv=none; b=eIegd9YFvbY8RvDkcKYc2SzA80MkOlrd2M/3J7QuAtDdF90EyohrfeljeTMcHE18Lo5UeV A1VijP1QLpQMe2sqdwKmL0p+NxaH/5XxjmFfMOjGLfDUEDaP2jl9UmpGMzlfOSlRlvpXu3 /g8F+/e/Y4oJh/IigpRznWV30Wplw18= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=none; spf=pass (imf28.hostedemail.com: domain of anshuman.khandual@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=anshuman.khandual@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750229097; 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:in-reply-to:references:references; bh=80Zkh7DZLmKbblAOGP1sTl3FoGQcSo849b/ACDR0kM8=; b=S97kUQnH0kWAwJbXhBm48S9p5xUM430kSsHTP2lBqkdj4MzyftQs5OEAd9gudVMlwX+XSE btJsniLDd7ed/EJ8n4LUmJ4+X90SnUMbLXbnmZ8SGkzdKG6z8LEKpQdmUh10bAT0K1LBKW CExB/+zIvqSSgnzjA2UF3kRdT7UfRYI= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id EE30412FC; Tue, 17 Jun 2025 23:44:34 -0700 (PDT) Received: from [10.163.35.185] (unknown [10.163.35.185]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EE1D23F66E; Tue, 17 Jun 2025 23:44:52 -0700 (PDT) Message-ID: <99b9f7c8-62e0-4500-b4f1-0efdb73bf502@arm.com> Date: Wed, 18 Jun 2025 12:14:49 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm/hugetlb: Don't crash when allocating a folio if there are no resv To: Vivek Kasireddy , dri-devel@lists.freedesktop.org, linux-mm@kvack.org Cc: syzbot+a504cb5bae4fe117ba94@syzkaller.appspotmail.com, Steve Sistare , Muchun Song , David Hildenbrand , Andrew Morton References: <20250618052840.1036164-1-vivek.kasireddy@intel.com> Content-Language: en-US From: Anshuman Khandual In-Reply-To: <20250618052840.1036164-1-vivek.kasireddy@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Stat-Signature: 1t6io6zr9w9mwrfnrhts8j7gdsd4i3ky X-Rspamd-Queue-Id: 9D5DCC0007 X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1750229096-696029 X-HE-Meta: U2FsdGVkX1+QHZXrXfqp7gxCH0NVwFDxhDXfcrmvQHgB9tFSQZ33e3QNKgWGp18lLF81mM7tnyde/wVfJzo0u826wibVwMlSVcpXAECLhI36X4CIVQddSEKJkugpVrKv6VBCw3BteYkYiMAPj9NLPKyQlIzz/Our6a82+F866RRbXY3X86CDcRKXggs1tUkCDCuUIERyhhNRlnQFOrZz0vOjIPSoIuuRxJEf5oiguuu1Vw/o1AeX150TlDKW/izveFZNZ+K35XfWaoX7eTj5DEL228VFAGUvmGn4En4HbAHvqH0LmTWnIzUaoqiXykdrvJ2dlwxokKFUvsegvQocGbsocpmJBAJT/CN+Mn1PbY6SQdL7Ki2ca9PNJZccgUQbJZYTMmCTLLW9gxeFU+nw1qNRBUeKRdAwKvJu/GtZlPRi5/sjn506E3zB+M6J3w2WLzlCZe4qs9cwu1xGX/1flP6HZmFFdSKwXT3eVoaxP9VEGthN1TmEvtt9WOduNURZTmJrbRbHt4o/jmB5HQi/0jji9HY4mPQwQNadHPveOEvrqTPp0uzRBC9bxvqDDeSoCeAXGtGmRgRc89DaZOP98Tt34i/oCpRa2ab7C50pynO/jHsfQimJ4h08371j79sSGG0s3qY+ppyMk0lFUv1UXO2DuNV7lB22ZYaZjtXvLwGSwQItWeCMpdu5Koop3k/UGztBAmwckge6OFC7BeQZ8/DPrMng2pc7tMVhCCPiUaUpq9yAy0Abxz6LTKgvZIg0tmT7ShRPA1ZwSIQVstyNrSa0uBQFJlYN1lqwLUMbC3PZvwsaND+BfygTp+Bx4p7W8bwFqCeva5jcMacS7vDpNnOdbAXH2lWG/7JZnGM5ddkBcEHN6OC0C3zTUiB/JvWZbV7NJ708XaIX9js+cBEWuC/p6F+KcrRBvVUP+gGwSYHeJGCv/v+dlKDt9dt+aETe4jn39e5Fb8Z6q6ritGL Esx8Lx/p 9ELVrrzCFiZJAZtlkDamwMTMkuJXcGvm7EmenoF/JdELWcOZjNM1ZNbYESTB8Zl9qYj2usMPkUlTw4uF35o2HKJw41LYA1UcDRQOI0xGKPY23zVES047C5au+eZrtRyP/9P4XHotbKxGbxj8EjCM2s6c6DNRs6O57Ns6NJaZqFiDQ1R2PvlMnX2ILLvJx/aWBUzIHjXLjt4ZldeaC4+fz2Qa3EjUFbPnu2DOz6PM6NZ+9CYVDEn1VvgGep8wdlfLC+MzzG0Z8ft1AICF9gjoYsCdcGHDnDWASEkhztIHtaO6FDRHGAWG3fMZylOkxDzN7MVAQFjM7trcfXAjeXlo+ztm9eCAUreJqzAxcFe/P6/fOmnwIxjn9OFC8DeLLWI/+ri7j1plOo7XrT53iaPS4J72+//vbwmWd09HJL49U8Q35Uxi+TL1889rmvt2vY8PmUl4SjP2yqSbBBhXR1fkENO+GK29ZLDQ2fiva7eiw4fznhXUGWNTPW2r/lXJqmLhBG2FoL+xWuleGn+RnC3ymFry/oQ== 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 18/06/25 10:58 AM, Vivek Kasireddy wrote: > 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 replacing the VM_BUG_ON() > with WARN_ON_ONCE() as there is no need to crash the system in > this situation and instead we could just warn and fail the > allocation. Why there are no reserved huge pages in such situations and also how likely this might happen ? Is it recoverable ? > > 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 > Cc: Steve Sistare > Cc: Muchun Song > Cc: David Hildenbrand > Cc: Andrew Morton > 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..f74c54ecf955 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 (WARN_ON_ONCE(!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;