Re: [PATCH 2/2] sched: Use WARN_ON.*_DEFERRED()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Low] The fallback definition of `WARN_ON_DEFERRED` in `include/asm-generic/bug.h` contains a syntax error due to missing semicolons. By broadly introducing this macro in the scheduler, this commit breaks the build on architectures that lack `__WARN_FLAGS`.

Pre-existing issues:
- [High] The patch fails to replace `WARN()`, `WARN_ONCE()`, and several `WARN_ON_ONCE()` macros within the scheduler, leaving critical paths vulnerable to the exact AB-BA deadlock the patch claims to fix.
--

commit a6aa09c317e0b91e99c786c88d0107e256973560
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Subject: sched: Use WARN_ON.*_DEFERRED()

This patch replaces WARN and WARN_ON_ONCE macros within the scheduler with
their DEFERRED variants. This aims to prevent AB-BA deadlocks with legacy
consoles that might wake ksoftirqd while the runqueue lock is held.

Link: https://lore.kernel.org/all/20260610183621.3915271-1-vlad.wing@gmail.com

> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index b8871449d3c69..0e282457abb91 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -853,7 +853,7 @@ void update_rq_clock(struct rq *rq)
>  		return;
>  
>  	if (sched_feat(WARN_DOUBLE_CLOCK))
> -		WARN_ON_ONCE(rq->clock_update_flags & RQCF_UPDATED);
> +		WARN_ON_ONCE_DEFERRED(rq->clock_update_flags & RQCF_UPDATED);

[Severity: Low]
Does this broad replacement break the build on architectures without
__WARN_FLAGS (like standard ARM32, MIPS, or SPARC)?

The fallback definition of WARN_ON_DEFERRED in include/asm-generic/bug.h
contains a syntax error due to missing semicolons:

	printk_deferred_enter()					\
	__WARN();						\
	printk_deferred_exit()					\

Using this macro here could cause syntax errors on those architectures.

[ ... ]

> diff --git a/kernel/sched/ext.c b/kernel/sched/ext.c
> index 5d2d19473a82e..47d3a4c16455a 100644
> --- a/kernel/sched/ext.c
> +++ b/kernel/sched/ext.c
> @@ -1855,7 +1855,7 @@ static void direct_dispatch(struct scx_sched *sch, struct task_struct *p,
>  			break;
>  		}
>  
> -		WARN_ON_ONCE(p->scx.dsq || !list_empty(&p->scx.dsq_list.node));
> +		WARN_ON_ONCE_DEFERRED(p->scx.dsq || !list_empty(&p->scx.dsq_list.node));
>  		list_add_tail(&p->scx.dsq_list.node,

[Severity: High]
This is a pre-existing issue, but since the goal is to prevent deadlocks
by replacing warnings while runqueue locks are held, did we miss the
WARN_ONCE right above this in the same function?

kernel/sched/ext.c:direct_dispatch() {
    ...
    default:
        WARN_ONCE(true, "sched_ext: %s[%d] has invalid ops state...",
                  p->comm, p->pid, opss);
        atomic_long_set_release(&p->scx.ops_state, SCX_OPSS_NONE);
        break;
    }

    WARN_ON_ONCE_DEFERRED(p->scx.dsq || !list_empty(&p->scx.dsq_list.node));
    ...
}

There are several other missed WARN and WARN_ONCE calls in the scheduler
that are also called with locks held. Could these trigger the same AB-BA
deadlock if they fire?

For example:
- finish_task_switch() in kernel/sched/core.c (with rq lock held)
- proxy_force_return() in kernel/sched/core.c (with pi_lock and rq_lock held)
- sched_cpu_dying() in kernel/sched/core.c (with rq lock held)
- sched_core_cpu_starting() in kernel/sched/core.c (with core_lock held)
- scx_set_task_state() in kernel/sched/ext.c (with rq lock held)
- assert_task_ready_or_enabled() in kernel/sched/ext.c (with rq lock held)

Would it be better to audit and replace these remaining macros as well?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260623142650.265721-1-bigeasy@linutronix.de?part=2