Re: [PATCH v19 18/40] dept: apply timeout consideration to waitqueue wait

[sashiko-bot]

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 <byungchul@xxxxxx>

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/20260706061928.66713-1-byungchul@xxxxxx?part=18