[PATCH] mm/hugetlb: Don't crash when allocating a folio if there are no resv

[PATCH] mm/hugetlb: Don't crash when allocating a folio if there are no resv

[Vivek Kasireddy]

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:
 <TASK>
 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.

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 <steven.sistare@oracle.com>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: David Hildenbrand <david@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
---
 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;
-- 
2.49.0

Re: [PATCH] mm/hugetlb: Don't crash when allocating a folio if there are no resv

[Anshuman Khandual]

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:
>  <TASK>
>  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 <steven.sistare@oracle.com>
> Cc: Muchun Song <muchun.song@linux.dev>
> Cc: David Hildenbrand <david@redhat.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
> ---
>  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;

Re: [PATCH] mm/hugetlb: Don't crash when allocating a folio if there are no resv

[Andrew Morton]

On Wed, 18 Jun 2025 12:14:49 +0530 Anshuman Khandual <anshuman.khandual@arm.com> 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 ?

I'm suspecting we don't know.

> > 
> > Fixes: 26a8ea80929c ("mm/hugetlb: fix memfd_pin_folios resv_huge_pages leak")

How was this arrived at?  This is merely the patch which added the assertion.

> > Reported-by: syzbot+a504cb5bae4fe117ba94@syzkaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=a504cb5bae4fe117ba94

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.

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.

RE: [PATCH] mm/hugetlb: Don't crash when allocating a folio if there are no resv

[Kasireddy, Vivek]

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
> <anshuman.khandual@arm.com> 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.

> 
> I'm suspecting we don't know.
> 
> > >
> > > Fixes: 26a8ea80929c ("mm/hugetlb: fix memfd_pin_folios
> resv_huge_pages leak")
> 
> How was this arrived at?  This is merely the patch which added the assertion.
Right, 26a8ea80929c is indeed the commit that introduced code that led to this
BUG/crash. Would this not qualify for Fixes?

> 
> > > Reported-by: syzbot+a504cb5bae4fe117ba94@syzkaller.appspotmail.com
> > > Closes: https://syzkaller.appspot.com/bug?extid=a504cb5bae4fe117ba94
> 
> 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 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

Re: [PATCH] mm/hugetlb: Don't crash when allocating a folio if there are no resv

[Oscar Salvador]

On Tue, Jun 17, 2025 at 10:28:40PM -0700, 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:
>  <TASK>
>  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.
> 
> 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 <steven.sistare@oracle.com>
> Cc: Muchun Song <muchun.song@linux.dev>
> Cc: David Hildenbrand <david@redhat.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>

Who is supossed to reserve these hugepages?
hugetlb_reserve_pages() is only called at mmap/file setup, and you mention that
you try to allocate the folios even before mmap, so who's in charge of
making those reservations for you?

 

-- 
Oscar Salvador
SUSE Labs

RE: [PATCH] mm/hugetlb: Don't crash when allocating a folio if there are no resv

[Kasireddy, Vivek]

Hi Oscar,

> Subject: Re: [PATCH] mm/hugetlb: Don't crash when allocating a folio if there
> are no resv
> 
> On Tue, Jun 17, 2025 at 10:28:40PM -0700, 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:
> >  <TASK>
> >  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.
> >
> > 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 <steven.sistare@oracle.com>
> > Cc: Muchun Song <muchun.song@linux.dev>
> > Cc: David Hildenbrand <david@redhat.com>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
> 
> Who is supossed to reserve these hugepages?
> hugetlb_reserve_pages() is only called at mmap/file setup, and you mention
> that
> you try to allocate the folios even before mmap, so who's in charge of
> making those reservations for you?
In this specific case, I would say the caller (memfd_alloc_folio()) should be the
one making the reservation before it tries to allocate the folio. And, the other
series you commented on is trying to do just that.

However, as mentioned in the other thread (replying to Andrew and Anshuman),
this is a very uncommon use-case as hugetlbfs_file_mmap() is not called first.
So, this patch is only trying to prevent the crash but the actual underlying problem
(no reservation) is addressed in the other series.

Thanks,
Vivek

> 
> 
> 
> --
> Oscar Salvador
> SUSE Labs

Re: [PATCH] mm/hugetlb: Don't crash when allocating a folio if there are no resv

[Andrew Morton]

On Thu, 19 Jun 2025 05:30:52 +0000 "Kasireddy, Vivek" <vivek.kasireddy@intel.com> 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
> > <anshuman.khandual@arm.com> 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

RE: [PATCH] mm/hugetlb: Don't crash when allocating a folio if there are no resv

[Kasireddy, Vivek]

Hi Andrew,

> Subject: Re: [PATCH] mm/hugetlb: Don't crash when allocating a folio if
> there are no resv
> 
> On Thu, 19 Jun 2025 05:30:52 +0000 "Kasireddy, Vivek"
> <vivek.kasireddy@intel.com> 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
> > > <anshuman.khandual@arm.com> 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 think it would be OK to drop the warning. Otherwise, Syzbot would continue
to flag this issue.

Thanks,
Vivek

> 
> > > 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.co
> m/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

Re: [PATCH] mm/hugetlb: Don't crash when allocating a folio if there are no resv

[Andrew Morton]

On Wed, 25 Jun 2025 14:18:28 +0000 "Kasireddy, Vivek" <vivek.kasireddy@intel.com> wrote:

> > 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 think it would be OK to drop the warning. Otherwise, Syzbot would continue
> to flag this issue.

OK.  Could you please propose such a patch?  With a fairly detailed
changelog explaining why the warning is bogus?  After all, we don't
want to be removing our ability to detect a real bug!