[PATCH liburing v2 1/1] tests: test timeout with immediate arguments

[PATCH liburing v2 1/1] tests: test timeout with immediate arguments

[Pavel Begunkov]

IORING_TIMEOUT_IMMEDIATE_ARG allows the user to store the timeout in the
SQE without indirection to a user timespec. Update io_uring.h and extend
tests to cover the feature.

Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
---
 src/include/liburing/io_uring.h |  5 ++++
 test/timeout.c                  | 46 ++++++++++++++++++++++++++++-----
 2 files changed, 45 insertions(+), 6 deletions(-)

diff --git a/src/include/liburing/io_uring.h b/src/include/liburing/io_uring.h
index ab1450ec..74b3f86d 100644
--- a/src/include/liburing/io_uring.h
+++ b/src/include/liburing/io_uring.h
@@ -332,6 +332,10 @@ enum io_uring_op {
 
 /*
  * sqe->timeout_flags
+ *
+ * IORING_TIMEOUT_IMMEDIATE_ARG:	If set, sqe->addr stores the timeout
+ *					value in nanoseconds instead of
+ *					pointing to a timespec.
  */
 #define IORING_TIMEOUT_ABS		(1U << 0)
 #define IORING_TIMEOUT_UPDATE		(1U << 1)
@@ -340,6 +344,7 @@ enum io_uring_op {
 #define IORING_LINK_TIMEOUT_UPDATE	(1U << 4)
 #define IORING_TIMEOUT_ETIME_SUCCESS	(1U << 5)
 #define IORING_TIMEOUT_MULTISHOT	(1U << 6)
+#define IORING_TIMEOUT_IMMEDIATE_ARG	(1U << 7)
 #define IORING_TIMEOUT_CLOCK_MASK	(IORING_TIMEOUT_BOOTTIME | IORING_TIMEOUT_REALTIME)
 #define IORING_TIMEOUT_UPDATE_MASK	(IORING_TIMEOUT_UPDATE | IORING_LINK_TIMEOUT_UPDATE)
 /*
diff --git a/test/timeout.c b/test/timeout.c
index 003ba743..6bef0a7e 100644
--- a/test/timeout.c
+++ b/test/timeout.c
@@ -23,6 +23,7 @@
 static int not_supported;
 static int no_modify;
 static int no_multishot;
+static int no_immediate;
 
 static void msec_to_ts(struct __kernel_timespec *ts, unsigned int msec)
 {
@@ -30,11 +31,25 @@ static void msec_to_ts(struct __kernel_timespec *ts, unsigned int msec)
 	ts->tv_nsec = (msec % 1000) * 1000000;
 }
 
+static void t_prep_timeout_rel(struct io_uring_sqe *sqe,
+				const struct __kernel_timespec *ts,
+				bool immediate)
+{
+	if (!immediate) {
+		io_uring_prep_timeout(sqe, ts, 0, 0);
+		return;
+	}
+
+	io_uring_prep_timeout(sqe, NULL, 0, 0);
+	sqe->addr = ts->tv_sec * 1000000000 + ts->tv_nsec;
+	sqe->timeout_flags = IORING_TIMEOUT_IMMEDIATE_ARG;
+}
+
 /*
  * Test that we return to userspace if a timeout triggers, even if we
  * don't satisfy the number of events asked for.
  */
-static int test_single_timeout_many(struct io_uring *ring)
+static int test_single_timeout_many(struct io_uring *ring, bool immediate)
 {
 	struct io_uring_cqe *cqe;
 	struct io_uring_sqe *sqe;
@@ -50,7 +65,7 @@ static int test_single_timeout_many(struct io_uring *ring)
 	}
 
 	msec_to_ts(&ts, TIMEOUT_MSEC);
-	io_uring_prep_timeout(sqe, &ts, 0, 0);
+	t_prep_timeout_rel(sqe, &ts, immediate);
 
 	ret = io_uring_submit(ring);
 	if (ret <= 0) {
@@ -219,7 +234,7 @@ err:
 /*
  * Test single timeout waking us up
  */
-static int test_single_timeout(struct io_uring *ring)
+static int test_single_timeout(struct io_uring *ring, bool immediate)
 {
 	struct io_uring_cqe *cqe;
 	struct io_uring_sqe *sqe;
@@ -235,7 +250,7 @@ static int test_single_timeout(struct io_uring *ring)
 	}
 
 	msec_to_ts(&ts, TIMEOUT_MSEC);
-	io_uring_prep_timeout(sqe, &ts, 0, 0);
+	t_prep_timeout_rel(sqe, &ts, immediate);
 
 	ret = io_uring_submit(ring);
 	if (ret <= 0) {
@@ -252,6 +267,11 @@ static int test_single_timeout(struct io_uring *ring)
 	ret = cqe->res;
 	io_uring_cqe_seen(ring, cqe);
 	if (ret == -EINVAL) {
+		if (immediate) {
+			no_immediate = true;
+			fprintf(stdout, "%s: Timeout (imm) not supported, ignored\n", __FUNCTION__);
+			return 0;
+		}
 		fprintf(stdout, "%s: Timeout not supported, ignored\n", __FUNCTION__);
 		not_supported = 1;
 		return 0;
@@ -1765,7 +1785,7 @@ int main(int argc, char *argv[])
 	ret = io_uring_queue_init(8, &sqpoll_ring, IORING_SETUP_SQPOLL);
 	sqpoll = !ret;
 
-	ret = test_single_timeout(&ring);
+	ret = test_single_timeout(&ring, false);
 	if (ret) {
 		fprintf(stderr, "test_single_timeout failed\n");
 		return ret;
@@ -1773,6 +1793,12 @@ int main(int argc, char *argv[])
 	if (not_supported)
 		return 0;
 
+	ret = test_single_timeout(&ring, true);
+	if (ret) {
+		fprintf(stderr, "test_single_timeout (imm) failed\n");
+		return ret;
+	}
+
 	ret = test_multi_timeout(&ring);
 	if (ret) {
 		fprintf(stderr, "test_multi_timeout failed\n");
@@ -1797,12 +1823,20 @@ int main(int argc, char *argv[])
 		return ret;
 	}
 
-	ret = test_single_timeout_many(&ring);
+	ret = test_single_timeout_many(&ring, false);
 	if (ret) {
 		fprintf(stderr, "test_single_timeout_many failed\n");
 		return ret;
 	}
 
+	if (!no_immediate) {
+		ret = test_single_timeout_many(&ring, true);
+		if (ret) {
+			fprintf(stderr, "test_single_timeout_many (imm) failed\n");
+			return ret;
+		}
+	}
+
 	ret = test_single_timeout_nr(&ring, 1);
 	if (ret) {
 		fprintf(stderr, "test_single_timeout_nr(1) failed\n");
-- 
2.53.0

Re: [PATCH liburing v2 1/1] tests: test timeout with immediate arguments

[Jens Axboe]

On 2/25/26 10:28 AM, Pavel Begunkov wrote:
> IORING_TIMEOUT_IMMEDIATE_ARG allows the user to store the timeout in the
> SQE without indirection to a user timespec. Update io_uring.h and extend
> tests to cover the feature.

Would be nice with a changelog...

Applied, but there's no documentation update included. I'm just going to
auto-generate one so we have it, we should not add new flags without
documenting them in the appropriate man page(s). Same old story...

-- 
Jens Axboe

Re: [PATCH liburing v2 1/1] tests: test timeout with immediate arguments

[Jens Axboe]

On Wed, 25 Feb 2026 17:28:03 +0000, Pavel Begunkov wrote:
> IORING_TIMEOUT_IMMEDIATE_ARG allows the user to store the timeout in the
> SQE without indirection to a user timespec. Update io_uring.h and extend
> tests to cover the feature.
> 
> 

Applied, thanks!

[1/1] tests: test timeout with immediate arguments
      commit: ac9b8d0daedc2d311a4a43c88689fe7731657cec

Best regards,
-- 
Jens Axboe

Re: [PATCH liburing v2 1/1] tests: test timeout with immediate arguments

[Pavel Begunkov]

On 2/25/26 18:07, Jens Axboe wrote:
> On 2/25/26 10:28 AM, Pavel Begunkov wrote:
>> IORING_TIMEOUT_IMMEDIATE_ARG allows the user to store the timeout in the
>> SQE without indirection to a user timespec. Update io_uring.h and extend
>> tests to cover the feature.
> 
> Would be nice with a changelog...

Forgot about this one

> Applied, but there's no documentation update included. I'm just going to
> auto-generate one so we have it, we should not add new flags without
> documenting them in the appropriate man page(s). Same old story...

Looks like you've been generating AI slop for docs, so I assume
you're not against it? I'll try generating it next time.

-- 
Pavel Begunkov

Re: [PATCH liburing v2 1/1] tests: test timeout with immediate arguments

[Jens Axboe]

On 2/26/26 5:52 AM, Pavel Begunkov wrote:
>> Applied, but there's no documentation update included. I'm just going to
>> auto-generate one so we have it, we should not add new flags without
>> documenting them in the appropriate man page(s). Same old story...
> 
> Looks like you've been generating AI slop for docs, so I assume
> you're not against it? I'll try generating it next time.

I think calling it "slop" is a bit unfair - sometimes it does get
nuances slightly wrong, but it's a LOT easier to fix those up than write
it from scratch yourself. And the the language is a lot better than what
you or I can produce. The icing on the cake is that I no longer have to
nag you or others on documentation - though I would prefer if you or
whoever is the submitted generated it and proof read it, I think that's
the better approach than me doing it.

-- 
Jens Axboe

Re: [PATCH liburing v2 1/1] tests: test timeout with immediate arguments

[Pavel Begunkov]

On 2/26/26 15:16, Jens Axboe wrote:
> On 2/26/26 5:52 AM, Pavel Begunkov wrote:
>>> Applied, but there's no documentation update included. I'm just going to
>>> auto-generate one so we have it, we should not add new flags without
>>> documenting them in the appropriate man page(s). Same old story...
>>
>> Looks like you've been generating AI slop for docs, so I assume
>> you're not against it? I'll try generating it next time.
> 
> I think calling it "slop" is a bit unfair - sometimes it does get
> nuances slightly wrong, but it's a LOT easier to fix those up than write
> it from scratch yourself. And the the language is a lot better than what
> you or I can produce. The icing on the cake is that I no longer have to
> nag you or others on documentation - though I would prefer if you or
> whoever is the submitted generated it and proof read it, I think that's
> the better approach than me doing it.

Well, whatever it's called, I might just use it if it saves time
for writing man pages. Does it require any attribution / tags in the
commit? Some Assisted-by?

-- 
Pavel Begunkov

Re: [PATCH liburing v2 1/1] tests: test timeout with immediate arguments

[Jens Axboe]

On 2/26/26 10:03 AM, Pavel Begunkov wrote:
> On 2/26/26 15:16, Jens Axboe wrote:
>> On 2/26/26 5:52 AM, Pavel Begunkov wrote:
>>>> Applied, but there's no documentation update included. I'm just going to
>>>> auto-generate one so we have it, we should not add new flags without
>>>> documenting them in the appropriate man page(s). Same old story...
>>>
>>> Looks like you've been generating AI slop for docs, so I assume
>>> you're not against it? I'll try generating it next time.
>>
>> I think calling it "slop" is a bit unfair - sometimes it does get
>> nuances slightly wrong, but it's a LOT easier to fix those up than write
>> it from scratch yourself. And the the language is a lot better than what
>> you or I can produce. The icing on the cake is that I no longer have to
>> nag you or others on documentation - though I would prefer if you or
>> whoever is the submitted generated it and proof read it, I think that's
>> the better approach than me doing it.
> 
> Well, whatever it's called, I might just use it if it saves time
> for writing man pages. Does it require any attribution / tags in the
> commit? Some Assisted-by?

I'll save you a lot of time...

I don't care if you put the tag in there or not. For the kernel, and for
actual code, I do believe an assisted-by tag is required. But for
documentation or liburing, as far as I'm concerned, you can add
attribution or not, doesn't matter to me.

-- 
Jens Axboe

Re: [PATCH liburing v2 1/1] tests: test timeout with immediate arguments

[Pavel Begunkov]

On 2/26/26 17:06, Jens Axboe wrote:
> On 2/26/26 10:03 AM, Pavel Begunkov wrote:
>> On 2/26/26 15:16, Jens Axboe wrote:
>>> On 2/26/26 5:52 AM, Pavel Begunkov wrote:
>>>>> Applied, but there's no documentation update included. I'm just going to
>>>>> auto-generate one so we have it, we should not add new flags without
>>>>> documenting them in the appropriate man page(s). Same old story...
>>>>
>>>> Looks like you've been generating AI slop for docs, so I assume
>>>> you're not against it? I'll try generating it next time.
>>>
>>> I think calling it "slop" is a bit unfair - sometimes it does get
>>> nuances slightly wrong, but it's a LOT easier to fix those up than write
>>> it from scratch yourself. And the the language is a lot better than what
>>> you or I can produce. The icing on the cake is that I no longer have to
>>> nag you or others on documentation - though I would prefer if you or
>>> whoever is the submitted generated it and proof read it, I think that's
>>> the better approach than me doing it.
>>
>> Well, whatever it's called, I might just use it if it saves time
>> for writing man pages. Does it require any attribution / tags in the
>> commit? Some Assisted-by?
> 
> I'll save you a lot of time...

"_I_ will", looks like AI already replaced Jens...

> I don't care if you put the tag in there or not. For the kernel, and for
> actual code, I do believe an assisted-by tag is required. But for
> documentation or liburing, as far as I'm concerned, you can add
> attribution or not, doesn't matter to me.

Got it, and I wasn't planning to use it for the kernel

-- 
Pavel Begunkov

Re: [PATCH liburing v2 1/1] tests: test timeout with immediate arguments

[Jens Axboe]

On 2/26/26 10:10 AM, Pavel Begunkov wrote:
> On 2/26/26 17:06, Jens Axboe wrote:
>> On 2/26/26 10:03 AM, Pavel Begunkov wrote:
>>> On 2/26/26 15:16, Jens Axboe wrote:
>>>> On 2/26/26 5:52 AM, Pavel Begunkov wrote:
>>>>>> Applied, but there's no documentation update included. I'm just going to
>>>>>> auto-generate one so we have it, we should not add new flags without
>>>>>> documenting them in the appropriate man page(s). Same old story...
>>>>>
>>>>> Looks like you've been generating AI slop for docs, so I assume
>>>>> you're not against it? I'll try generating it next time.
>>>>
>>>> I think calling it "slop" is a bit unfair - sometimes it does get
>>>> nuances slightly wrong, but it's a LOT easier to fix those up than write
>>>> it from scratch yourself. And the the language is a lot better than what
>>>> you or I can produce. The icing on the cake is that I no longer have to
>>>> nag you or others on documentation - though I would prefer if you or
>>>> whoever is the submitted generated it and proof read it, I think that's
>>>> the better approach than me doing it.
>>>
>>> Well, whatever it's called, I might just use it if it saves time
>>> for writing man pages. Does it require any attribution / tags in the
>>> commit? Some Assisted-by?
>>
>> I'll save you a lot of time...
> 
> "_I_ will", looks like AI already replaced Jens...

Oops, missing a t - It'll :)

>> I don't care if you put the tag in there or not. For the kernel, and for
>> actual code, I do believe an assisted-by tag is required. But for
>> documentation or liburing, as far as I'm concerned, you can add
>> attribution or not, doesn't matter to me.
> 
> Got it, and I wasn't planning to use it for the kernel

It's most useful for documentation and tests on the liburing side. It
does a pretty decent job on the latter too, mimicking things like "skip
on old kernels" and that kind of thing. Needs a bit of nudging on little
things, but once dialed in, that part is a big time saver too.

-- 
Jens Axboe