From: Harry Yoo <harry.yoo@oracle.com>
To: Lilith Gkini <lilithpgkini@gmail.com>
Cc: Vlastimil Babka <vbabka@suse.cz>,
Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Hyeonggon Yoo <42.hyeyoo@gmail.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] slub: Adds a way to handle freelist cycle in on_freelist()
Date: Thu, 6 Mar 2025 17:34:36 +0900 [thread overview]
Message-ID: <Z8leHDicTjUR9850@harry> (raw)
In-Reply-To: <Z8hyV4sROVDtwRDE@Arch>
Hi Lilith, the patch looks good, and it's great to see the improvements
over the revisions! I've added my Reviewed-by: tag after the '---' line.
A few nit comments are inlined below.
From Documentation/process/submitting-patches.rst:
> Describe your changes in imperative mood, e.g. “make xyzzy do frotz”
> instead of “[This patch] makes xyzzy do frotz” or
> “[I] changed xyzzy to do frotz”, as if you are giving orders to the codebase
> to change its behaviour.
nit: Per submitting-patches.rst, I think the subject could be:
- "slub: Add a way to handle freelist cycle in on_freelist()"
or more concisely,
- "slub: Handle freelist cycle in on_freelist()"
On Wed, Mar 05, 2025 at 05:48:39PM +0200, Lilith Gkini wrote:
> The on_freelist() doesn't have a way to handle the edgecase of having a
> full freelist that doesn't end in NULL and instead has another valid
> pointer in the slab as a result of a Use-After-Free or anything similar.
>
> This case won't get caught by check_valid_pointer() and it will result in
> nr incrementing to `slab->objects + 1`, corrupting the slab->inuse entry
> later in the code by setting it to -1.
>
> The Patch adds an if check to detect that case, notifies us and handles
> the freelist and slab appropriately, as is the standard process in these
> situations.
>
> Furthermore the Patch changes the return type of the function from
> int to bool as per codying style guidelines.
nit: codying -> coding
> It also moves the `break;` line inside the `if (object) {` to make it more
> obvious that the code breaks the while loop in that branch.
>
> Signed-off-by: Lilith Persefoni Gkini <lilithgkini@proton.me>
> ---
Looks good to me,
Reviewed-by: Harry Yoo <harry.yoo@oracle.com>
--
Cheers,
Harry
> mm/slub.c | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/mm/slub.c b/mm/slub.c
> index 1f50129dcfb3..95e54ffd5330 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -1427,7 +1427,7 @@ static int check_slab(struct kmem_cache *s, struct slab *slab)
> * Determine if a certain object in a slab is on the freelist. Must hold the
> * slab lock to guarantee that the chains are in a consistent state.
> */
> -static int on_freelist(struct kmem_cache *s, struct slab *slab, void *search)
> +static bool on_freelist(struct kmem_cache *s, struct slab *slab, void *search)
> {
> int nr = 0;
> void *fp;
> @@ -1437,26 +1437,34 @@ static int on_freelist(struct kmem_cache *s, struct slab *slab, void *search)
> fp = slab->freelist;
> while (fp && nr <= slab->objects) {
> if (fp == search)
> - return 1;
> + return true;
> if (!check_valid_pointer(s, slab, fp)) {
> if (object) {
> object_err(s, slab, object,
> "Freechain corrupt");
> set_freepointer(s, object, NULL);
> + break;
> } else {
> slab_err(s, slab, "Freepointer corrupt");
> slab->freelist = NULL;
> slab->inuse = slab->objects;
> slab_fix(s, "Freelist cleared");
> - return 0;
> + return false;
> }
> - break;
> }
> object = fp;
> fp = get_freepointer(s, object);
> nr++;
> }
>
> + if (nr > slab->objects) {
> + slab_err(s, slab, "Freelist cycle detected");
> + slab->freelist = NULL;
> + slab->inuse = slab->objects;
> + slab_fix(s, "Freelist cleared");
> + return false;
> + }
> +
> max_objects = order_objects(slab_order(slab), s->size);
> if (max_objects > MAX_OBJS_PER_PAGE)
> max_objects = MAX_OBJS_PER_PAGE;
> --
> 2.48.1
>
next prev parent reply other threads:[~2025-03-06 8:34 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-02 18:01 [PATCH] slub: Fix Off-By-One in the While condition " Lilith Persefoni Gkini
2025-03-03 11:06 ` Vlastimil Babka
2025-03-03 16:41 ` Lilith Gkini
2025-03-03 17:39 ` Christoph Lameter (Ampere)
2025-03-03 19:06 ` Vlastimil Babka
2025-03-04 8:24 ` Lilith Gkini
2025-03-04 8:41 ` Vlastimil Babka
2025-03-04 11:06 ` Lilith Gkini
2025-03-04 11:20 ` Vlastimil Babka
2025-03-04 12:18 ` Lilith Gkini
2025-03-04 14:25 ` Vlastimil Babka
2025-03-04 17:14 ` Lilith Gkini
2025-03-05 15:48 ` [PATCH] slub: Adds a way to handle freelist cycle " Lilith Gkini
2025-03-06 8:34 ` Harry Yoo [this message]
2025-03-06 8:46 ` Vlastimil Babka
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=Z8leHDicTjUR9850@harry \
--to=harry.yoo@oracle.com \
--cc=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=lilithpgkini@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=vbabka@suse.cz \
/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