Re: netlink: Disable insertions/removals during rehash

[Guenter Roeck <linux@roeck-us.net>]

On Sat, May 16, 2015 at 05:10:19PM -0400, David Miller wrote:
> From: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Sat, 16 May 2015 21:16:28 +0800
> 
> > On Fri, May 15, 2015 at 01:02:57PM -0400, David Miller wrote:
> >> From: Herbert Xu <herbert@gondor.apana.org.au>
> >> Date: Thu, 14 May 2015 13:58:24 +0800
> >> 
> >> > The current rhashtable rehash code is buggy and can't deal with
> >> > parallel insertions/removals without corrupting the hash table.
> >> > 
> >> > This patch disables it by partially reverting
> >> > c5adde9468b0714a051eac7f9666f23eb10b61f7 ("netlink: eliminate
> >> > nl_sk_hash_lock").
> >> > 
> >> > This patch also removes a bogus socket lock introduced by that
> >> > very same patch.
> >> > 
> >> > Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> >> 
> >> Herbert, if you agree with me in the other thread that the lock_sock()
> >> or something like it has to remain, you'll need to respin this.
> > 
> > Actually I think this one is OK because I'm replacing it with the
> > hash table mutex which is just like the previous global lock except
> > that it is per-family.  As you cannot change the family on a netlink
> > socket this should be good enough.
> > 
> > But the changelog message is wrong so here is an updated version.
> > 
> > Cheers,
> > 
> > ---8<---
> > The current rhashtable rehash code is buggy and can't deal with
> > parallel insertions/removals without corrupting the hash table.
> > 
> > This patch disables it by partially reverting
> > c5adde9468b0714a051eac7f9666f23eb10b61f7 ("netlink: eliminate
> > nl_sk_hash_lock").
> > 
> > Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> 
> Ok, I've queued this up for -stable, thanks Herbert.
> 
Hi David,

sorry for bothering you - I don't see this patch in any of your trees,
and it is marked as "changes requested" in patchwork. Did I look
at the wrong places, do you still plan to apply the patch as-is,
or do you expect some changes ?

As side info, I have been trying to track down the getaddrinfo
hang problem observed by others, which we see in 3.19.4 and 4.0.4.

Thanks,
Guenter