Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: - [Medium] The timeout consideration logic fails for wait_event_hrtimeout(), hashed-waitqueues, and DMA fences, causing them to be falsely treated as infinite waits. - [Medium] The ___wait_event() and ___wait_var_event() macros skip the DEPT sleep end annotation on the signal interruption error path, leaking the DEPT tracking stage context. --
commit 25089e0217c82211740316928fec38c6d2b7e4fa Author: Byungchul Park <[email protected]> dept: apply timeout consideration to waitqueue wait This commit applies timeout consideration to waitqueue waits by using the ret parameter in ___wait_event() as a timeout value for DEPT tracking. It leverages CONFIG_DEPT_AGGRESSIVE_TIMEOUT_WAIT to help reduce false positive deadlock reports for waits that are meant to expire. > diff --git a/include/linux/wait.h b/include/linux/wait.h > index c8f8b44060fb9..a9524bc8630b7 100644 > --- a/include/linux/wait.h > +++ b/include/linux/wait.h > @@ -306,7 +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); > \ > + sdt_might_sleep_start_timeout(NULL, __ret); > \ [Severity: Medium] Does this logic also need to be applied to __wait_event_hrtimeout(), hashed-waitqueues, and DMA fences? For example, __wait_event_hrtimeout() passes 0 as the 'ret' parameter to ___wait_event(), causing sdt_might_sleep_start_timeout() to treat it as an infinite wait. Additionally, hashed-waitqueues (in ___wait_var_event) and DMA fences (in dma_fence_default_wait and dma_fence_wait_any_timeout) still hardcode sdt_might_sleep_start(NULL) even when taking a timeout. This seems to cause DEPT to falsely report deadlocks for these bounded waits. > init_wait_entry(&__wq_entry, exclusive ? WQ_FLAG_EXCLUSIVE : 0); > \ > for (;;) { > \ > long __int = prepare_to_wait_event(&wq_head, &__wq_entry, > state);\ [Severity: Medium] Can the DEPT sleep end annotation be skipped on the signal interruption error path? Looking further down in the ___wait_event() macro, if the wait is interruptible and interrupted by a signal, it takes the goto __out branch: if (___wait_is_interruptible(state) && __int) { __ret = __int; goto __out; } ... } finish_wait(&wq_head, &__wq_entry); sdt_might_sleep_end(); __out: __ret; This skips over sdt_might_sleep_end(), which leaks the DEPT wait stage context. As a result, DEPT will mistakenly treat subsequent wait events for this task as nested waits. The same issue appears to exist in ___wait_var_event() for hashed-waitqueues. -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=18
