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 2A84EC02185 for ; Wed, 15 Jan 2025 03:33:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4476F280002; Tue, 14 Jan 2025 22:33:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3F459280001; Tue, 14 Jan 2025 22:33:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2BC19280002; Tue, 14 Jan 2025 22:33:01 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 0D5B8280001 for ; Tue, 14 Jan 2025 22:33:01 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 61DBA160EEB for ; Wed, 15 Jan 2025 03:33:00 +0000 (UTC) X-FDA: 83008264920.03.9C670A6 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf11.hostedemail.com (Postfix) with ESMTP id AEFFB40003 for ; Wed, 15 Jan 2025 03:32:58 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=bERF0PVU; spf=pass (imf11.hostedemail.com: domain of akpm@linux-foundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736911978; 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:dkim-signature; bh=M4Q+F26t4NwpPrCJRsdfqDsHkv5pfLbby1bFrEUOhDQ=; b=VONHa3OXVoSGt4JEtyFJUEK9hqJK4EQ1W7Nl2Gs/CLvx5Uu7jWwFFrFay56PPm87tFoq+g I2WWy2cNObxIId+CV1H9HqH8MJRO2o7EsnMumiAHKE5vl70cSAZ/3FgimnvnKgV5KfprrQ zsLWaJ84pFeO9onk/344zaPw7g7kkTs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736911978; a=rsa-sha256; cv=none; b=qEm01djtAnBpIOGdzDWC/6BxmSymr7eqpfLbR14gJs+dRSvnKVBYrJcGU0J0y2ARaakAu4 MeCjrJHoz/qiOVlFaHaEfM6SIMsuG0rYPmEmOlcfBHHPJlxw9a2J2wSgRIqrT4aJHkyjMA 30qGeUqOTXK8Ax2BWHwLuad0ISe8Ya0= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=bERF0PVU; spf=pass (imf11.hostedemail.com: domain of akpm@linux-foundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id B9CE3A41375; Wed, 15 Jan 2025 03:31:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4F3E0C4CEDD; Wed, 15 Jan 2025 03:32:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1736911977; bh=T4dcbDI/vKyWRblxs1ywFALBVAfQe8tiDcHpfJM6RN8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=bERF0PVUQI4js/tXDP63ORxOW/2+/PHDid/ylo91qKh7+q5Ymbi8I0mhhtdg7LF5t VeMCK3B4Qbo5Vcxz8SCqqSYPF9HyCZkrSPuC9aAS1GOmYZyxt+TPgnAtPd/sH3rdlV KD9hRAbzLTi/y6DF539AQQoK095/jG0bOU+jUq3w= Date: Tue, 14 Jan 2025 19:32:56 -0800 From: Andrew Morton To: Vivek Kasireddy Cc: dri-devel@lists.freedesktop.org, linux-mm@kvack.org, syzbot+a504cb5bae4fe117ba94@syzkaller.appspotmail.com, Steve Sistare , Muchun Song , David Hildenbrand Subject: Re: [PATCH v2 1/2] mm/memfd: reserve hugetlb folios before allocation Message-Id: <20250114193256.c1cdb555ba24afc9790a40c8@linux-foundation.org> In-Reply-To: <20250114080927.2616684-2-vivek.kasireddy@intel.com> References: <20250114080927.2616684-1-vivek.kasireddy@intel.com> <20250114080927.2616684-2-vivek.kasireddy@intel.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: AEFFB40003 X-Stat-Signature: x53moc35o1tjqbtbszd9cpnzufxnpuc7 X-Rspam-User: X-HE-Tag: 1736911978-826034 X-HE-Meta: U2FsdGVkX1/+G7JNzZI0Usmhxr/OJ1mA5MvP2+WO6+jib30YYHxZH78OT46R20BEmnntHoTrK0HcGJ5lpL93Bm0pL/J3OiSwXMTeLBIy1PAFUAbsp748uzGm98X//xvbCt5un6p+TUMN7G+wlAY4WH5yR3U53+zIPGHo7X59G94HWq9GJOxA36+3e3lXTKapr9Znk491a0bBQgayoyNiytZSwRIb+bRo9Z+MmPx65ZJ5KMoFFvuAxCN1uw1ADPQPXAFaKHIq8J0mwW3vbRwu/ZRIZpdeZIvEktH6Mf7oGBB75zjESuEjXNuA7sNPyQtNWUM5u9fwIvVLT8a/f7qg0lBeKSZVxOkiu0/ZVzg6c5ebWamt2y+auEwfbjgPMBJ5Yc9oF0VheVXsDb3EkxH9ftUIkoYd2ngjU/amHunHPjnLzQ1rdu3QFJtLD8u+JCOHmxq+TfGQkZI/xJS04WXp6fx0VbF5lltlBwPQCRp/i68TV2WTVN4NlGaq7+XIGd/XptxW2pxtZJhYeCK+IZtcZuPOsjWJRYssF9knOl+uAWiMiFr+ZYoIbreGfx7gd8IXp2Bfegh+yWHBBypLKvuUaI/c0EEkCJmHHDYM82/Rd009ODHzJlXilK1mKqagaPKT5i5l4jKfHkm9qwobQdcQ3H2X6XMIo3u8Pe+E9pPm9Kypuj+LoRGlvOBNcl+tLu3gcrCcuG6f/L31h3OhO1ogAoJ+jYiICIcO6IOOPKb4fcOR/Gc+eMQnZF7uJ1Um+FoqUlcy4nFDHaD5jt/yfw4bj+6YpQMCyIuE7CbIcrZGlKUiyEqKK043mF/Y8hYQPbIZUBY7/FR2iFmWBUKjHUxHjtSJapNrIItEK6ApG0FkiAYU2fgsI1s5+EW09kVEwOh4R6bw9THa3RlZsSrPFRAJmWBNAYNKze9moT2m3IhjBHHG4tSJTr8VZlVDcdyaKJqmTUP3qws93B6lPZt4R1f sQ8nTpFr SrGXinT/TMZT44iuGiywRmrO1S/jCZc/SqnkTt5MBGKE/3TIsJmXPxRmE3C7v8tLA4MS/jEsg0rkWo/AnfxeTfFhZRr2ZD7CvN/npCMDr3X9MLF/ZdZ8/330fLqR8+E2D/8d2/IPvlGnEAoEQsXPwAeGd8s7g54uWMH3aXiQ5uSlbieF4K0qOQjCUTCZEoVzSa05wuAGjbkKboAmSNJVs7tg50wngvl6/OWfgox2YD2ebu+w1MFxZMj0P/OnwERl+gIKF7uY9wjwVYINXrkpjmhhUdrcprMR9vZWjFiXVujPxhYyTVi/2HT6UWvmC99klJL5aUvmnvT1QsLLSDbCHOy94t5xGr5YunHLk6f1iSrWz+fkjKOAYG+vQig== 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 Tue, 14 Jan 2025 00:08:00 -0800 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 crash/failure > (VM_BUG_ON(!h->resv_huge_pages)) if there are no active reservations > at that instant. This issue was reported by syzbot: > > kernel BUG at mm/hugetlb.c:2403! > > ... > > Therefore, to avoid this situation and fix this issue, we just need > to make a reservation (by calling hugetlb_reserve_pages()) before > we try to allocate the folio. This will ensure that we are properly > doing region/subpool accounting associated with our allocation. > > While at it, move subpool_inode() into hugetlb header and also > replace the VM_BUG_ON() with WARN_ON_ONCE() as there is no need to > crash the system in this scenario and instead we could just warn > and fail the allocation. > > ... > > @@ -2397,12 +2392,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; > + } > + What is is that we're warning of here? Is there any action which either kernel developers or the user can take to prevent this warning from being issued? IOW, maybe the WARN shouldn't be present?