From: Shardul Bankar <shardul.b@mpiricsoftware.com>
To: "David Hildenbrand (Red Hat)" <david@kernel.org>,
willy@infradead.org, linux-mm@kvack.org,
akpm@linux-foundation.org
Cc: dev.jain@arm.com, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, janak@mpiricsoftware.com,
shardulsb08@gmail.com
Subject: Re: [PATCH v3] lib: xarray: free unused spare node in xas_create_range()
Date: Thu, 04 Dec 2025 19:45:59 +0530 [thread overview]
Message-ID: <78c9b5eeb10051dd9791ed3cb0ce7a18eedc5e7f.camel@mpiricsoftware.com> (raw)
In-Reply-To: <57d5793d-2343-49b3-a30c-cd12dc40460d@kernel.org>
On Mon, 2025-12-01 at 09:39 +0100, David Hildenbrand (Red Hat) wrote:
> Please don't post new versions as reply to old versions.
> ...
>
> ...
> The first thing xas_destroy() does is check whether xa_alloc is set.
>
> I'd assume that the compiler is smart enough to inline xas_destroy()
> completely here, so likely the xa_alloc check here can just be
> dropped.
Got it, will share a v4 of the patch on a new chain with redundant
xas_destroy() removed.
> Staring at xas_destroy() callers, we only have a single one outside
> of
> lib: mm/huge_memory.c:__folio_split()
>
> Is that one still required?
I checked the callers of xas_destroy(). Apart from the internal uses in
lib/xarray.c and the unit tests in lib/test_xarray.c, the only external
user is indeed mm/huge_memory.c:__folio_split().
That path is slightly different from the xas_nomem() retry loop I fixed
in xas_create_range():
__folio_split() goes through xas_split_alloc() and then
xas_split() / xas_try_split(), which allocate and consume nodes via
xas->xa_alloc.
The final xas_destroy(&xas) in __folio_split() is there to
drop any leftover split-allocation nodes, not the xas_nomem() spare
node I handled in xas_create_range().
So with the current code I don’t think I can safely declare that
xas_destroy() in __folio_split() is redundant- it still acts as the
last cleanup for the split helpers.
For v4 I’d therefore like to keep the scope focused on the syzkaller
leak and just drop the redundant "if (xa_alloc)" around xas_destroy()
in xas_create_range() as you suggested.
Separately, I agree it would be cleaner if the split helpers guaranteed
that xa_alloc is always cleared on return, so callers never have to
think about xas_destroy(). I can take a closer look at xas_split() /
xas_try_split() and, if it looks sound, propose a small follow-up
series that makes their cleanup behaviour explicit and then removes the
xas_destroy() from __folio_split().
Thanks,
Shardul
next prev parent reply other threads:[~2025-12-04 14:16 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-23 13:27 [PATCH] mm: khugepaged: fix memory leak in collapse_file rollback path Shardul Bankar
2025-11-23 14:49 ` Dev Jain
2025-11-24 10:02 ` David Hildenbrand (Red Hat)
2025-11-24 11:46 ` Dev Jain
2025-11-24 15:23 ` Shardul Bankar
2025-11-24 16:11 ` [PATCH v2] mm: khugepaged: fix memory leak in collapse_file xas retry loop Shardul Bankar
2025-11-24 16:21 ` Matthew Wilcox
2025-11-24 17:37 ` Shardul Bankar
2025-12-01 7:45 ` [PATCH v3] lib: xarray: free unused spare node in xas_create_range() Shardul Bankar
2025-12-01 8:39 ` David Hildenbrand (Red Hat)
2025-12-04 14:15 ` Shardul Bankar [this message]
2025-12-04 21:15 ` David Hildenbrand (Red Hat)
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=78c9b5eeb10051dd9791ed3cb0ce7a18eedc5e7f.camel@mpiricsoftware.com \
--to=shardul.b@mpiricsoftware.com \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=janak@mpiricsoftware.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=shardulsb08@gmail.com \
--cc=willy@infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox