All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Vivek Kasireddy <vivek.kasireddy@intel.com>,
	dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
	syzbot+a504cb5bae4fe117ba94@syzkaller.appspotmail.com,
	Steve Sistare <steven.sistare@oracle.com>,
	Muchun Song <muchun.song@linux.dev>,
	David Hildenbrand <david@redhat.com>
Subject: Re: [PATCH] mm/hugetlb: Don't crash when allocating a folio if there are no resv
Date: Wed, 18 Jun 2025 17:02:48 -0700	[thread overview]
Message-ID: <20250618170248.89ff5c3d3fe23233424fd4da@linux-foundation.org> (raw)
In-Reply-To: <99b9f7c8-62e0-4500-b4f1-0efdb73bf502@arm.com>

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.

  reply	other threads:[~2025-06-19  0:03 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-18  5:28 [PATCH] mm/hugetlb: Don't crash when allocating a folio if there are no resv Vivek Kasireddy
2025-06-18  6:44 ` Anshuman Khandual
2025-06-19  0:02   ` Andrew Morton [this message]
2025-06-19  5:30     ` Kasireddy, Vivek
2025-06-23 23:35       ` Andrew Morton
2025-06-25 14:18         ` Kasireddy, Vivek
2025-06-25 20:46           ` Andrew Morton
2025-06-19 13:53 ` Oscar Salvador
2025-06-21  2:02   ` Kasireddy, Vivek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250618170248.89ff5c3d3fe23233424fd4da@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=anshuman.khandual@arm.com \
    --cc=david@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-mm@kvack.org \
    --cc=muchun.song@linux.dev \
    --cc=steven.sistare@oracle.com \
    --cc=syzbot+a504cb5bae4fe117ba94@syzkaller.appspotmail.com \
    --cc=vivek.kasireddy@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.