diff options
| author | Jens Axboe <axboe@kernel.dk> | 2024-06-03 13:56:53 -0600 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2024-06-16 13:51:04 +0200 |
| commit | 46b9d23c879f7f73eec9a94fff347f1f26a7d751 (patch) | |
| tree | 2460bb68126f524680c67cdbd3bf9d1c675ac672 /tools/lib/api/fs/tracing_path.c | |
| parent | a968d5c895d527cd364cd3de86b9363901b2a434 (diff) | |
io_uring/napi: fix timeout calculation
commit 415ce0ea55c5a3afea501a773e002be9ed7149f5 upstream.
Not quite sure what __io_napi_adjust_timeout() was attemping to do, it's
adjusting both the NAPI timeout and the general overall timeout, and
calculating a value that is never used. The overall timeout is a super
set of the NAPI timeout, and doesn't need adjusting. The only thing we
really need to care about is that the NAPI timeout doesn't exceed the
overall timeout. If a user asked for a timeout of eg 5 usec and NAPI
timeout is 10 usec, then we should not spin for 10 usec.
While in there, sanitize the time checking a bit. If we have a negative
value in the passed in timeout, discard it. Round up the value as well,
so we don't end up with a NAPI timeout for the majority of the wait,
with only a tiny sleep value at the end.
Hence the only case we need to care about is if the NAPI timeout is
larger than the overall timeout. If it is, cap the NAPI timeout at what
the overall timeout is.
Cc: stable@vger.kernel.org
Fixes: 8d0c12a80cde ("io-uring: add napi busy poll support")
Reported-by: Lewis Baker <lewissbaker@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'tools/lib/api/fs/tracing_path.c')
0 files changed, 0 insertions, 0 deletions