Re: [PATCH v8 2/2] slub: Introduce CONFIG_SLUB_RCU_DEBUG

[Jann Horn <jannh@google.com>]

Hi!

On Tue, Aug 13, 2024 at 11:03 AM Shinichiro Kawasaki
<shinichiro.kawasaki@wdc.com> wrote:
> Hello Jann, let me ask a question about this patch. When I tested the
> next-20240808 kernel which includes this patch, I observed that
> slab_free_after_rcu_debug() reports many WARNs. Please find my question in line.

Thanks for testing linux-next.

> On Aug 09, 2024 / 17:36, Jann Horn wrote:
[...]
> > +#ifdef CONFIG_SLUB_RCU_DEBUG
> > +static void slab_free_after_rcu_debug(struct rcu_head *rcu_head)
> > +{
> > +     struct rcu_delayed_free *delayed_free =
> > +                     container_of(rcu_head, struct rcu_delayed_free, head);
> > +     void *object = delayed_free->object;
> > +     struct slab *slab = virt_to_slab(object);
> > +     struct kmem_cache *s;
> > +
> > +     kfree(delayed_free);
> > +
> > +     if (WARN_ON(is_kfence_address(object)))
> > +             return;
>
> With the kernel configs above, I see the many WARNs are reported here.
> When SLUB_RCU_DEBUG is enabled, should I disable KFENCE?

These features are supposed to be compatible.

In the version you tested
(https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next-history.git/tree/mm/slub.c?h=next-20240808#n4550),
I made a mistake and wrote "if (WARN_ON(is_kfence_address(rcu_head)))"
instead of "if (WARN_ON(is_kfence_address(object)))". That issue was
fixed in v6 of the series after syzbot and the Intel test bot ran into
the same issue.