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 <[email protected]> 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/[email protected]?part=23
