[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CANn89iKGayUU2cg+ibQeEqWhw-mD+b4x_k+fm7xjis52f8q82g@mail.gmail.com>
Date: Wed, 13 Mar 2024 15:04:12 +0100
From: Eric Dumazet <edumazet@...gle.com>
To: Dmitry Antipov <dmantipov@...dex.ru>
Cc: Oliver Hartkopp <socketcan@...tkopp.net>, Marc Kleine-Budde <mkl@...gutronix.de>,
linux-can@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH] can: gw: prefer kfree_rcu() over call_rcu() with cgw_job_free_rcu()
On Wed, Mar 13, 2024 at 3:01 PM Dmitry Antipov <dmantipov@...dex.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.
Powered by blists - more mailing lists