[PATCH] io_uring: Redefined the meaning of io_alloc_async_data's return value

[PATCH] io_uring: Redefined the meaning of io_alloc_async_data's return value

[Lu Hongfei]

Usually, successful memory allocation returns true and failure returns false,
which is more in line with the intuitive perception of most people. So it
is necessary to redefine the meaning of io_alloc_async_data's return value.

This could enhance the readability of the code and reduce the possibility
of confusion.

Signed-off-by: Lu Hongfei <luhongfei@vivo.com>
---
 io_uring/io_uring.c  | 13 +++++++++----
 io_uring/net.c       |  4 ++--
 io_uring/rw.c        |  2 +-
 io_uring/timeout.c   |  2 +-
 io_uring/uring_cmd.c |  2 +-
 5 files changed, 14 insertions(+), 9 deletions(-)

diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c
index e8096d502a7c..19f14b7b417d 100644
--- a/io_uring/io_uring.c
+++ b/io_uring/io_uring.c
@@ -1753,14 +1753,19 @@ unsigned int io_file_get_flags(struct file *file)
 	return res;
 }
 
+/*
+ * Alloc async data to the req.
+ *
+ * Returns 'true' if the allocation is successful, 'false' otherwise.
+ */
 bool io_alloc_async_data(struct io_kiocb *req)
 {
 	WARN_ON_ONCE(!io_cold_defs[req->opcode].async_size);
 	req->async_data = kmalloc(io_cold_defs[req->opcode].async_size, GFP_KERNEL);
-	if (req->async_data) {
-		req->flags |= REQ_F_ASYNC_DATA;
+	if (!req->async_data)
 		return false;
-	}
+
+	req->flags |= REQ_F_ASYNC_DATA;
 	return true;
 }
 
@@ -1777,7 +1782,7 @@ int io_req_prep_async(struct io_kiocb *req)
 	if (WARN_ON_ONCE(req_has_async_data(req)))
 		return -EFAULT;
 	if (!def->manual_alloc) {
-		if (io_alloc_async_data(req))
+		if (!io_alloc_async_data(req))
 			return -EAGAIN;
 	}
 	return cdef->prep_async(req);
diff --git a/io_uring/net.c b/io_uring/net.c
index eb1f51ddcb23..49e659d3a874 100644
--- a/io_uring/net.c
+++ b/io_uring/net.c
@@ -152,7 +152,7 @@ static struct io_async_msghdr *io_msg_alloc_async(struct io_kiocb *req,
 		}
 	}
 
