I got the lockdep splat below from an SRCU-T rcutorture run, which uses
a !SMP !PREEMPT kernel. This is a random event, and about half the time
it happens within an hour or two. My reproducer (on current -rcu "dev"
branch for a 16-CPU system) is:
tools/testing/selftests/rcutorture/bin/kvm.sh --cpus 16 --configs "16*SRCU-T" --duration 7200
My points of confusion are as follows:
1. The locks involved in this deadlock cycle are irq-disabled
raw spinlocks. The claimed deadlock cycle uses two CPUs.
There is only one CPU. There is no possibility of preemption
or interrupts. So how can this deadlock actually happen?
2. If there was more than one CPU, then yes, there would be
a deadlock. The PI lock is acquired by the wakeup code after
acquiring the workqueue lock, and rcutorture tests the new ability
of the scheduler to hold the PI lock across rcu_read_unlock(),
and while it is at it, across the rest of the unlock primitives.
But if there was more than one CPU, Tree SRCU would be used
instead of Tiny SRCU, and there would be no wakeup invoked from
Given only one CPU, there is no way to complete the deadlock
For now, I am working around this by preventing rcutorture from holding
the PI lock across Tiny srcu_read_unlock().
Am I missing something subtle here?