[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <caaf8d102fc520116d66121b7285c191802199c0.camel@redhat.com>
Date: Wed, 24 Apr 2024 15:46:17 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: "David S . Miller" <davem@...emloft.net>, Jakub Kicinski
<kuba@...nel.org>, David Ahern <dsahern@...nel.org>,
netdev@...r.kernel.org, eric.dumazet@...il.com, Joel Fernandes
<joel@...lfernandes.org>, "Paul E . McKenney" <paulmck@...nel.org>
Subject: Re: [PATCH net-next] net: add two more call_rcu_hurry()
On Wed, 2024-04-24 at 15:01 +0200, Eric Dumazet wrote:
> Hi Paolo
>
> On Wed, Apr 24, 2024 at 10:01 AM Paolo Abeni <pabeni@...hat.com> wrote:
> >
> > On Tue, 2024-04-23 at 20:54 +0000, Eric Dumazet wrote:
> > > I had failures with pmtu.sh selftests lately,
> > > with netns dismantles firing ref_tracking alerts [1].
> > >
> > > After much debugging, I found that some queued
> > > rcu callbacks were delayed by minutes, because
> > > of CONFIG_RCU_LAZY=y option.
> > >
> > > Joel Fernandes had a similar issue in the past,
> > > fixed with commit 483c26ff63f4 ("net: Use call_rcu_hurry()
> > > for dst_release()")
> > >
> > > In this commit, I make sure nexthop_free_rcu()
> > > and free_fib_info_rcu() are not delayed too much
> > > because they both can release device references.
> >
> > Great debugging!
> >
> > I'm wondering how many other similar situations we have out there???
>
> I think there is another candidate for inet_free_ifa()
>
> diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
> index 7592f242336b7fdf67e79dbd75407cf03e841cfc..cd2f0af7240899795abff0087730db2bb755c36e
> 100644
> --- a/net/ipv4/devinet.c
> +++ b/net/ipv4/devinet.c
> @@ -231,7 +231,7 @@ static void inet_rcu_free_ifa(struct rcu_head *head)
>
> static void inet_free_ifa(struct in_ifaddr *ifa)
> {
> - call_rcu(&ifa->rcu_head, inet_rcu_free_ifa);
> + call_rcu_hurry(&ifa->rcu_head, inet_rcu_free_ifa);
> }
>
>
> >
> > Have you considered instead adding a synchronize_rcu() alongside the
> > rcu_barrier() in netdev_wait_allrefs_any()? If I read correctly commit
> > 483c26ff63f4, That should kick all the possibly pending lazy rcu
> > operation.
>
> synchronize_rcu() could return very fast, even if queued rcu items are
> still lingering.
>
> I tried the following patch, this does not help.
>
> Were you thinking of something else ?
I'm not sure if the _expedited() variant implies the call_rcu_hurry()
needed to flush the pending lazy callbacks. My expectation was "yes",
but quickly skimming over the code hints otherwise.
Additionally, re-reading the 483c26ff63f4 changelog, I now think
synchornize_rcu() will kick the pending lazy callback only on the
current CPU, which should not be enough here.
I guess your original patch is the only option.
Thanks for the additional investigation,
Paolo
Powered by blists - more mailing lists