On Tue 29-04-25 15:34:19, Joe Damato wrote:
> In commit 0a65bc27bd64 ("eventpoll: Set epoll timeout if it's in the
> future"), a bug was introduced causing the loop in ep_poll to hang under
> certain circumstances.
>
> When the timeout is non-NULL and ep_schedule_timeout returns false, the
> flag timed_out was not set to true. This causes a hang.
>
> Adjust the logic and set timed_out, if needed, fixing the original code.
>
> Reported-by: Christian Brauner <brauner@xxxxxxxxxx>
> Closes: https://lore.kernel.org/linux-fsdevel/20250426-haben-redeverbot-0b58878ac722@brauner/
> Reported-by: Mike Pagano <mpagano@xxxxxxxxxx>
> Closes: https://bugs.gentoo.org/954806
> Reported-by: Carlos Llamas <cmllamas@xxxxxxxxxx>
> Closes: https://lore.kernel.org/linux-fsdevel/aBAB_4gQ6O_haAjp@xxxxxxxxxx/
> Fixes: 0a65bc27bd64 ("eventpoll: Set epoll timeout if it's in the future")
> Tested-by: Carlos Llamas <cmllamas@xxxxxxxxxx>
> Signed-off-by: Joe Damato <jdamato@xxxxxxxxxx>
Looks good. Feel free to add:
Reviewed-by: Jan Kara <jack@xxxxxxx>
Honza
> ---
> fs/eventpoll.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/fs/eventpoll.c b/fs/eventpoll.c
> index 4bc264b854c4..1a5d1147f082 100644
> --- a/fs/eventpoll.c
> +++ b/fs/eventpoll.c
> @@ -2111,7 +2111,9 @@ static int ep_poll(struct eventpoll *ep, struct epoll_event __user *events,
>
> write_unlock_irq(&ep->lock);
>
> - if (!eavail && ep_schedule_timeout(to))
> + if (!ep_schedule_timeout(to))
> + timed_out = 1;
> + else if (!eavail)
> timed_out = !schedule_hrtimeout_range(to, slack,
> HRTIMER_MODE_ABS);
> __set_current_state(TASK_RUNNING);
>
> base-commit: f520bed25d17bb31c2d2d72b0a785b593a4e3179
> --
> 2.43.0
>
--
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR
