Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] When a wait event is interrupted by a signal, it bypasses sdt_might_sleep_end(), permanently leaking the DEPT wait stage. --
commit 264d829a8f72641205caea8b130ee3c25557563a Author: Byungchul Park <[email protected]> dept: apply timeout consideration to swait Now that CONFIG_DEPT_AGGRESSIVE_TIMEOUT_WAIT was introduced, apply the consideration to swait, assuming an input 'ret' in ___swait_event() macro is used as a timeout value. > diff --git a/include/linux/swait.h b/include/linux/swait.h > index 277ac74f61c39..233acdf55e9bc 100644 > --- a/include/linux/swait.h > +++ b/include/linux/swait.h > @@ -162,7 +162,7 @@ extern void finish_swait(struct swait_queue_head *q, > struct swait_queue *wait); > struct swait_queue __wait; \ > long __ret = ret; \ > \ > - sdt_might_sleep_start(NULL); \ > + sdt_might_sleep_start_timeout(NULL, __ret); \ [Severity: High] Is this a regression where a signal-interrupted wait event permanently leaks the dept wait stage tracking state? Looking at ___swait_event(), if the task receives a signal while waiting, it evaluates ___wait_is_interruptible(state) && __int as true and takes the goto __out path: if (___wait_is_interruptible(state) && __int) { __ret = __int; goto __out; } This jumps completely over the cleanup call: finish_swait(&wq, &__wait); sdt_might_sleep_end(); __out: __ret; Without calling sdt_might_sleep_end() and its underlying dept_clean_stage(), the dept state isn't cleaned up for the current task. Subsequent waits by this task will fail to register new dependency maps and instead repeatedly commit the stale wait map during __schedule(). This irreversibly corrupts the lock dependency graph and triggers false deadlock reports. The exact same bypass flaw appears to be present in ___wait_event() in include/linux/wait.h and ___wait_var_event() in include/linux/wait_bit.h. > INIT_LIST_HEAD(&__wait.task_list); \ > for (;;) { \ > long __int = prepare_to_swait_event(&wq, &__wait, state);\ -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=17
