[PATCH v2] sched: replace if (cond) BUG() with WARN_ON()

Subsystems: cell broadband engine architecture, linux for powerpc (32-bit and 64-bit), spu file system, the rest

STALE1986d

2 messages, 2 authors, 2021-03-17 · open the first message on its own page

[PATCH v2] sched: replace if (cond) BUG() with WARN_ON()

From: Jiapeng Chong <hidden>
Date: 2021-03-17 07:34:34

Fix the following coccicheck warnings:

./arch/powerpc/platforms/cell/spufs/sched.c:908:2-5: WARNING: Use BUG_ON
instead of if condition followed by BUG.

Reported-by: Abaci Robot <redacted>
Signed-off-by: Jiapeng Chong <redacted>
---
Changes in v2:
  - replace BUG with WARN_ON.

 arch/powerpc/platforms/cell/spufs/sched.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/cell/spufs/sched.c b/arch/powerpc/platforms/cell/spufs/sched.c
index 3692064..1031448 100644
--- a/arch/powerpc/platforms/cell/spufs/sched.c
+++ b/arch/powerpc/platforms/cell/spufs/sched.c
@@ -904,8 +904,7 @@ static noinline void spusched_tick(struct spu_context *ctx)
 	struct spu_context *new = NULL;
 	struct spu *spu = NULL;
 
-	if (spu_acquire(ctx))
-		BUG();	/* a kernel thread never has signals pending */
+	WARN_ON(spu_acquire(ctx));	/* a kernel thread never has signals pending */
 
 	if (ctx->state != SPU_STATE_RUNNABLE)
 		goto out;
-- 
1.8.3.1

Re: [PATCH v2] sched: replace if (cond) BUG() with WARN_ON()

From: Arnd Bergmann <arnd@arndb.de>
Date: 2021-03-17 07:56:01

On Wed, Mar 17, 2021 at 8:35 AM Jiapeng Chong
[off-list ref] wrote:
Fix the following coccicheck warnings:

./arch/powerpc/platforms/cell/spufs/sched.c:908:2-5: WARNING: Use BUG_ON
instead of if condition followed by BUG.

Reported-by: Abaci Robot <redacted>
Signed-off-by: Jiapeng Chong <redacted>
If you change it from BUG() to WARN_ON(), you should explain why it's safe to
do that in this case. Here it is not, since the following spu_release() will
end up making things worse if the acquire failed. Also if there was a signal
pending, then spusched_tick() will just get called again and constantly
print these warnings.

There is probably a way to use WARN_ON_ONCE() here, in combination
with a way to terminate the thread safely, but this has to be done carefully.

       Arnd
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help