[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fedf0448966b44d5b9146508265874fd@AcuMS.aculab.com>
Date: Fri, 21 Jul 2023 11:51:39 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Alan Huang' <mmpgouride@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"rcu@...r.kernel.org" <rcu@...r.kernel.org>
CC: "Paul E. McKenney" <paulmck@...nel.org>,
Eric Dumazet <edumazet@...gle.com>,
"roman.gushchin@...ux.dev" <roman.gushchin@...ux.dev>
Subject: RE: Question about the barrier() in hlist_nulls_for_each_entry_rcu()
From: Alan Huang
> Sent: 20 July 2023 19:54
>
> I noticed a commit c87a124a5d5e(“net: force a reload of first item in hlist_nulls_for_each_entry_rcu”)
> and a related discussion [1].
Hmmm... that was all about the retry loop in ipv4/udp.c
AFAICT that retry got deleted by ca065d0c.
That also changes the list from hlist_nulls_xxx to hlist_xxx.
(I'm not sure of the difference)
This might be why we're seeing unexpected 'port unreachable' messages?
Quite why that has just started happening is another issue.
Most of the UDP sockets we create aren't 'connected' so I don't
believe they get moved between hash chains - just deleted.
The deletion should leave the hash chain intact.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists