The new multiple-reader rtmutex code keeps an array of MAX_RWLOCK_DEPTH read-lock owners in task_struct. As described in the original patch: > The max depth is currently set to 5. A task may own the same lock > multiple times for read without affecting this limit. It is bad > programming practice to hold more than 5 different locks for read at > the same time anyway so this should not be a problem. The 5 lock limit > should be way more than enough." However, CONFIG_DEBUG_LOCKING_API_SELFTESTS includes tests which intentionally use locks incorrectly, and in particular it locks without unlocking. This quickly reaches the 5 lock limit. AA_rlock locks twice without unlocking, AA_rsem locks twice more without unlocking, and ABBA_rlock locks twice more before it unlocks; this nests read locks six deep, triggering the WARN_ON. Given that CONFIG_DEBUG_LOCKING_API_SELFTESTS exists to use locks incorrectly, I don't think this necessarily needs fixing. However, perhaps locking_selftest should print a big warning in advance if run without lockdep turned on, saying to expect locking-related warnings/bugs/panics? - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
