linux-stable.git/kernel/locking/locktorture.c, branch v3.18.76

locktorture: Fix potential memory leak with rw lock test

2017-09-13T21:03:47+00:00

commit f4dbba591945dc301c302672adefba9e2ec08dc5 upstream.

When running locktorture module with the below commands with kmemleak enabled:

$ modprobe locktorture torture_type=rw_lock_irq
$ rmmod locktorture

The below kmemleak got caught:

root@10:~# echo scan > /sys/kernel/debug/kmemleak
[  323.197029] kmemleak: 2 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
root@10:~# cat /sys/kernel/debug/kmemleak
unreferenced object 0xffffffc07592d500 (size 128):
  comm "modprobe", pid 368, jiffies 4294924118 (age 205.824s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 c3 7b 02 00 00 00 00 00  .........{......
    00 00 00 00 00 00 00 00 d7 9b 02 00 00 00 00 00  ................
  backtrace:
    [] create_object+0x110/0x288
    [] kmemleak_alloc+0x58/0xa0
    [] __kmalloc+0x234/0x318
    [] 0xffffff80006fa130
    [] do_one_initcall+0x44/0x138
    [] do_init_module+0x68/0x1cc
    [] load_module+0x1a68/0x22e0
    [] SyS_finit_module+0xe0/0xf0
    [] el0_svc_naked+0x24/0x28
    [] 0xffffffffffffffff
unreferenced object 0xffffffc07592d480 (size 128):
  comm "modprobe", pid 368, jiffies 4294924118 (age 205.824s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 3b 6f 01 00 00 00 00 00  ........;o......
    00 00 00 00 00 00 00 00 23 6a 01 00 00 00 00 00  ........#j......
  backtrace:
    [] create_object+0x110/0x288
    [] kmemleak_alloc+0x58/0xa0
    [] __kmalloc+0x234/0x318
    [] 0xffffff80006fa22c
    [] do_one_initcall+0x44/0x138
    [] do_init_module+0x68/0x1cc
    [] load_module+0x1a68/0x22e0
    [] SyS_finit_module+0xe0/0xf0
    [] el0_svc_naked+0x24/0x28
    [] 0xffffffffffffffff

It is because cxt.lwsa and cxt.lrsa don't get freed in module_exit, so free
them in lock_torture_cleanup() and free writer_tasks if reader_tasks is
failed at memory allocation.

Signed-off-by: Yang Shi 
Signed-off-by: Paul E. McKenney 
Reviewed-by: Josh Triplett 
Cc: 石洋 
Signed-off-by: Greg Kroah-Hartman

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

locktorture: Make statistics generic

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

The statistics structure can serve well for both reader and writer
locks, thus simply rename some fields that mention 'write' and leave
the declaration of lwsa.

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