[Skiboot] [PATCH v2] core/lock: Add debug options to store backtrace of where lock was taken
stewart at linux.ibm.com
Tue May 21 13:07:02 AEST 2019
Andrew Donnellan <andrew.donnellan at au1.ibm.com> writes:
> Contrary to popular belief, skiboot developers are imperfect and
> occasionally write locking bugs. When we exit skiboot, we check if we're
> still holding any locks, and if so, we print an error with a list of the
> locks currently held and the locations where they were taken.
> However, this only tells us the location where lock() was called, which may
> not be enough to work out what's going on. To give us more to go on with,
> we can store backtrace data in the lock and print that out when we
> unexpectedly still hold locks.
> Because the backtrace data is rather big, we only enable this if
> DEBUG_LOCKS_BACKTRACE is defined, which in turn is switched on when
> (We disable DEBUG_LOCKS_BACKTRACE in some of the memory allocation tests
> because the locks used by the memory allocator take up too much room in the
> fake skiboot heap.)
> Signed-off-by: Andrew Donnellan <andrew.donnellan at au1.ibm.com>
> - Switch this on when DEBUG=1 (Stewart)
> - Rebase on top of some backtrace API changes
> - Disable lock backtraces in the mem_region and mem_range_is_reserved
> tests. This is because region allocation requires space in the fake skiboot
> heap, including a lock, and the backtrace records make locks a lot bigger.
> Maybe coupling DEBUG=1 to DEBUG_LOCKS_BACKTRACE isn't that great an idea?
> core/lock.c | 19 +++++++++++++++++--
> core/test/run-mem_range_is_reserved.c | 3 +++
> core/test/run-mem_region.c | 3 +++
> include/config.h | 7 +++++++
> include/lock.h | 11 +++++++++++
> 5 files changed, 41 insertions(+), 2 deletions(-)
Past me would have loved this a few times. Merged to master as of 1706e0311c47b2bfda3db1ef6168628072e7878b
OPAL Architect, IBM.
More information about the Skiboot