Re: [PATCH v19 11/40] dept: apply sdt_might_sleep_{start,end}() to swait

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The `___swait_event`, `___wait_event`, and `___wait_var_event` macros skip the `sdt_might_sleep_end()` cleanup call when returning early due to a pending signal, leading to persistent DEPT state corruption that permanently disables dependency tracking for the affected task.
--

commit 7785a2fe54ced42e856f39ece5776f11bca47be8
Author: Byungchul Park <[email protected]>

dept: apply sdt_might_sleep_{start,end}() to swait

Make dept able to track dependencies by swaits.

> diff --git a/include/linux/swait.h b/include/linux/swait.h
> index d324419482a0f..277ac74f61c39 100644
> --- a/include/linux/swait.h
> +++ b/include/linux/swait.h
[ ... ]
> @@ -161,6 +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);					\
>  	INIT_LIST_HEAD(&__wait.task_list);				\
>  	for (;;) {							\
>  		long __int = prepare_to_swait_event(&wq, &__wait, state);\
> @@ -176,6 +178,7 @@ extern void finish_swait(struct swait_queue_head *q, struct swait_queue *wait);
>  		cmd;							\
>  	}								\
>  	finish_swait(&wq, &__wait);					\
> +	sdt_might_sleep_end();						\
>  __out:	__ret;								\
>  })

[Severity: High]
Does this code bypass the sdt_might_sleep_end() cleanup when returning early
due to a pending signal?

Looking at ___swait_event(), if a task waiting interruptibly receives a
signal, prepare_to_swait_event() returns a non-zero error code. 

The wait loop evaluates ___wait_is_interruptible(state) && __int as true and
executes a goto __out; which jumps completely over this new cleanup call.

If sdt_might_sleep_end() is skipped, does the task's dependency staging map
remain persistently populated, effectively causing subsequent calls to
dept_stage_wait() to silently exit early and disable DEPT tracking for that
task?

It looks like this identical sequence might also occur in the generic
waitqueue macros (___wait_event in include/linux/wait.h) and the hashed
waitqueue macros (___wait_var_event in include/linux/wait_bit.h).

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=11