summaryrefslogtreecommitdiff
path: root/include/linux/rcutiny.h
diff options
context:
space:
mode:
authorPaul E. McKenney <paulmck@linux.vnet.ibm.com>2014-11-17 21:12:27 +0300
committerPaul E. McKenney <paulmck@linux.vnet.ibm.com>2015-01-11 06:07:46 +0300
commit79619cf5151257f82a4c016b02283e2ceb4b63ce (patch)
tree15fc277aa25ea7efdad0269e27f75ddbfb06a361 /include/linux/rcutiny.h
parent734d16801349fbe951d2f780191d32c5b8a892d1 (diff)
downloadlinux-79619cf5151257f82a4c016b02283e2ceb4b63ce.tar.xz
rcutorture: Issue warnings on close calls due to Reader Batch blows
Normal rcutorture checking overestimates grace periods somewhat due to the fact that there is a delay from a grace-period request until the start of the corresponding grace period and another delay from the end of that grace period to notification of the requestor. This means that rcutorture's detection of RCU bugs is less sensitive than it might be. It turns out that rcutorture also checks the underlying grace-period "completed" counter (displayed in Reader Batch output), which in theory allows rcutorture to do exact checks. In practice, memory misordering (by both compiler and CPU) can result in false positives. However, experience on x86 shows that these false positives are quite rare, occurring less than one time per 1,000 hours of testing. This commit therefore does the exact checking, giving a warning if any Reader Batch blows happen, and flagging an error if they happen more often than once every three hours in long tests. Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Diffstat (limited to 'include/linux/rcutiny.h')
0 files changed, 0 insertions, 0 deletions