On 3/2/26 04:41, Qing Wang wrote:
> #syz test
>
> diff --git a/mm/slub.c b/mm/slub.c
> index cdc1e652ec52..387979b89120 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -6307,15 +6307,21 @@ bool __kfree_rcu_sheaf(struct kmem_cache *s, void
> *obj)
> goto fail;
>
> if (!local_trylock(&s->cpu_sheaves->lock)) {
> - barn_put_empty_sheaf(barn, empty);
> + if (barn && data_race(barn->nr_empty) <
> MAX_EMPTY_SHEAVES)
> + barn_put_empty_sheaf(barn, empty);
> + else
> + free_empty_sheaf(s, empty);
> goto fail;
> }
>
> pcs = this_cpu_ptr(s->cpu_sheaves);
>
> - if (unlikely(pcs->rcu_free))
> - barn_put_empty_sheaf(barn, empty);
> - else
> + if (unlikely(pcs->rcu_free)) {
> + if (barn && data_race(barn->nr_empty) <
> MAX_EMPTY_SHEAVES)
> + barn_put_empty_sheaf(barn, empty);
> + else
> + free_empty_sheaf(s, empty);
> + } else
> pcs->rcu_free = empty;
> }
I don't think this would fix any leak, and syzbot agrees. It would limit the
empty sheaves in barn more strictly, but they are not leaked.
Hm I don't see any leak in __kfree_rcu_sheaf() or rcu_free_sheaf(). Wonder
if kmemleak lacks visibility into barns or pcs's as roots for searching what
objects are considered referenced, or something?
_______________________________________________
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
