public inbox for io-uring@vger.kernel.org
 help / color / mirror / Atom feed
From: redacherkaoui <redacherkaoui67@gmail.com>
To: io-uring@vger.kernel.org
Cc: axboe@kernel.dk, linux-kernel@vger.kernel.org,
	redacherkaoui <redacherkaoui67@gmail.com>
Subject: [PATCH] io_uring: document advise SQE field reuse for 64-bit lengths
Date: Mon, 16 Feb 2026 16:14:24 +0000	[thread overview]
Message-ID: <20260216161426.10810-1-redacherkaoui67@gmail.com> (raw)

IORING_OP_FADVISE and IORING_OP_MADVISE reuse SQE fields to
support 64-bit lengths without extending struct io_uring_sqe.

For IORING_OP_FADVISE, the length is carried in sqe->addr when
non-zero, with sqe->len providing legacy fallback.

For IORING_OP_MADVISE, the length is carried in sqe->off when
non-zero, with sqe->len providing legacy fallback.

This differs from the more common addr/off/len interpretation
used by many other opcodes and can be confusing when constructing
SQEs manually.

Document the field mapping in the UAPI header to clarify the
intended behavior and reduce the risk of misuse.
Signed-off-by: redacherkaoui <redacherkaoui67@gmail.com>
---
 include/uapi/linux/io_uring.h | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/include/uapi/linux/io_uring.h b/include/uapi/linux/io_uring.h
index d84627cf06b4..a19bd1e42561 100644
--- a/include/uapi/linux/io_uring.h
+++ b/include/uapi/linux/io_uring.h
@@ -25,9 +25,11 @@ extern "C" {
 #endif
 
 /*
+ * IO submission data structure (Submission Queue Entry)
+ *
  * Field reuse for 64-bit lengths:
  *
- * Most opcodes interpret:
+ * Many opcodes interpret:
  *   - addr as a userspace pointer (buffer/iov/etc)
  *   - off  as a file offset
  *   - len  as a 32-bit length
@@ -37,12 +39,14 @@ extern "C" {
  *
  * IORING_OP_FADVISE:
  *   - off           : file offset
- *   - fadvise_advice: POSIX_FADV_* advice
+ *   - fadvise_advice: POSIX_FADV_*
+
  *   - length        : addr if non-zero, otherwise len (legacy)
  *
  * IORING_OP_MADVISE:
  *   - addr          : start address of mapping
- *   - fadvise_advice: MADV_* advice
+ *   - fadvise_advice: MADV_*
+
  *   - length        : off if non-zero, otherwise len (legacy)
  *
  * This mapping is part of the stable UAPI.
-- 
2.43.0


             reply	other threads:[~2026-02-16 16:14 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-16 16:14 redacherkaoui [this message]
2026-02-16 16:23 ` [PATCH] io_uring: document advise SQE field reuse for 64-bit lengths Jens Axboe
  -- strict thread matches above, loose matches on Subject: below --
2026-02-16 11:37 redacherkaoui
2026-02-16 15:17 ` Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260216161426.10810-1-redacherkaoui67@gmail.com \
    --to=redacherkaoui67@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=io-uring@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox