From: "Linus Lüssing" <linus.luessing@c0d3.blue>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: b.a.t.m.a.n@lists.open-mesh.org,
Dmitry Antipov <dmantipov@yandex.ru>,
netdev@vger.kernel.org, rcu@vger.kernel.org
Subject: Re: [PATCH] Revert "batman-adv: prefer kfree_rcu() over call_rcu() with free-only callbacks"
Date: Wed, 12 Jun 2024 16:54:49 +0200 [thread overview]
Message-ID: <Zmm2uTHTge-i3eCM@sellars> (raw)
In-Reply-To: <ZmmzE6Przj0pCHek@sellars>
On Wed, Jun 12, 2024 at 04:39:15PM +0200, Linus Lüssing wrote:
> On Wed, Jun 12, 2024 at 07:06:04AM -0700, Paul E. McKenney wrote:
> > Let me make sure that I understand...
> >
> > You need rcu_barrier() to wait for any memory passed to kfree_rcu()
> > to actually be freed? If so, please explain why you need this, as
> > in what bad thing happens if the actual kfree() happens later.
> >
> > (I could imagine something involving OOM avoidance, but I need to
> > hear your code's needs rather than my imaginations.)
> >
> > Thanx, Paul
> [...]
> As far as I understand before calling kmem_cache_destroy()
> we need to ensure that all previously allocated objects on this
> kmem-cache were free'd. At least we get this kernel splat
> (from Slub?) otherwise. I'm not quite sure if any other bad things
> other than this noise in dmesg would occur though. Other than a
> [...]
I guess, without knowing the details of RCU and Slub, that at
least nothing super serious, like a segfault, can happen when
the remaining execution is just a kfree(), which won't need
access to batman-adv internal functions anymore.
next prev parent reply other threads:[~2024-06-12 14:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-12 13:33 [PATCH] Revert "batman-adv: prefer kfree_rcu() over call_rcu() with free-only callbacks" Linus Lüssing
2024-06-12 14:06 ` Paul E. McKenney
2024-06-12 14:39 ` Linus Lüssing
2024-06-12 14:54 ` Linus Lüssing [this message]
2024-06-12 16:06 ` Paul E. McKenney
2024-06-12 16:31 ` Linus Lüssing
2024-06-12 18:22 ` Sven Eckelmann
2024-06-12 15:01 ` Paul E. McKenney
2024-06-12 16:25 ` Uladzislau Rezki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zmm2uTHTge-i3eCM@sellars \
--to=linus.luessing@c0d3.blue \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
--cc=dmantipov@yandex.ru \
--cc=netdev@vger.kernel.org \
--cc=paulmck@kernel.org \
--cc=rcu@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.