> 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
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?
>
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 buc
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
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 t
