[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-can
Subject:    Re: [PATCH] can: gw: prefer kfree_rcu() over call_rcu() with cgw_job_free_rcu()
From:       Eric Dumazet <edumazet () google ! com>
Date:       2024-03-13 14:04:12
Message-ID: CANn89iKGayUU2cg+ibQeEqWhw-mD+b4x_k+fm7xjis52f8q82g () mail ! gmail ! com
[Download RAW message or body]

On Wed, Mar 13, 2024 at 3:01 PM Dmitry Antipov <dmantipov@yandex.ru> wrote:
>
> On 3/13/24 13:55, Eric Dumazet wrote:
>
> > kmem_cache_free(struct kmem_cache *s, void *x) has additional checks
> > to make sure the object @x was allocated
> > from the @s kmem_cache.
> >
> > Look for SLAB_CONSISTENCY_CHECKS and CONFIG_SLAB_FREELIST_HARDENED
>
> Yes. Using kfree_rcu() bypasses these (optional) debugging/consistency
> checks.
>
> > Your patch is not 'trivial' as you think.
>
> You're shifting from "not going to work" to "not trivial" so nicely.

You used the word "trivial" in the changelog, not me.

>
> > Otherwise, we will soon have dozen of patches submissions replacing
> > kmem_cache_free() with kfree()
>
> No. The question is about freeing on some (where the freeing callback
> function is trivial) RCU-protected paths only.
>

I am saying no to this patch.

[prev in list] [next in list] [prev in thread] [next in thread]