Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] The `sdt_might_sleep_end()` cleanup macro is bypassed when wait loops (`___wait_event`, `___swait_event`) are interrupted by a signal, permanently leaking a DEPT dependency stage. --
commit 1300cac9c94eeb3955744b6d40ed8dce8cfc059f Author: Byungchul Park <[email protected]> dept: apply sdt_might_sleep_{start,end}() to waitqueue wait Make dept able to track dependencies by waitqueue waits. > diff --git a/include/linux/wait.h b/include/linux/wait.h > index dce055e6add39..c8f8b44060fb9 100644 > --- a/include/linux/wait.h > +++ b/include/linux/wait.h [ ... ] > @@ -305,6 +306,7 @@ extern void init_wait_entry(struct wait_queue_entry > *wq_entry, int flags); > struct wait_queue_entry __wq_entry; > \ > long __ret = ret; /* explicit shadow */ > \ > > \ > + sdt_might_sleep_start(NULL); > \ > init_wait_entry(&__wq_entry, exclusive ? WQ_FLAG_EXCLUSIVE : 0); > \ > for (;;) { > \ > long __int = prepare_to_wait_event(&wq_head, &__wq_entry, > state);\ > @@ -323,6 +325,7 @@ extern void init_wait_entry(struct wait_queue_entry > *wq_entry, int flags); > break; > \ > } > \ > finish_wait(&wq_head, &__wq_entry); > \ > + sdt_might_sleep_end(); > \ > __out: __ret; > \ > }) [Severity: High] Does this bypass sdt_might_sleep_end() when interrupted by a signal? Looking at ___wait_event(), if ___wait_is_interruptible(state) and __int is set, it will take the goto __out path: if (___wait_is_interruptible(state) && __int) { \ __ret = __int; \ goto __out; \ } \ If that path is taken, sdt_might_sleep_end() is bypassed, which permanently leaks a DEPT dependency stage. A stale wait context remains in the task's dependency tracker state. When the task later sleeps for unrelated reasons, the scheduler might attribute the sleep to the leaked context, leading to false-positive lockup splats. Also, does this same structural issue exist in ___swait_event() in include/linux/swait.h for simple waitqueues? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=12
