On Fri, Jul 26, 2024 at 11:34:57AM +0200, Vlastimil Babka wrote:
> On 7/25/24 7:59 AM, kernel test robot wrote:
> >
> > hi, Vlastimil Babka,
> >
> > we noticed by this commit:
> >
> > 7fd4dfd0d38db6f3 df00e211c9c11e8d20f2ea7b4ab
> > ---------------- ---------------------------
> > fail:runs %reproduction fail:runs
> > | | |
> > 6:6 -100% :6
> > dmesg.WARNING:at_mm/slab_common.c:#kmem_cache_destroy
> > :6 100% 6:6
> > dmesg.WARNING:at_mm/slab_common.c:#kmem_cache_kfree_rcu_destroy_workfn
> >
> > below formal report just FYI what we observed in our tests. not sure if it's
> > valuable to supply any hints.
> >
> >
> > Hello,
> >
> > kernel test robot noticed
> > "WARNING:at_mm/slab_common.c:#kmem_cache_kfree_rcu_destroy_workfn" on:
> >
> > commit: df00e211c9c11e8d20f2ea7b4ab1d7c9760fe822 ("mm, slab: asynchronously
> > destroy caches with outstanding objects")
> > https://git.kernel.org/cgit/linux/kernel/git/vbabka/linux.git
> > slab-kfree_rcu-destroy-v1r0
>
> Yes, that's expected proves we need the proper barrier added from the RCU
> folks :)
>
Give me some time, i will implement it! After discussion with Paul it
should not be so hard :)
Thanks!
--
Uladzislau Rezki
