diff options
| author | Nicholas Piggin <npiggin@gmail.com> | 2018-09-30 13:48:21 +1000 |
|---|---|---|
| committer | Stewart Smith <stewart@linux.ibm.com> | 2018-10-10 18:09:25 -0500 |
| commit | 527286706ab1861774742402c4e69e1b3b6f6cde (patch) | |
| tree | 489cf00039bac49553613a4b4637458c13ec3c35 /core/lock.c | |
| parent | 2aa227cc0e18e8ccd6e3e0747587eaf296a72e92 (diff) | |
| download | skiboot-527286706ab1861774742402c4e69e1b3b6f6cde.zip skiboot-527286706ab1861774742402c4e69e1b3b6f6cde.tar.gz skiboot-527286706ab1861774742402c4e69e1b3b6f6cde.tar.bz2 | |
core/lock: don't set bust_locks on lock error
bust_locks is a big hammer that guarantees a mess if it's set while
all other threads are not stopped.
I propose removing this in the lock error paths. In debugging the
previous deadlock false positive, none of the error messages printed,
and the in-memory console was totally garbled due to lack of locking.
I think it's generally better for debugging and system integrity to
keep locks held when lock errors occur. Lock busting should be used
carefully, just to allow messages to be printed out or machine to be
restarted, probably when the whole system is single-threaded.
Skiboot is slowly working toward that being feasible with co-operative
debug APIs between firmware and host, but for the time being,
difficult lock crashes are better not to corrupt everything by
busting locks.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
Diffstat (limited to 'core/lock.c')
| -rw-r--r-- | core/lock.c | 2 |
1 files changed, 0 insertions, 2 deletions
diff --git a/core/lock.c b/core/lock.c index fc051ca..e7c60a3 100644 --- a/core/lock.c +++ b/core/lock.c @@ -34,8 +34,6 @@ bool bust_locks = true; static void __nomcount lock_error(struct lock *l, const char *reason, uint16_t err) { - bust_locks = true; - fprintf(stderr, "LOCK ERROR: %s @%p (state: 0x%016llx)\n", reason, l, l->lock_val); op_display(OP_FATAL, OP_MOD_LOCK, err); |