Skip to content

Commit a382f8f

Browse files
committed
signal handling: don't use BUG_ON() for debugging
These are indeed "should not happen" situations, but it turns out recent changes made the 'task_is_stopped_or_trace()' case trigger (fix for that exists, is pending more testing), and the BUG_ON() makes it unnecessarily hard to actually debug for no good reason. It's been that way for a long time, but let's make it clear: BUG_ON() is not good for debugging, and should never be used in situations where you could just say "this shouldn't happen, but we can continue". Use WARN_ON_ONCE() instead to make sure it gets logged, and then just continue running. Instead of making the system basically unusuable because you crashed the machine while potentially holding some very core locks (eg this function is commonly called while holding 'tasklist_lock' for writing). Signed-off-by: Linus Torvalds <[email protected]>
1 parent 9f09069 commit a382f8f

File tree

1 file changed

+4
-4
lines changed

1 file changed

+4
-4
lines changed

kernel/signal.c

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -2029,12 +2029,12 @@ bool do_notify_parent(struct task_struct *tsk, int sig)
20292029
bool autoreap = false;
20302030
u64 utime, stime;
20312031

2032-
BUG_ON(sig == -1);
2032+
WARN_ON_ONCE(sig == -1);
20332033

2034-
/* do_notify_parent_cldstop should have been called instead. */
2035-
BUG_ON(task_is_stopped_or_traced(tsk));
2034+
/* do_notify_parent_cldstop should have been called instead. */
2035+
WARN_ON_ONCE(task_is_stopped_or_traced(tsk));
20362036

2037-
BUG_ON(!tsk->ptrace &&
2037+
WARN_ON_ONCE(!tsk->ptrace &&
20382038
(tsk->group_leader != tsk || !thread_group_empty(tsk)));
20392039

20402040
/* Wake up all pidfd waiters */

0 commit comments

Comments
 (0)