On Thu, 2023-01-12 at 22:59 -0800, Boqun Feng wrote: > This is actually a leftover of the recursive read deadlock detection > patchset: > > https://lore.kernel.org/lkml/20180411135647.21496-1-boqun.feng@xxxxxxxxx/ > > I resolve comments then and add more test cases, and hopefully this can > fulfill the request from KVM: > > https://lore.kernel.org/lkml/a14a13a690277d4cc95a4b26aa2d9a4d9b392a74.camel@xxxxxxxxxxxxx/ > > ;-) It definitely seems to work; thank you! I can revert some of the recent fixes from the KVM tree, apply your patches, and then I can trigger the lockdep warnings. To make it reliably trigger, we need to artificially call synchronize_srcu(&kvm->srcu) under kvm->lock on KVM init, because the circumstances under which that happens are a bit esoteric and don't always happen otherwise, so lockdep wouldn't notice. > The patch #3 is now WIP for two reasons: > > * It may conflicts with Paul's patchset on removing CONFIG_SRCU > > * I haven't found a proper way to "reinit" srcu_struct when > lockdep selftest runs: cleanup_srcu_struct() needs workqueue > however the tests can run before there is one. Understood. I think the KVM series which follows can stand alone and go via the KVM tree separately. As and when your series gets merged, it'll serve to protect against regressions. Thanks again! David Woodhouse (3): KVM: Show lockdep the kvm->mutex vs. kvm->srcu ordering rule KVM: selftests: Use enum for test numbers in xen_shinfo_test KVM: selftests: Add EVTCHNOP_send slow path test to xen_shinfo_test .../testing/selftests/kvm/x86_64/xen_shinfo_test.c | 165 ++++++++++++++------- virt/kvm/kvm_main.c | 10 ++ 2 files changed, 124 insertions(+), 51 deletions(-)
