On Tue 29-04-25 20:58:27, Max Kellermann wrote:
> After commit 0a65bc27bd64 ("eventpoll: Set epoll timeout if it's in
> the future"), the following program would immediately enter a busy
> loop in the kernel:
>
> ```
> int main() {
> int e = epoll_create1(0);
> struct epoll_event event = {.events = EPOLLIN};
> epoll_ctl(e, EPOLL_CTL_ADD, 0, &event);
> const struct timespec timeout = {.tv_nsec = 1};
> epoll_pwait2(e, &event, 1, &timeout, 0);
> }
> ```
>
> This happens because the given (non-zero) timeout of 1 nanosecond
> usually expires before ep_poll() is entered and then
> ep_schedule_timeout() returns false, but `timed_out` is never set
> because the code line that sets it is skipped. This quickly turns
> into a soft lockup, RCU stalls and deadlocks, inflicting severe
> headaches to the whole system.
>
> When the timeout has expired, we don't need to schedule a hrtimer, but
> we should set the `timed_out` variable. Therefore, I suggest moving
> the ep_schedule_timeout() check into the `timed_out` expression
> instead of skipping it.
>
> Fixes: 0a65bc27bd64 ("eventpoll: Set epoll timeout if it's in the future")
> Cc: Joe Damato <jdamato@xxxxxxxxxx>
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: Max Kellermann <max.kellermann@xxxxxxxxx>
I agree this makes the logic somewhat more obvious than Joe's fix so feel
free to add:
Reviewed-by: Jan Kara <jack@xxxxxxx>
Thanks!
Honza
> ---
> fs/eventpoll.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/fs/eventpoll.c b/fs/eventpoll.c
> index 4bc264b854c4..d4dbffdedd08 100644
> --- a/fs/eventpoll.c
> +++ b/fs/eventpoll.c
> @@ -2111,9 +2111,10 @@ static int ep_poll(struct eventpoll *ep, struct epoll_event __user *events,
>
> write_unlock_irq(&ep->lock);
>
> - if (!eavail && ep_schedule_timeout(to))
> - timed_out = !schedule_hrtimeout_range(to, slack,
> - HRTIMER_MODE_ABS);
> + if (!eavail)
> + timed_out = !ep_schedule_timeout(to) ||
> + !schedule_hrtimeout_range(to, slack,
> + HRTIMER_MODE_ABS);
> __set_current_state(TASK_RUNNING);
>
> /*
> --
> 2.47.2
>
--
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR
