On Thu, 19 Jun 2025 05:30:52 +0000 "Kasireddy, Vivek" <[email protected]> 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 > > <[email protected]> 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/[email protected]/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
