From: Harry Yoo <harry.yoo@oracle.com>
To: Zi Yan <ziy@nvidia.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
Brendan Jackman <jackmanb@google.com>,
Johannes Weiner <hannes@cmpxchg.org>,
David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
"Liam R . Howlett" <Liam.Howlett@oracle.com>,
Mike Rapoport <rppt@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Shakeel Butt <shakeel.butt@linux.dev>,
linux-mm@kvack.org, stable@vger.kernel.org
Subject: Re: [PATCH] mm/page_alloc: skip debug_check_no_{obj,locks}_freed with FPI_TRYLOCK
Date: Sat, 7 Feb 2026 02:20:28 +0900 [thread overview]
Message-ID: <aYYi3DhceyKbta2Y@hyeyoo> (raw)
In-Reply-To: <7B9B9CF3-29A6-4271-8C3C-87FF3EB9FA4D@nvidia.com>
On Fri, Feb 06, 2026 at 12:08:04PM -0500, Zi Yan wrote:
> On 6 Feb 2026, at 11:58, Harry Yoo wrote:
>
> > When CONFIG_DEBUG_OBJECTS_FREE is enabled,
> > debug_check_no_{obj,locks}_freed() functions are called.
> >
> > Since both of them spin on a lock, they are not safe to be called
> > if the FPI_TRYLOCK flag is specified. This leads to a lockdep splat:
> >
> > ================================
> > WARNING: inconsistent lock state
> > 6.19.0-rc5-slab-for-next+ #326 Tainted: G N
> > --------------------------------
> > inconsistent {INITIAL USE} -> {IN-NMI} usage.
> > kunit_try_catch/9046 [HC2[2]:SC0[0]:HE0:SE1] takes:
> > ffffffff84ed6bf8 (&obj_hash[i].lock){-.-.}-{2:2}, at: __debug_check_no_obj_freed+0xe0/0x300
> > {INITIAL USE} state was registered at:
> > lock_acquire+0xd9/0x2f0
> > _raw_spin_lock_irqsave+0x4c/0x80
> > __debug_object_init+0x9d/0x1f0
> > debug_object_init+0x34/0x50
> > __init_work+0x28/0x40
> > init_cgroup_housekeeping+0x151/0x210
> > init_cgroup_root+0x3d/0x140
> > cgroup_init_early+0x30/0x240
> > start_kernel+0x3e/0xcd0
> > x86_64_start_reservations+0x18/0x30
> > x86_64_start_kernel+0xf3/0x140
> > common_startup_64+0x13e/0x148
> > irq event stamp: 2998
> > hardirqs last enabled at (2997): [<ffffffff8298b77a>] exc_nmi+0x11a/0x240
> > hardirqs last disabled at (2998): [<ffffffff8298b991>] sysvec_irq_work+0x11/0x110
> > softirqs last enabled at (1416): [<ffffffff813c1f72>] __irq_exit_rcu+0x132/0x1c0
> > softirqs last disabled at (1303): [<ffffffff813c1f72>] __irq_exit_rcu+0x132/0x1c0
> >
> > other info that might help us debug this:
> > Possible unsafe locking scenario:
> >
> > CPU0
> > ----
> > lock(&obj_hash[i].lock);
> > <Interrupt>
> > lock(&obj_hash[i].lock);
> >
> > *** DEADLOCK ***
> >
> > Fix this by adding an fpi_t parameter to free_pages_prepare() and
> > skipping those checks if FPI_TRYLOCK is set. Since mm/compaction.c
> > calls free_pages_prepare(), move the fpi_t definition to mm/internal.h.
> >
> > Fixes: 8c57b687e833 ("mm, bpf: Introduce free_pages_nolock()")
> > Cc: <stable@vger.kernel.org>
> > Signed-off-by: Harry Yoo <harry.yoo@oracle.com>
> > ---
> > mm/compaction.c | 2 +-
> > mm/internal.h | 35 ++++++++++++++++++++++++++++++++++-
> > mm/page_alloc.c | 42 ++++++------------------------------------
> > 3 files changed, 41 insertions(+), 38 deletions(-)
> >
> > diff --git a/mm/compaction.c b/mm/compaction.c
> > index 1e8f8eca318c..9ffeb7c6d2b0 100644
> > --- a/mm/compaction.c
> > +++ b/mm/compaction.c
> > @@ -1859,7 +1859,7 @@ static void compaction_free(struct folio *dst, unsigned long data)
> > struct page *page = &dst->page;
> >
> > if (folio_put_testzero(dst)) {
> > - free_pages_prepare(page, order);
> > + free_pages_prepare(page, order, FPI_NONE);
>
> Is it OK to add something like free_pages_prepare_fpi_none() for this one
> to avoid the FPI flag move?
Yeah, moving FPI flag definition isn't great :)
I'm totally fine with your suggestion,
as long as page allocator/compaction folks are fine with it!
--
Cheers,
Harry / Hyeonggon
next prev parent reply other threads:[~2026-02-06 17:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-06 16:58 [PATCH] mm/page_alloc: skip debug_check_no_{obj,locks}_freed with FPI_TRYLOCK Harry Yoo
2026-02-06 17:08 ` Zi Yan
2026-02-06 17:20 ` Harry Yoo [this message]
2026-02-06 17:34 ` Vlastimil Babka
2026-02-07 1:26 ` Harry Yoo
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=aYYi3DhceyKbta2Y@hyeyoo \
--to=harry.yoo@oracle.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=ast@kernel.org \
--cc=bigeasy@linutronix.de \
--cc=david@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=jackmanb@google.com \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mhocko@suse.com \
--cc=rppt@kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=stable@vger.kernel.org \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--cc=ziy@nvidia.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.