mm/slub: fix memory leak in free_to_pcs_bulk()

The commit 989b09b73978 ("slab: skip percpu sheaves for remote object
freeing") introduced the remote_objects array in free_to_pcs_bulk() to
skip sheaves when objects from a remote node are freed.

However, the array is flushed only when:
1) the array becomes full (++remote_nr >= PCS_BATCH_MAX), or
2) slab_free_hook() returns false and size becomes zero.

When neither of the conditions is met, objects in the array are leaked.
This resulted in a memory leak [1], where 82 GiB of memory was allocated
for the maple_node cache.

Flush the array after successfully freeing objects to sheaves
in the do_free: path.

In the meantime, move the snippet if (!size) goto flush_remote; outside
the while loop for readability. Let's say all objects in the array are
from a remote node: then we acquire s->cpu_sheaves->lock and try to free
an object even when size is zero. This doesn't appear to be harmful,
but isn't really readable.

Reported-by: Tytus Rogalewski <[e-mail]>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220765 [1]
Closes: https://lore.kernel.org/linux-mm/[e-mail]
Closes: https://lore.kernel.org/all/aRGDTwbt2EIz2CYn@hyeyoo
Fixes: 989b09b73978 ("slab: skip percpu sheaves for remote object freeing")
Signed-off-by: Harry Yoo <[e-mail]>
Link: https://patch.msgid.link/[e-mail]
Acked-by: Liam R. Howlett <[e-mail]>
Tested-by: Darrick J. Wong <[e-mail]>
Tested-by: Tytus Rogalewski <[e-mail]>
Signed-off-by: Vlastimil Babka <[e-mail]>

mm/slub.c

···
 
 		if (unlikely(!slab_free_hook(s, p[i], init, false))) {
 			p[i] = p[--size];
-			if (!size)
-				goto flush_remote;
 			continue;
 		}
 
···
 
 		i++;
 	}
+
+	if (!size)
+		goto flush_remote;
 
 next_batch:
 	if (!local_trylock(&s->cpu_sheaves->lock))
···
 		size -= batch;
 		goto next_batch;
 	}
+
+	if (remote_nr)
+		goto flush_remote;
 
 	return;