While hunting a locking problem in my core scheduling series I have
added some debugging aids to spinlock handling making it easier to
find the root cause for the problem.
Making use of the already existing lock profiling and enhancing it a
little bit produces some really valuable diagnostic data e.g. when a
NMI watchdog is triggering a crash.
Changes in V5:
- add BUILD_BUG_ON() in patch 1
Changes in V4:
- some comments by Jan Beulich addressed
- replaced patch 5 with another approach to make lock names unique
Changes in V3:
- rebase to current staging (after realizing that patch 4 still
applied, but resulting in patching a wrong function)
Changes in V2:
- multiple comments addressed
- added patch 5
Juergen Gross (5):
xen/spinlocks: in debug builds store cpu holding the lock
xen: add new CONFIG_DEBUG_LOCKS option
xen: print lock profile info in panic()
xen: modify lock profiling interface
xen: add function name to lock profiling data
tools/libxc/xc_misc.c | 1 +
tools/misc/xenlockprof.c | 17 +---
xen/Kconfig.debug | 10 ++-
xen/arch/arm/xen.lds.S | 13 +--
xen/arch/x86/domain.c | 2 +-
xen/arch/x86/xen.lds.S | 13 +--
xen/common/domain.c | 4 +-
xen/common/keyhandler.c | 2 +-
xen/common/spinlock.c | 188 ++++++++++++++++++++++++++++++++------------
xen/common/sysctl.c | 2 +-
xen/drivers/char/console.c | 4 +-
xen/include/public/sysctl.h | 11 +--
xen/include/xen/spinlock.h | 76 +++++++++++-------
13 files changed, 225 insertions(+), 118 deletions(-)
--
2.16.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel