Commit 408f13ef authored Mar 21, 2019 by Herbert Xu Committed by David S. Miller Mar 21, 2019

rhashtable: Still do rehash when we get EEXIST



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: da20420f ("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>

parent 6b70fc94

lib/rhashtable.c

+6 −2

Original line number	Diff line number	Diff line
		@@ -416,8 +416,12 @@ static void rht_deferred_worker(struct work_struct *work)
		else if (tbl->nest)
		err = rhashtable_rehash_alloc(ht, tbl, tbl->size);

		if (!err)
		err = rhashtable_rehash_table(ht);
		if (!err \|\| err == -EEXIST) {
		int nerr;

		nerr = rhashtable_rehash_table(ht);
		err = err ?: nerr;
		}

		mutex_unlock(&ht->mutex);

Admin message