On Thu, Feb 20, 2025 at 05:20:00PM +0900, Harry Yoo wrote:
> On Sat, Feb 15, 2025 at 06:57:01PM +0200, Lilitha Persefoni Gkini wrote:
> > The condition `nr <= slab->objects` in the `on_freelist()` serves as
> > bound while walking through the `freelist` linked list because we can't
> > have more free objects than the maximum amount of objects in the slab.
> > But the `=` can result in an extra unnecessary iteration.
> >
> > The patch changes it to `nr < slab->objects` to ensure it iterates
> > at most `slab->objects` number of times.
> >
> > Signed-off-by: Lilitha Persefoni Gkini <lilithpgkini@xxxxxxxxx>
> > ---
> > mm/slub.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/mm/slub.c b/mm/slub.c
> > index 1f50129dcfb3..ad42450d4b0f 100644
> > --- a/mm/slub.c
> > +++ b/mm/slub.c
> > @@ -1435,7 +1435,7 @@ static int on_freelist(struct kmem_cache *s, struct slab *slab, void *search)
> > int max_objects;
> >
> > fp = slab->freelist;
> > - while (fp && nr <= slab->objects) {
> > + while (fp && nr < slab->objects) {
>
> Hi, this makes sense to me.
>
> But based on what the name of the variable suggests (nr of objects),
> I think it makes clearer to initialize it to 1 instead?
Oh, actually iterating at most (slab->objects + 1) times allows it to catch
cases where the freelist does not end with NULL (see how validate_slab()
calls on_freelist(), passing search = NULL).
It's very subtle. A comment like this would help:
/*
* Iterate at most slab->objects + 1 times to handle cases
* where the freelist does not end with NULL.
*/
--
Cheers,
Harry
