linux.git/kernel/locking/locktorture.c, branch v4.2-rc5

locktorture: Change longdelay_us to longdelay_ms

2015-05-27T19:59:57+00:00

The locktorture long delays are in milliseconds rather than microseconds,
so this commit changes the name of the corresponding variable from
longdelay_us to longdelay_ms.

Reported-by: Ben Goodwyn 
Signed-off-by: Paul E. McKenney 
Cc: Davidlohr Bueso 
Reviewed-by: Josh Triplett

locktorture: fix deadlock in 'rw_lock_irq' type

2015-05-27T19:59:56+00:00

torture_rwlock_read_unlock_irq() must use read_unlock_irqrestore()
instead of write_unlock_irqrestore().

Use read_unlock_irqrestore() instead of write_unlock_irqrestore().

Signed-off-by: Alexey Kodanev 
Signed-off-by: Paul E. McKenney 
Reviewed-by: Josh Triplett

locktorture: Cleanup header usage

2014-09-30T07:10:02+00:00

Remove some unnecessary ones and explicitly include rwsem.h

Signed-off-by: Davidlohr Bueso 
Signed-off-by: Paul E. McKenney

locktorture: Cannot hold read and write lock

2014-09-30T07:10:02+00:00

... trigger an error if so.

Signed-off-by: Davidlohr Bueso 
Signed-off-by: Paul E. McKenney

locktorture: Fix __acquire annotation for spinlock irq

2014-09-30T07:10:02+00:00

Its quite easy to get mixed up with the names -- 'torture_spinlock_irq'
is not actually a valid spinlock name.

Signed-off-by: Davidlohr Bueso 
Signed-off-by: Paul E. McKenney

locktorture: Support rwlocks

2014-09-30T07:10:00+00:00

Add a "rw_lock" torture test to stress kernel rwlocks and their irq
variant. Reader critical regions are 5x longer than writers. As such
a similar ratio of lock acquisitions is seen in the statistics. In the
case of massive contention, both hold the lock for 1/10 of a second.

Signed-off-by: Davidlohr Bueso 
Signed-off-by: Paul E. McKenney

locktorture: Introduce torture context

2014-09-16T20:41:40+00:00

The amount of global variables is getting pretty ugly. Group variables
related to the execution (ie: not parameters) in a new context structure.

Signed-off-by: Davidlohr Bueso 
Signed-off-by: Paul E. McKenney

locktorture: Support rwsems

2014-09-16T20:41:36+00:00

We can easily do so with our new reader lock support. Just an arbitrary
design default: readers have higher (5x) critical region latencies than
writers: 50 ms and 10 ms, respectively.

Signed-off-by: Davidlohr Bueso 
Signed-off-by: Paul E. McKenney

locktorture: Add infrastructure for torturing read locks

2014-09-16T20:41:07+00:00

Most of it is based on what we already have for writers. This allows
readers to be very independent (and thus configurable), enabling
future module parameters to control things such as rw distribution.
Furthermore, readers have their own delaying function, allowing us
to test different rw critical region latencies, and stress locking
internals. Similarly, statistics, for now will only serve for the
number of lock acquisitions -- as opposed to writers, readers have
no failure detection.

In addition, introduce a new nreaders_stress module parameter. The
default number of readers will be the same number of writers threads.
Writer threads are interleaved with readers. Documentation is updated,
respectively.

Signed-off-by: Davidlohr Bueso 
Signed-off-by: Paul E. McKenney

torture: Address race in module cleanup

2014-09-16T20:41:06+00:00

When performing module cleanups by calling torture_cleanup() the
'torture_type' string in nullified However, callers are not necessarily
done, and might still need to reference the variable. This impacts
both rcutorture and locktorture, causing printing things like:

[   94.226618] (null)-torture: Stopping lock_torture_writer task
[   94.226624] (null)-torture: Stopping lock_torture_stats task

Thus delay this operation until the very end of the cleanup process.
The consequence (which shouldn't matter for this kid of program) is,
of course, that we delay the window between rmmod and modprobing,
for instance in module_torture_begin().

Signed-off-by: Davidlohr Bueso 
Signed-off-by: Paul E. McKenney