]> www.infradead.org Git - users/dwmw2/linux.git/commit
signal handling: don't use BUG_ON() for debugging
authorLinus Torvalds <torvalds@linux-foundation.org>
Wed, 6 Jul 2022 19:20:59 +0000 (12:20 -0700)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 21 Jul 2022 19:20:18 +0000 (21:20 +0200)
commit58b94325ee80c709f57b15f762bf3b25d8a534f1
treef2ece1cba829b006c55715f689ab2be263094e33
parente75f692b79b477826296841d1535dae6e3eaa8bb
signal handling: don't use BUG_ON() for debugging

[ Upstream commit a382f8fee42ca10c9bfce0d2352d4153f931f5dc ]

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 <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
kernel/signal.c