Re: [PATCH v19 23/40] dept: print staged wait's stacktrace on report

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Data race on `dt->stage_m` leading to zeroed class keys and kernel warnings.
--

commit 02dbd1fb0ecda3493e1e312bcf532860fa1353de
Author: Byungchul Park <byungchul@sk.com>

dept: print staged wait's stacktrace on report

This commit modifies the dependency tracking (dept) system to capture and
print the stacktrace of the wait that an event wakes up. This provides more
context for interpreting dept's reports.

> diff --git a/kernel/dependency/dept.c b/kernel/dependency/dept.c
> index e425d3ab05e5a..5bf32633e1fbd 100644
> --- a/kernel/dependency/dept.c
> +++ b/kernel/dependency/dept.c

[ ... ]

> @@ -2561,6 +2580,14 @@ void dept_request_event_wait_commit(void)
>  
>  	wg = next_wgen();
>  	WRITE_ONCE(dt->stage_m.wgen, wg);
> +
> +	/*
> +	 * __schedule() can be hit multiple times between
> +	 * dept_stage_wait() and dept_clean_stage().  In that case,
> +	 * keep the first stacktrace only.  That's enough.
> +	 */
> +	if (!dt->stage_wait_stack)
> +		dt->stage_wait_stack = get_current_stack();
>  	arch_spin_unlock(&dt->stage_lock);
>  
>  	__dept_wait(&dt->stage_m, 1UL, ip, w_fn, 0, true, sched_map, timeout);

[Severity: High]
This isn't a bug introduced by this patch, but does accessing dt->stage_m
here, immediately after dropping the stage_lock, introduce a data race with
a concurrent wakeup?

If a task begins scheduling out, it calls dept_request_event_wait_commit()
from __schedule(). It acquires dt->stage_lock, updates fields, and unlocks
it. Before it can call __dept_wait(&dt->stage_m, ...), an interrupt or
another CPU could concurrently call try_to_wake_up() on the same task.

The waking CPU would acquire dt->stage_lock in dept_ttwu_stage_wait() and
zero out dt->stage_m via __dept_clean_stage():

kernel/dependency/dept.c:__dept_clean_stage() {
    memset(&dt->stage_m, 0x0, sizeof(struct dept_map));
    ...
}

If __dept_wait(&dt->stage_m) executes concurrently on the original CPU, it
reads the zeroed structure. This would cause it to look up a class with key
0 and trigger DEPT_WARN_ON(!valid_class(c)), breaking dependency tracking
and potentially panicking the system if panic_on_warn is enabled.

Could this be prevented by either copying the required parts of dt->stage_m
to local variables while the lock is still held, or expanding the lock
coverage?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260706061928.66713-1-byungchul@sk.com?part=23