Skip to content

Commit

Permalink
core/lock: don't set bust_locks on lock error
Browse files Browse the repository at this point in the history
[ Upstream commit 5272867 ]

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>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
  • Loading branch information
npiggin authored and oohal committed May 9, 2019
1 parent 3d135fe commit 68acaf1
Showing 1 changed file with 0 additions and 2 deletions.
2 changes: 0 additions & 2 deletions core/lock.c
Original file line number Diff line number Diff line change
Expand Up @@ -33,8 +33,6 @@ static struct lock dl_lock = LOCK_UNLOCKED;

static void 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);
Expand Down

0 comments on commit 68acaf1

Please sign in to comment.