diff mbox series

[v3] rhashtable: Still do rehash when we get EEXIST

Message ID 20190321013952.3quw6bsqptyngzo5@gondor.apana.org.au
State Accepted
Delegated to: David Miller
Headers show
Series [v3] rhashtable: Still do rehash when we get EEXIST | expand

Commit Message

Herbert Xu March 21, 2019, 1:39 a.m. UTC 
On Wed, Mar 20, 2019 at 03:29:17PM -0700, Josh Hunt wrote:
>
> Herbert
> 
> We're seeing this pretty regularly on 4.14 LTS kernels. I didn't see your
> change in any of the regular trees. Are there plans to submit this? If so,
> can it get queued up for 4.14 stable too?

Hi Josh:

Thanks for reminding me.  Looks like this one slipped through the
cracks.

Dave, could you please apply this? Thanks!

---8<---
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>

Comments

Herbert Xu March 21, 2019, 1:46 a.m. UTC | #1 
On Thu, Mar 21, 2019 at 09:39:52AM +0800, Herbert Xu wrote:
>
> Dave, could you please apply this? Thanks!

I forgot to include the tested-by so here it is for patchwork:

Tested-by: Josh Elsasser <jelsasser@appneta.com>
David Miller March 21, 2019, 8:58 p.m. UTC | #2 
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 21 Mar 2019 09:39:52 +0800

> 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>

Applied and queued up for -stable, thanks Herbert.
David Miller March 21, 2019, 8:58 p.m. UTC | #3 
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 21 Mar 2019 09:46:15 +0800

> On Thu, Mar 21, 2019 at 09:39:52AM +0800, Herbert Xu wrote:
>>
>> Dave, could you please apply this? Thanks!
> 
> I forgot to include the tested-by so here it is for patchwork:
> 
> Tested-by: Josh Elsasser <jelsasser@appneta.com>

Thanks for providing this.
diff mbox series

Patch

diff --git a/lib/rhashtable.c b/lib/rhashtable.c
index 852ffa5160f1..4edcf3310513 100644
--- 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);