Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Unconditional zeroing of `wgen` in `dept_event` creates a race condition that systematically loses dependencies for shared locks, blinding the deadlock detector. -- commit f7ae795e924d8a4b1154e57adaf0e878e810272c Author: Byungchul Park <[email protected]> dept: make dept able to work with an external wgen This commit introduces an external wait generation structure, struct dept_ext_wgen, to allow subsystems with memory constraints to use DEPT without embedding a full struct dept_map. It modifies dept_request_event() and dept_event() to optionally accept and operate on this external wgen instead of the one embedded in struct dept_map. > diff --git a/kernel/dependency/dept.c b/kernel/dependency/dept.c > index 5ef85977e6314..e425d3ab05e5a 100644 > --- a/kernel/dependency/dept.c > +++ b/kernel/dependency/dept.c [ ... ] > @@ -2816,24 +2826,26 @@ void dept_event(struct dept_map *m, unsigned long e_f, > if (m->nocheck) > return; > > + wg_p = ewg ? &ewg->wgen : &m->wgen; > + > if (dt->recursive) { > /* > * Dept won't work with this even though an event > * context has been asked. Don't make it confused at > * handling the event. Disable it until the next. > */ > - WRITE_ONCE(m->wgen, 0U); > + WRITE_ONCE(*wg_p, 0U); > return; > } > > flags = dept_enter(); > > - __dept_event(m, m, e_f, ip, e_fn, false); > + __dept_event(m, m, e_f, ip, e_fn, false, READ_ONCE(*wg_p)); > > /* > * Keep the map diabled until the next sleep. > */ > - WRITE_ONCE(m->wgen, 0U); > + WRITE_ONCE(*wg_p, 0U); [Severity: High] This is a pre-existing issue, but does unconditionally clearing the wgen here in dept_event() create a race condition that loses dependencies for shared locks? When multiple threads hold a shared lock (e.g., a read-lock like rw_semaphore), and a writer begins waiting, the writer calls dept_request_event() which sets the lock's wgen. The first reader to unlock calls dept_event(), which reads the wgen, processes the wait dependency for its own context, and then unconditionally clears wgen to 0 here. All subsequent readers unlocking will read 0 and fail to record the dependency between the writer's wait and their own read-side critical sections, which could blind the deadlock detector. Since this issue affects the newly introduced ewg->wgen as well, could this be addressed to ensure dependencies aren't lost when multiple threads share the lock? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=21
