Re: [PATCH v2 1/3] wait: Introduce non-irq variants of wait_event_lock_timeout

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The kerneldoc comment for wait_event_lock_timeout incorrectly states that the process can be awakened by a signal.
--

--- Patch [1]: [PATCH v2 1/3] wait: Introduce non-irq variants of wait_event_lock_timeout ---
commit a625303b88e13551964ad465fcf368350aa20d46
Author: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>

wait: Introduce non-irq variants of wait_event_lock_timeout

This commit introduces non-irq variants of wait_event_lock_timeout and 
wait_event_interruptible_lock_timeout. These macros are optimized for 
spinlocks that are never acquired in an interrupt context, avoiding the 
overhead of globally disabling IRQs.

> diff --git a/include/linux/wait.h b/include/linux/wait.h
> index dce055e6add39..cd9b989c120e5 100644
> --- a/include/linux/wait.h
> +++ b/include/linux/wait.h
[ ... ]
> +/**
> + * wait_event_lock_timeout - sleep until a condition gets true or a timeout
> + *		elapses. The condition is checked under the lock with IRQs
> + *		enabled. This is expected to be called with the lock taken.
> + * @wq_head: the waitqueue to wait on
> + * @condition: a C expression for the event to wait for
> + * @lock: a spinlock_t that has been locked with spin_lock(), which will be
> + *	  released before schedule() and reacquired afterwards.
> + * @timeout: timeout, in jiffies
> + *
> + * The process is put to sleep (TASK_UNINTERRUPTIBLE) until the
> + * @condition evaluates to true or signal is received. The @condition is
> + * checked each time the waitqueue @wq_head is woken up.

[Severity: Low]
This isn't a bug, but is the mention of a signal being received accurate 
here?

Since wait_event_lock_timeout places the task in TASK_UNINTERRUPTIBLE state, 
it should not be awakened by signals. It looks like this sentence might have 
been copied from the interruptible variant above it.

> + *
> + * wake_up() has to be called after changing any variable that could
> + * change the result of the wait condition.
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260730-panthor-cache-flush-fix-v2-0-28790478bfff@collabora.com?part=1