[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANn89iJJEp9MiRrxzwkd7w-nHK7iQ42qGco3e3QhrOZmOaa7RA@mail.gmail.com>
Date: Wed, 24 Apr 2024 15:01:18 +0200
From: Eric Dumazet <edumazet@...gle.com>
To: Paolo Abeni <pabeni@...hat.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()
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 ?
diff --git a/net/core/dev.c b/net/core/dev.c
index 8bdc59074b29c287e432c73fffbe93c63d539ad2..a727290011693081b13ac6065e2ff2810bb5739d
100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -10559,6 +10559,7 @@ static struct net_device
*netdev_wait_allrefs_any(struct list_head *list)
rebroadcast_time = jiffies;
}
+ synchronize_rcu_expedited();
if (!wait) {
rcu_barrier();
wait = WAIT_REFS_MIN_MSECS;
>
> The patch LGTM, I'm just "thinking aloud".
>
> Thanks,
>
> Paolo
>
Powered by blists - more mailing lists