stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Sasha Levin <sashal@kernel.org>,
	ebiederm@xmission.com, keescook@chromium.org, oleg@redhat.com,
	tglx@linutronix.de, peterz@infradead.org
Subject: [PATCH AUTOSEL 5.10 15/15] signal handling: don't use BUG_ON() for debugging
Date: Thu, 14 Jul 2022 00:25:40 -0400	[thread overview]
Message-ID: <20220714042541.282175-15-sashal@kernel.org> (raw)
In-Reply-To: <20220714042541.282175-1-sashal@kernel.org>

From: Linus Torvalds <torvalds@linux-foundation.org>

[ 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 | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/kernel/signal.c b/kernel/signal.c
index 6bb2df4f6109..d05f783d5a5e 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -1912,12 +1912,12 @@ bool do_notify_parent(struct task_struct *tsk, int sig)
 	bool autoreap = false;
 	u64 utime, stime;
 
-	BUG_ON(sig == -1);
+	WARN_ON_ONCE(sig == -1);
 
- 	/* do_notify_parent_cldstop should have been called instead.  */
- 	BUG_ON(task_is_stopped_or_traced(tsk));
+	/* do_notify_parent_cldstop should have been called instead.  */
+	WARN_ON_ONCE(task_is_stopped_or_traced(tsk));
 
-	BUG_ON(!tsk->ptrace &&
+	WARN_ON_ONCE(!tsk->ptrace &&
 	       (tsk->group_leader != tsk || !thread_group_empty(tsk)));
 
 	/* Wake up all pidfd waiters */
-- 
2.35.1


      parent reply	other threads:[~2022-07-14  4:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-14  4:25 [PATCH AUTOSEL 5.10 01/15] ASoC: ops: Fix off by one in range control validation Sasha Levin
2022-07-14  4:25 ` [PATCH AUTOSEL 5.10 02/15] pinctrl: aspeed: Fix potential NULL dereference in aspeed_pinmux_set_mux() Sasha Levin
2022-07-14  4:25 ` [PATCH AUTOSEL 5.10 03/15] ASoC: SOF: Intel: hda-loader: Clarify the cl_dsp_init() flow Sasha Levin
2022-07-14  4:25 ` [PATCH AUTOSEL 5.10 04/15] ASoC: wm5110: Fix DRE control Sasha Levin
2022-07-14  4:25 ` [PATCH AUTOSEL 5.10 05/15] ASoC: dapm: Initialise kcontrol data for mux/demux controls Sasha Levin
2022-07-14  4:25 ` [PATCH AUTOSEL 5.10 06/15] ASoC: cs47l15: Fix event generation for low power mux control Sasha Levin
2022-07-14  4:25 ` [PATCH AUTOSEL 5.10 07/15] ASoC: madera: Fix event generation for OUT1 demux Sasha Levin
2022-07-14  4:25 ` [PATCH AUTOSEL 5.10 08/15] ASoC: madera: Fix event generation for rate controls Sasha Levin
2022-07-14  4:25 ` [PATCH AUTOSEL 5.10 09/15] irqchip: or1k-pic: Undefine mask_ack for level triggered hardware Sasha Levin
2022-07-14  4:25 ` [PATCH AUTOSEL 5.10 10/15] x86: Clear .brk area at early boot Sasha Levin
2022-07-14  4:25 ` [PATCH AUTOSEL 5.10 11/15] soc: ixp4xx/npe: Fix unused match warning Sasha Levin
2022-07-14  4:25 ` [PATCH AUTOSEL 5.10 12/15] ARM: dts: stm32: use the correct clock source for CEC on stm32mp151 Sasha Levin
2022-07-14  4:25 ` [PATCH AUTOSEL 5.10 13/15] Revert "can: xilinx_can: Limit CANFD brp to 2" Sasha Levin
2022-07-14  4:25 ` [PATCH AUTOSEL 5.10 14/15] nvme-pci: phison e16 has bogus namespace ids Sasha Levin
2022-07-14  4:25 ` Sasha Levin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220714042541.282175-15-sashal@kernel.org \
    --to=sashal@kernel.org \
    --cc=ebiederm@xmission.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).