-	if (!io_alloc_async_data(req)) {
+	if (io_alloc_async_data(req)) {
 		hdr = req->async_data;
 		hdr->free_iov = NULL;
 		return hdr;
@@ -1494,7 +1494,7 @@ int io_connect(struct io_kiocb *req, unsigned int issue_flags)
 		}
 		if (req_has_async_data(req))
 			return -EAGAIN;
-		if (io_alloc_async_data(req)) {
+		if (!io_alloc_async_data(req)) {
 			ret = -ENOMEM;
 			goto out;
 		}
diff --git a/io_uring/rw.c b/io_uring/rw.c
index 1bce2208b65c..90d4be57a811 100644
--- a/io_uring/rw.c
+++ b/io_uring/rw.c
@@ -523,7 +523,7 @@ static int io_setup_async_rw(struct io_kiocb *req, const struct iovec *iovec,
 	if (!req_has_async_data(req)) {
 		struct io_async_rw *iorw;
 
-		if (io_alloc_async_data(req)) {
+		if (!io_alloc_async_data(req)) {
 			kfree(iovec);
 			return -ENOMEM;
 		}
diff --git a/io_uring/timeout.c b/io_uring/timeout.c
index fb0547b35dcd..35a756d22781 100644
--- a/io_uring/timeout.c
+++ b/io_uring/timeout.c
@@ -534,7 +534,7 @@ static int __io_timeout_prep(struct io_kiocb *req,
 
 	if (WARN_ON_ONCE(req_has_async_data(req)))
 		return -EFAULT;
-	if (io_alloc_async_data(req))
+	if (!io_alloc_async_data(req))
 		return -ENOMEM;
 
 	data = req->async_data;
diff --git a/io_uring/uring_cmd.c b/io_uring/uring_cmd.c
index 476c7877ce58..716a28495bf3 100644
--- a/io_uring/uring_cmd.c
+++ b/io_uring/uring_cmd.c
@@ -139,7 +139,7 @@ int io_uring_cmd(struct io_kiocb *req, unsigned int issue_flags)
 	ret = file->f_op->uring_cmd(ioucmd, issue_flags);
 	if (ret == -EAGAIN) {
 		if (!req_has_async_data(req)) {
-			if (io_alloc_async_data(req))
+			if (!io_alloc_async_data(req))
 				return -ENOMEM;
 			io_uring_cmd_prep_async(req);
 		}
-- 
2.39.0

Re: [PATCH] io_uring: Redefined the meaning of io_alloc_async_data's return value

[Gabriel Krisman Bertazi]

Lu Hongfei <luhongfei@vivo.com> writes:

> Usually, successful memory allocation returns true and failure returns false,
> which is more in line with the intuitive perception of most people. So it
> is necessary to redefine the meaning of io_alloc_async_data's return value.
>
> This could enhance the readability of the code and reduce the possibility
> of confusion.

just want to say, this is the kind of patch that causes bugs in
downstream kernels.  It is not fixing anything, and when we backport a
future bugfix around it, it is easy to miss it and slightly break the
semantics.

That's my downstream problem, of course. But at least it would be good
practice to change the symbol, making the change hard to miss.  Or
make the function return int instead of bool, which preserves the
interface and is a common C idiom.  Or leave it as it is, which is quite
readable already..

thx,

> Signed-off-by: Lu Hongfei <luhongfei@vivo.com>
> ---
>  io_uring/io_uring.c  | 13 +++++++++----
>  io_uring/net.c       |  4 ++--
>  io_uring/rw.c        |  2 +-
>  io_uring/timeout.c   |  2 +-
>  io_uring/uring_cmd.c |  2 +-
>  5 files changed, 14 insertions(+), 9 deletions(-)
>
> diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c
> index e8096d502a7c..19f14b7b417d 100644
> --- a/io_uring/io_uring.c
> +++ b/io_uring/io_uring.c
> @@ -1753,14 +1753,19 @@ unsigned int io_file_get_flags(struct file *file)
>  	return res;
>  }
>  
> +/*
> + * Alloc async data to the req.
> + *
> + * Returns 'true' if the allocation is successful, 'false' otherwise.
> + */
>  bool io_alloc_async_data(struct io_kiocb *req)
>  {
>  	WARN_ON_ONCE(!io_cold_defs[req->opcode].async_size);
>  	req->async_data = kmalloc(io_cold_defs[req->opcode].async_size, GFP_KERNEL);
> -	if (req->async_data) {
> -		req->flags |= REQ_F_ASYNC_DATA;
> +	if (!req->async_data)
>  		return false;
> -	}
> +
> +	req->flags |= REQ_F_ASYNC_DATA;
>  	return true;
>  }
>  
> @@ -1777,7 +1782,7 @@ int io_req_prep_async(struct io_kiocb *req)
>  	if (WARN_ON_ONCE(req_has_async_data(req)))
>  		return -EFAULT;
>  	if (!def->manual_alloc) {
> -		if (io_alloc_async_data(req))
> +		if (!io_alloc_async_data(req))
>  			return -EAGAIN;
>  	}
>  	return cdef->prep_async(req);
> diff --git a/io_uring/net.c b/io_uring/net.c
> index eb1f51ddcb23..49e659d3a874 100644
> --- a/io_uring/net.c
> +++ b/io_uring/net.c
> @@ -152,7 +152,7 @@ static struct io_async_msghdr *io_msg_alloc_async(struct io_kiocb *req,
>  		}
>  	}
>  
> -	if (!io_alloc_async_data(req)) {
> +	if (io_alloc_async_data(req)) {
>  		hdr = req->async_data;
>  		hdr->free_iov = NULL;
>  		return hdr;
> @@ -1494,7 +1494,7 @@ int io_connect(struct io_kiocb *req, unsigned int issue_flags)
>  		}
>  		if (req_has_async_data(req))
>  			return -EAGAIN;
> -		if (io_alloc_async_data(req)) {
> +		if (!io_alloc_async_data(req)) {
>  			ret = -ENOMEM;
>  			goto out;
>  		}
> diff --git a/io_uring/rw.c b/io_uring/rw.c
> index 1bce2208b65c..90d4be57a811 100644
> --- a/io_uring/rw.c
> +++ b/io_uring/rw.c
> @@ -523,7 +523,7 @@ static int io_setup_async_rw(struct io_kiocb *req, const struct iovec *iovec,
>  	if (!req_has_async_data(req)) {
>  		struct io_async_rw *iorw;
>  
> -		if (io_alloc_async_data(req)) {
> +		if (!io_alloc_async_data(req)) {
>  			kfree(iovec);
>  			return -ENOMEM;
>  		}
> diff --git a/io_uring/timeout.c b/io_uring/timeout.c
> index fb0547b35dcd..35a756d22781 100644
> --- a/io_uring/timeout.c
> +++ b/io_uring/timeout.c
> @@ -534,7 +534,7 @@ static int __io_timeout_prep(struct io_kiocb *req,
>  
>  	if (WARN_ON_ONCE(req_has_async_data(req)))
>  		return -EFAULT;
> -	if (io_alloc_async_data(req))
> +	if (!io_alloc_async_data(req))
>  		return -ENOMEM;
>  
>  	data = req->async_data;
> diff --git a/io_uring/uring_cmd.c b/io_uring/uring_cmd.c
> index 476c7877ce58..716a28495bf3 100644
> --- a/io_uring/uring_cmd.c
> +++ b/io_uring/uring_cmd.c
> @@ -139,7 +139,7 @@ int io_uring_cmd(struct io_kiocb *req, unsigned int issue_flags)
>  	ret = file->f_op->uring_cmd(ioucmd, issue_flags);
>  	if (ret == -EAGAIN) {
>  		if (!req_has_async_data(req)) {
> -			if (io_alloc_async_data(req))
> +			if (!io_alloc_async_data(req))
>  				return -ENOMEM;
>  			io_uring_cmd_prep_async(req);
>  		}

-- 
Gabriel Krisman Bertazi

Re: [PATCH] io_uring: Redefined the meaning of io_alloc_async_data's return value

[Jens Axboe]

On 7/10/23 10:58?AM, Gabriel Krisman Bertazi wrote:
> Lu Hongfei <luhongfei@vivo.com> writes:
> 
>> Usually, successful memory allocation returns true and failure returns false,
>> which is more in line with the intuitive perception of most people. So it
>> is necessary to redefine the meaning of io_alloc_async_data's return value.
>>
>> This could enhance the readability of the code and reduce the possibility
>> of confusion.
> 
> just want to say, this is the kind of patch that causes bugs in
> downstream kernels.  It is not fixing anything, and when we backport a
> future bugfix around it, it is easy to miss it and slightly break the
> semantics.

Exactly! This is also why I'm not a fan of patches like this, and was
not intending to apply it.

> That's my downstream problem, of course. But at least it would be good

Strictly speaking it is, but I think we have a responsibility to not
have core bits be different upstream "just because". IOW, making it
harder to introduce problems when backporting.

And fwiw, I'm not sure I agree on the idiomatic part of it. Lots of
functions return 0 for success and non-zero for an error. It's a bit odd
as this one is a bool, but I'm pretty sure it used to return an actual
error and this is why it looks the way it currently does.

-- 
Jens Axboe

Re: [PATCH] io_uring: Redefined the meaning of io_alloc_async_data's return value

[Christoph Hellwig]

On Mon, Jul 10, 2023 at 12:58:58PM -0400, Gabriel Krisman Bertazi wrote:
> practice to change the symbol, making the change hard to miss.  Or
> make the function return int instead of bool, which preserves the
> interface and is a common C idiom.  Or leave it as it is, which is quite
> readable already..

Yeah, returning -ENOMEM and 0 would make a lot more sense here.  But I'd
only change it if we have any good reason to touch the interface anyway.