[PATCH v2] rhashtable: fix for resize events during table walk
If rhashtable_walk_next detects a resize operation in progress, it jumps
to the new table and continues walking that one. But it misses to drop
the reference to it's current item, leading it to continue traversing
the new table's bucket in which the current item is sorted into, and
after reaching that bucket's end continues traversing the new table's
second bucket instead of the first one, thereby potentially missing
items.
This fixes the rhashtable runtime test for me. Bug probably introduced
by Herbert Xu's patch eddee5ba ("rhashtable: Fix walker behaviour during
rehash") although not explicitly tested.
Fixes: eddee5ba ("rhashtable: Fix walker behaviour during rehash")
Signed-off-by: Phil Sutter
---
Changes since v1:
- Use simplified solution suggested by Herbert Xu.
---
lib/rhashtable.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/rhashtable.c b/lib/rhashtable.c
index a60a6d3..cc0c697 100644
--- a/lib/rhashtable.c
+++ b/lib/rhashtable.c
@@ -610,6 +610,8 @@ next:
iter->skip = 0;
}
+ iter->p = NULL;
+
/* Ensure we see any new tables. */
smp_rmb();
@@ -620,8 +622,6 @@ next:
return ERR_PTR(-EAGAIN);
}
- iter->p = NULL;
-
return NULL;
}
EXPORT_SYMBOL_GPL(rhashtable_walk_next);
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] rhashtable: fix for resize events during table walk
On 07/15/15 at 12:35am, mr...@linux.ee wrote: > Yes, this fixes the error, thank you. > > The new problem with the test - soft lockup - CPU#0 stuck for 22s! is > still there on 360 MHz UltraSparc IIi. I understand it is harmless but > is there some easy way to make the test avoid NMI watchdog? > > [ 58.374173] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! > [swapper:1] They don't show up on my system. I will add a schedule() call to the long loops. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] rhashtable: fix for resize events during table walk
> If rhashtable_walk_next detects a resize operation in progress, it jumps
> to the new table and continues walking that one. But it misses to drop
> the reference to it's current item, leading it to continue traversing
> the new table's bucket in which the current item is sorted into, and
> after reaching that bucket's end continues traversing the new table's
> second bucket instead of the first one, thereby potentially missing
> items.
>
> This fixes the rhashtable runtime test for me. Bug probably introduced
> by Herbert Xu's patch eddee5ba ("rhashtable: Fix walker behaviour during
> rehash") although not explicitly tested.
>
> Fixes: eddee5ba ("rhashtable: Fix walker behaviour during rehash")
> Signed-off-by: Phil Sutter
Yes, this fixes the error, thank you.
The new problem with the test - soft lockup - CPU#0 stuck for 22s! is
still there on 360 MHz UltraSparc IIi. I understand it is harmless but
is there some easy way to make the test avoid NMI watchdog?
[ 58.374173] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper:1]
[ 58.374293] Modules linked in:
[ 58.374387] irq event stamp: 144
[ 58.374461] hardirqs last enabled at (143): [<00404b1c>]
rtrap_xcall+0x18/0x20
[ 58.374621] hardirqs last disabled at (144): [<00426b28>]
sys_call_table+0x5ac/0x744
[ 58.374788] softirqs last enabled at (142): [<0045f5fc>]
__do_softirq+0x4fc/0x680
[ 58.374958] softirqs last disabled at (135): [<0042be28>]
do_softirq_own_stack+0x28/0x40
[ 58.375148] CPU: 0 PID: 1 Comm: swapper Not tainted 4.2.0-rc2-00077-gf760b87
#20
[ 58.375248] task: f8001f09ef60 ti: f8001f0fc000 task.ti:
f8001f0fc000
[ 58.375348] TSTATE: 004480001601 TPC: 0049663c TNPC:
00496640 Y: Not tainted
[ 58.375497] TPC:
[ 58.375579] g0: 00b1d000 g1: 0002 g2: 00a88000
g3: 007f
[ 58.375699] g4: f8001f09ef60 g5: g6: f8001f0fc000
g7: 2f23003c7b80
[ 58.375817] o0: o1: 0002 o2: 0620
o3: f8001f09f560
[ 58.375937] o4: f8001f09ef60 o5: 0002 sp: f8001f0ff041
ret_pc: 0049662c
[ 58.376069] RPC:
[ 58.376152] l0: f8001f09ef60 l1: 0189bc00 l2: 00b1d000
l3: 0028
[ 58.376272] l4: f8001f09f538 l5: 0008 l6:
l7: 0014
[ 58.376388] i0: 018d1428 i1: 01318d18 i2: 05f8
i3:
[ 58.376506] i4: i5: 0001 i6: f8001f0ff0f1
i7: 007022d8
[ 58.376643] I7:
[ 58.376715] Call Trace:
[ 58.376798] [007022d8] lockdep_rht_mutex_is_held+0x18/0x40
[ 58.376917] [00b7a6ac] test_rht_lookup.constprop.10+0x32c/0x4ac
[ 58.377029] [00b7afd0] test_rhashtable.constprop.8+0x7a4/0x1100
[ 58.377138] [00b7ba00] test_rht_init+0xd4/0x148
[ 58.377240] [00426e2c] do_one_initcall+0xec/0x1e0
[ 58.377351] [00b58b60] kernel_init_freeable+0x114/0x1c4
[ 58.377469] [0091c1ec] kernel_init+0xc/0x100
[ 58.377577] [00405fe4] ret_from_fork+0x1c/0x2c
[ 58.377663] [] (null)
--
Meelis Roos (mr...@linux.ee)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] rhashtable: fix for resize events during table walk
On Mon, Jul 06, 2015 at 03:51:20PM +0200, Phil Sutter wrote:
> If rhashtable_walk_next detects a resize operation in progress, it jumps
> to the new table and continues walking that one. But it misses to drop
> the reference to it's current item, leading it to continue traversing
> the new table's bucket in which the current item is sorted into, and
> after reaching that bucket's end continues traversing the new table's
> second bucket instead of the first one, thereby potentially missing
> items.
>
> This fixes the rhashtable runtime test for me. Bug probably introduced
> by Herbert Xu's patch eddee5ba ("rhashtable: Fix walker behaviour during
> rehash") although not explicitly tested.
>
> Fixes: eddee5ba ("rhashtable: Fix walker behaviour during rehash")
> Signed-off-by: Phil Sutter
Acked-by: Herbert Xu
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] rhashtable: fix for resize events during table walk
From: Phil Sutter
Date: Mon, 6 Jul 2015 15:51:20 +0200
> If rhashtable_walk_next detects a resize operation in progress, it jumps
> to the new table and continues walking that one. But it misses to drop
> the reference to it's current item, leading it to continue traversing
> the new table's bucket in which the current item is sorted into, and
> after reaching that bucket's end continues traversing the new table's
> second bucket instead of the first one, thereby potentially missing
> items.
>
> This fixes the rhashtable runtime test for me. Bug probably introduced
> by Herbert Xu's patch eddee5ba ("rhashtable: Fix walker behaviour during
> rehash") although not explicitly tested.
>
> Fixes: eddee5ba ("rhashtable: Fix walker behaviour during rehash")
> Signed-off-by: Phil Sutter
Applied and queued up for -stable, thanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
