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: da20420 ("rhashtable: Add nested tables") Reported-by: Josh Elsasser <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Tested-by: Josh Elsasser <[email protected]> Signed-off-by: David S. Miller <[email protected]>
ashr · Mar 21, 2019 · 408f13e · 408f13e
1 parent 6b70fc9
commit 408f13e
Showing 1 changed file with 6 additions and 2 deletions.
diff --git a/lib/rhashtable.c b/lib/rhashtable.c
@@ -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);