rhashtable: Prevent spurious EBUSY errors on insertion
authorHerbert Xu <herbert@gondor.apana.org.au>
Thu, 3 Dec 2015 12:41:29 +0000 (20:41 +0800)
committerDavid S. Miller <davem@davemloft.net>
Fri, 4 Dec 2015 19:38:26 +0000 (14:38 -0500)
commit3cf92222a39cc7842c373dd90a0c204fa7d7cced
treeda9e396b430096bc864ee7522667f228bb672630
parent071f5d105a0ae93aeb02197c4ee3557e8cc57a21
rhashtable: Prevent spurious EBUSY errors on insertion

Thomas and Phil observed that under stress rhashtable insertion
sometimes failed with EBUSY, even though this error should only
ever been seen when we're under attack and our hash chain length
has grown to an unacceptable level, even after a rehash.

It turns out that the logic for detecting whether there is an
existing rehash is faulty.  In particular, when two threads both
try to grow the same table at the same time, one of them may see
the newly grown table and thus erroneously conclude that it had
been rehashed.  This is what leads to the EBUSY error.

This patch fixes this by remembering the current last table we
used during insertion so that rhashtable_insert_rehash can detect
when another thread has also done a resize/rehash.  When this is
detected we will give up our resize/rehash and simply retry the
insertion with the new table.

Reported-by: Thomas Graf <tgraf@suug.ch>
Reported-by: Phil Sutter <phil@nwl.cc>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Tested-by: Phil Sutter <phil@nwl.cc>
Signed-off-by: David S. Miller <davem@davemloft.net>
include/linux/rhashtable.h
lib/rhashtable.c