6.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: Josef Bacik Commit 21ed976c12f6b77d7ea028a4fe9a08e69a56179f upstream. __io_napi_busy_loop() caps the busy poll time to what is left until the timeout of the wait. The difference is negative if the timeout has passed already, which is what an application gets if it uses IORING_ENTER_ABS_TIMER with a time that isn't in the future any more. The min_t(u64, ...) turns that into a huge value, so the cap has no effect and the wait, which should return right away, spins for the full busy poll time first. Fixes: d5cce407e4f5 ("io_uring/napi: postpone napi timeout adjustment") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-34-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman --- io_uring/napi.c | 2 ++ 1 file changed, 2 insertions(+) --- a/io_uring/napi.c +++ b/io_uring/napi.c @@ -365,6 +365,8 @@ void __io_napi_busy_loop(struct io_ring_ if (iowq->timeout != KTIME_MAX) { ktime_t dt = ktime_sub(iowq->timeout, io_get_time(ctx)); + /* an absolute timeout may have passed already */ + dt = max_t(ktime_t, dt, 0); iowq->napi_busy_poll_dt = min_t(u64, iowq->napi_busy_poll_dt, dt); }