[PATCH] io_uring: document advise SQE field reuse for 64-bit lengths

[PATCH] io_uring: document advise SQE field reuse for 64-bit lengths

[redacherkaoui]

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

Re: [PATCH] io_uring: document advise SQE field reuse for 64-bit lengths

[Jens Axboe]

On 2/16/26 9:14 AM, redacherkaoui wrote:
> 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.

Like I asked you before, what on earth is this patch against?
Stop re-sending the same stuff without answering the question.

-- 
Jens Axboe

[PATCH] io_uring: document advise SQE field reuse for 64-bit lengths

[redacherkaoui]

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 883c9ceb5..7955ebb98 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

Re: [PATCH] io_uring: document advise SQE field reuse for 64-bit lengths

[Jens Axboe]

On 2/16/26 4:37 AM, redacherkaoui wrote:
> 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.

What is this patch against? Not the upstream kernel...


-- 
Jens Axboe