[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150604162727.GA2670@roeck-us.net>
Date: Thu, 4 Jun 2015 09:27:27 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: David Miller <davem@...emloft.net>
Cc: herbert@...dor.apana.org.au, eric.dumazet@...il.com, tgraf@...g.ch,
netdev@...r.kernel.org
Subject: Re: netlink: Disable insertions/removals during rehash
On Sat, May 16, 2015 at 05:10:19PM -0400, David Miller wrote:
> From: Herbert Xu <herbert@...dor.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@...dor.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@...dor.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@...dor.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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists