rhashtable: Still do rehash when we get EEXIST
authorHerbert Xu <herbert@gondor.apana.org.au>
Thu, 21 Mar 2019 01:39:52 +0000 (09:39 +0800)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 3 Apr 2019 04:25:09 +0000 (06:25 +0200)
commit9f6e90284fcf0e710630899d94e80982f58c8441
tree85d5b0650dc6cf067953dbaf89e0585480662220
parent68979f5eccc6ecc2630e6edc7c0d0a915d3d630b
rhashtable: Still do rehash when we get EEXIST

[ Upstream commit 408f13ef358aa5ad56dc6230c2c7deb92cf462b1 ]

As it stands if a shrink is delayed because of an outstanding
rehash, we will go into a rescheduling loop without ever doing
the rehash.

This patch fixes this by still carrying out the rehash and then
rescheduling so that we can shrink after the completion of the
rehash should it still be necessary.

The return value of EEXIST captures this case and other cases
(e.g., another thread expanded/rehashed the table at the same
time) where we should still proceed with the rehash.

Fixes: da20420f83ea ("rhashtable: Add nested tables")
Reported-by: Josh Elsasser <jelsasser@appneta.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Tested-by: Josh Elsasser <jelsasser@appneta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
lib/rhashtable.c