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 D8D11C77B7C for ; Mon, 23 Jun 2025 23:35:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 50E556B00B4; Mon, 23 Jun 2025 19:35:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4BE0B6B00B5; Mon, 23 Jun 2025 19:35:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3AC156B00B7; Mon, 23 Jun 2025 19:35:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 255786B00B4 for ; Mon, 23 Jun 2025 19:35:51 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id A1241160FFF for ; Mon, 23 Jun 2025 23:35:50 +0000 (UTC) X-FDA: 83588275260.17.C1554A0 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf26.hostedemail.com (Postfix) with ESMTP id DE462140012 for ; Mon, 23 Jun 2025 23:35:48 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=sIKXIz8v; spf=pass (imf26.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=1750721749; 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=YiyX+CfGakzj6NHAFaOL1oU6AYGK8xR48sG75ALe4q8=; b=Vq7W/ZaSs0we1PnjpYlqcOxOpeLob1qbSIBC6OzxERyumTCzmfPVLpn7gTZy967FoEeEeR NOXtArIij9eCCByhsrMvlYzT5njz0+0XZ2szr4o2Pk3jPOn0DS0SdGeG7A14SuCrkrkb31 8caV5/baRS8bW81lq/oKqPf0TtFxsUY= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=sIKXIz8v; spf=pass (imf26.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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750721749; a=rsa-sha256; cv=none; b=fVFyXH6jsuBZyUSrGz4DWDIFYZLbOHzUaQ7drBZdT3dBG+HYBDdZLcwCNSU2MNh7V9f3eT kw7ZPQgcafMnD9rSfRCO2T3mhtW/dQn/yKYo/0L0WEYMlXTXFRT7/ohgbS13wGAeP50GKh 2VZSIZyhovSvJ7qdRsENNcivJABNZJk= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 16B59A500E5; Mon, 23 Jun 2025 23:35:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 724C6C4CEEA; Mon, 23 Jun 2025 23:35:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1750721747; bh=v3mXMdkiN3SKrn9IVtLWTsSO9yIG76lq1pU/dQfOUFQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=sIKXIz8vgnVPk1Xk/E6PE+l07VvE/mtIAWNojffeIsvHVGhRSAVFkgy4h1/ivb6kp bhpzSKQwAWzEbjJYEv9gjBHh6QsIWEW4E4M2gDGM9jxC9BXQAY3IWfxlqoXsX4k9yK VPPLPgfn4aZGoQ+cD4czH2EWTLQgf9rOmW4yfk1w= Date: Mon, 23 Jun 2025 16:35:46 -0700 From: Andrew Morton To: "Kasireddy, Vivek" Cc: Anshuman Khandual , "dri-devel@lists.freedesktop.org" , "linux-mm@kvack.org" , "syzbot+a504cb5bae4fe117ba94@syzkaller.appspotmail.com" , Steve Sistare , Muchun Song , "David Hildenbrand" , Oscar Salvador Subject: Re: [PATCH] mm/hugetlb: Don't crash when allocating a folio if there are no resv Message-Id: <20250623163546.ddb768e0833f7a19af259a43@linux-foundation.org> In-Reply-To: References: <20250618052840.1036164-1-vivek.kasireddy@intel.com> <99b9f7c8-62e0-4500-b4f1-0efdb73bf502@arm.com> <20250618170248.89ff5c3d3fe23233424fd4da@linux-foundation.org> X-Mailer: Sylpheed 3.7.0 (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: rspam03 X-Rspamd-Queue-Id: DE462140012 X-Stat-Signature: a91orgoek5r93pjsmefr5ojeyjddce45 X-Rspam-User: X-HE-Tag: 1750721748-805329 X-HE-Meta: U2FsdGVkX18fML/XtZkqC+ICGBUrqF0fcAxo47XR4+FLzRdS5oatLH1yB1lK0zG/5EIP+jsdAqECd7jaKTe5/j352T/0fPQeYVe6Oc9jVmyl6QxNivA2EwVqBnOlJVRZrgxaAk3a9yTkvvXB8nzpi4iF1yIOwAjyZZO16w/xLKhevjnbWPLRF59UoLruON6fPNjKEEgLSgP6j4i+wwxjvFj8ZcC8d5kqsTy2DUWAlBoIi+oRaFexGTSulTuWqRnhFdk7Ij76ksLWWyd/UiZciYwYs0IKpVI4oCHw4IJyY5//A7b05L+vUdqRkoXJro6nRTnhexDn0qcTr64ii+fshCyH7Qwz9AmS8J4ULQ3rZwe/VSuX2qKJq3nQ+pVyg1lMHZAxQpOClTLqHxUbO2vQVOAqXkxDcbcpgqYpQaOIWOC2HQxvFA8eQah4R08rVkgUDKa1I/frSJKrRrRXQ7FMgw87VzHM0HTWSKkVNS3/8mZroEh5wl57aR8prKvkLK73sZ3zyLiL1HxnKX6CPJ3+wz+Zb4xFZMRqPSIwKkdwvWN3GWfao/0m24tPFFsRV1yJhndN2leIxKI5kwRU3JPGunjoMbFYKMI7XuLfT37Ys40MaR01ph/dxRwepxFffjUOdodhhyrSrZ4To86kY6p1UivQ3b+W/ptu1KuaiQAbubsZHVCxMhzzrhKD3nvHTck1Bu77IUfiidRDDaN6GR7p6NAUCmLG+40t33bSOCSfDQhhCDbauBC5p4zElPXI/wg4ktKt6C6pQGFoASokbLiSiEcAl8iPkODgRe9bJgRYHn2dPA1vAE839DH6XL8oN3LIwqtss2CSz6kkuMnuYOkZEM2ajofS3DcT3q5n3Y9Caw7R50KHQLaed46tPpaPQ+3BfqFBE/e40hpmxS1oFo/WZN83/oK/JT5tYnbOljXwACBOaodQe7OBkosiZsecjfVusTgcKBqYgFpHFJYNWX7 XU/igSDP H0LJGCC+1ZuVOi87Q4YakYfuwduHLt/cdms33IyWpZLFPvWFCeXjAj9UdSxiODB81m5KjryZmA+3f/srC/jTW7b74KqkYjX02LU4WgYlWaZElTM92gHSwKl0MB9lmGW+sp1xMjwZ79WdR6ONWgK/DbYexiPhAZ6D1e283AHtNKX77yOrKiFWZ60kXlaNcdvS2Om+BhmAGbMpHzm8RU0LZ7nryjwzPq+9GaVSfZiVGiSZOsym5QyIkd3MB779Fi09amYbpXxlIcgQu3Y5X140F5J+/GWZKATe8ROOeBVsFBcRSOzVtZ0TFD2srJeaBPbWGxv5suA5sBAPWAcCbizeFfyRR6tN3UZvyVfyEeAJpV1soKP1UF2iOuO6wq2O4bZpz3VpNcLiVr/kJNoJxO6FgwdA/Z3hdTCM8OZ1Ojx7f0RJGC5mSyMU2hkpdi7wuHMjjHilyUeeIMx0whtrq4x/4wh3FyziQlkmS633bZwQrTpPrMWPZExRdG3YtsTHEG3ItBJEm 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 Thu, 19 Jun 2025 05:30:52 +0000 "Kasireddy, Vivek" wrote: > Hi Andrew, Anshuman, > > > Subject: Re: [PATCH] mm/hugetlb: Don't crash when allocating a folio if there > > are no resv > > > > On Wed, 18 Jun 2025 12:14:49 +0530 Anshuman Khandual > > wrote: > > > > > > 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 ? > As described in the commit message 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 me explain this further with 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. Cool, thanks, I'll paste that into the changelog ;) So if this code path is rare but expected and normal, should we be emitting this warning at all? > > I can't find any mailing report/discussion of this. The Closes: takes > > us to the syskaller report which is a bit of a dead end. > My understanding is that the Closes tag can be associated with a URL for > a public bugtracker like Syzkaller. Would the following be a better Closes link: > https://lore.kernel.org/all/677928b5.050a0220.3b53b0.004d.GAE@google.com/T/ I'll add that - the more the merrier. > > > > I agree with the patch - converting a BUG into a WARN+recover is a good > > thing but as far as I can tell, we don't know what's causing this > > situation. > > > > syskaller has a C reproducer, if anyone is feeling brave. > The udmabuf selftest added in patch #3 of the other series can also reproduce > this issue and is a lot simpler. > > Thanks, > Vivek