linux-toradex.git/lib/test_rhashtable.c, branch v4.14-rc5

lib: test_rhashtable: Fix KASAN warning

2017-07-25T19:35:23+00:00

I forgot one spot when introducing struct test_obj_val.

Fixes: e859afe1ee0c5 ("lib: test_rhashtable: fix for large entry counts")
Reported by: kernel test robot 
Signed-off-by: Phil Sutter 
Signed-off-by: David S. Miller

lib: test_rhashtable: fix for large entry counts

2017-07-24T21:13:58+00:00

During concurrent access testing, threadfunc() concatenated thread ID
and object index to create a unique key like so:

| tdata->objs[i].value = (tdata->id << 16) | i;

This breaks if a user passes an entries parameter of 64k or higher,
since 'i' might use more than 16 bits then. Effectively, this will lead
to duplicate keys in the table.

Fix the problem by introducing a struct holding object and thread ID and
using that as key instead of a single integer type field.

Fixes: f4a3e90ba5739 ("rhashtable-test: extend to test concurrency")
Reported by: Manuel Messner 
Signed-off-by: Phil Sutter 
Acked-by: Herbert Xu 
Signed-off-by: David S. Miller

rhashtable-test: Fix max_size parameter description

2016-08-08T19:52:42+00:00

Looks like a simple copy'n'paste error.

Fixes: 1aa661f5c3df1 ("rhashtable-test: Measure time to insert, remove & traverse entries")
Signed-off-by: Phil Sutter 
Signed-off-by: David S. Miller

rhashtable: accept GFP flags in rhashtable_walk_init

2016-04-05T08:56:32+00:00

In certain cases, the 802.11 mesh pathtable code wants to
iterate over all of the entries in the forwarding table from
the receive path, which is inside an RCU read-side critical
section.  Enable walks inside atomic sections by allowing
GFP_ATOMIC allocations for the walker state.

Change all existing callsites to pass in GFP_KERNEL.

Acked-by: Thomas Graf 
Signed-off-by: Bob Copeland 
[also adjust gfs2/glock.c and rhashtable tests]
Signed-off-by: Johannes Berg

rhashtable-test: allow to retry even if -ENOMEM was returned

2015-11-23T17:36:08+00:00

This is rather a hack to expose the current issue with rhashtable to
under high pressure sometimes return -ENOMEM even though system memory
is not exhausted and a consecutive insert may succeed.

Signed-off-by: Phil Sutter 
Signed-off-by: David S. Miller

rhashtable-test: calculate max_entries value by default

2015-11-23T17:36:08+00:00

A maximum table size of 64k entries is insufficient for the multiple
threads test even in default configuration (10 threads * 50000 objects =
500000 objects in total). Since we know how many objects will be
inserted, calculate the max size unless overridden by parameter.

Note that specifying the exact number of objects upon table init won't
suffice as that value is being rounded down to the next power of two -
anticipate this by rounding up to the next power of two in beforehand.

Signed-off-by: Phil Sutter 
Signed-off-by: David S. Miller

rhashtable-test: retry insert operations

2015-11-23T17:36:08+00:00

After adding cond_resched() calls to threadfunc(), a surprisingly high
rate of insert failures occurred probably due to table resizes getting a
better chance to run in background. To not soften up the remaining
tests, retry inserts until they either succeed or fail permanently.

Also change the non-threaded test to retry insert operations, too.

Suggested-by: Thomas Graf 
Signed-off-by: Phil Sutter 
Signed-off-by: David S. Miller

rhashtable-test: add cond_resched() to thread test

2015-11-23T17:36:08+00:00

This should fix for soft lockup bugs triggered on slow systems.

Signed-off-by: Phil Sutter 
Signed-off-by: David S. Miller

rhashtable-test: extend to test concurrency

2015-08-17T21:33:47+00:00

After having tested insertion, lookup, table walk and removal, spawn a
number of threads running operations on the same rhashtable. Each of
them will:

1) insert it's own set of objects,
2) lookup every successfully inserted object and finally
3) remove objects in several rounds until all of them have been removed,
   making sure the remaining ones are still found after each round.

This should put a good amount of load onto the system and due to
synchronising thread startup via two semaphores also extensive
concurrent table access.

The default number of ten threads returned within half a second on my
local VM with two cores. Running 200 threads took about four seconds. If
slow systems suffer too much from this though, the default could be
lowered or even set to zero so this extended test does not run at all by
default.

Signed-off-by: Phil Sutter 
Acked-by: Thomas Graf 
Signed-off-by: David S. Miller

rhashtable: Allow other tasks to be scheduled in large lookup loops

2015-07-21T07:10:08+00:00

Depending on system speed, the large lookup/insert/delete loops of the testsuite can
take a considerable amount of time to complete causing watchdog warnings to appear.
Allow other tasks to be scheduled throughout the loops.

Reported-by: Meelis Roos 
Signed-off-by: Thomas Graf 
Acked-by: Eric Dumazet 
Signed-off-by: David S. Miller