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. 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. ----------------------------- Patchset overview: Patch 1: Fix for VM_BUG_ON(!h->resv_huge_pages) crash reported by syzbot Patch 2: New udmabuf selftest to invoke memfd_alloc_folio() This series is tested by running the new udmabuf selftest introduced in patch #2 along with the other selftests. Changelog: v1 -> v2: - Replace VM_BUG_ON() with WARN_ON_ONCE() in the function alloc_hugetlb_folio_reserve() (David) - Move the inline function subpool_inode() from hugetlb.c into the relevant header (hugetlb.h) - Call hugetlb_unreserve_pages() if the folio cannot be added to the page cache as well - Added a new udmabuf selftest to exercise the same path as that of syzbot Cc: Gerd Hoffmann <kraxel@xxxxxxxxxx> Cc: Steve Sistare <steven.sistare@xxxxxxxxxx> Cc: Muchun Song <muchun.song@xxxxxxxxx> Cc: David Hildenbrand <david@xxxxxxxxxx> Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> Vivek Kasireddy (2): mm/memfd: reserve hugetlb folios before allocation selftests/udmabuf: add a test to pin first before writing to memfd include/linux/hugetlb.h | 5 +++++ mm/hugetlb.c | 14 ++++++------- mm/memfd.c | 14 ++++++++++--- .../selftests/drivers/dma-buf/udmabuf.c | 20 ++++++++++++++++++- 4 files changed, 41 insertions(+), 12 deletions(-) -- 2.47.1
