[PATCH V2] loop: aio inherit the ioprio of original request

[PATCH V2] loop: aio inherit the ioprio of original request

[Yunlong Xing]

Set cmd->iocb.ki_ioprio to the ioprio of loop device's request.
The purpose is to inherit the original request ioprio in the aio
flow.

Signed-off-by: Yunlong Xing <yunlong.xing@unisoc.com>
Signed-off-by: Zhiguo Niu <zhiguo.niu@unisoc.com>=
---
V2:
- Assign cmd->iocb.ki_ioprio in lo_rw_aio()
---
 drivers/block/loop.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 674527d770dc..dd7f33d47f4f 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -447,7 +447,7 @@ static int lo_rw_aio(struct loop_device *lo, struct loop_cmd *cmd,
 	cmd->iocb.ki_filp = file;
 	cmd->iocb.ki_complete = lo_rw_aio_complete;
 	cmd->iocb.ki_flags = IOCB_DIRECT;
-	cmd->iocb.ki_ioprio = IOPRIO_PRIO_VALUE(IOPRIO_CLASS_NONE, 0);
+	cmd->iocb.ki_ioprio = req_get_ioprio(rq);
 
 	if (rw == ITER_SOURCE)
 		ret = file->f_op->write_iter(&cmd->iocb, &iter);
-- 
2.25.1

Re: [PATCH V2] loop: aio inherit the ioprio of original request

[Christoph Hellwig]

On Mon, Apr 14, 2025 at 11:01:59AM +0800, Yunlong Xing wrote:
> Set cmd->iocb.ki_ioprio to the ioprio of loop device's request.
> The purpose is to inherit the original request ioprio in the aio
> flow.

This looks good, but has a mechanical conflict with my
"loop: stop using vfs_iter_{read,write} for buffered I/O" patch
that fixes setting the block size for direct I/O.

Jens, any preference how we should order the patches?  Should I resend
on top of this smaller one or the other way around?

Reviewed-by: Christoph Hellwig <hch@lst.de>

Re: [PATCH V2] loop: aio inherit the ioprio of original request

[Jens Axboe]

On 4/14/25 12:12 AM, Christoph Hellwig wrote:
> On Mon, Apr 14, 2025 at 11:01:59AM +0800, Yunlong Xing wrote:
>> Set cmd->iocb.ki_ioprio to the ioprio of loop device's request.
>> The purpose is to inherit the original request ioprio in the aio
>> flow.
> 
> This looks good, but has a mechanical conflict with my
> "loop: stop using vfs_iter_{read,write} for buffered I/O" patch
> that fixes setting the block size for direct I/O.
> 
> Jens, any preference how we should order the patches?  Should I resend
> on top of this smaller one or the other way around?

I think we layer yours on top of this one, which is something I
can just do without much trouble. Do we want the vfs_iter removal
in 6.15 or is 6.16 fine for that?

-- 
Jens Axboe

Re: [PATCH V2] loop: aio inherit the ioprio of original request

[Jens Axboe]

On Mon, 14 Apr 2025 11:01:59 +0800, Yunlong Xing wrote:
> Set cmd->iocb.ki_ioprio to the ioprio of loop device's request.
> The purpose is to inherit the original request ioprio in the aio
> flow.
> 
> Signed-off-by:
> 

Applied, thanks!

[1/1] loop: aio inherit the ioprio of original request
      commit: d8ec13ceb917611582b52ecc28c34ddbb61ce0cf

Best regards,
-- 
Jens Axboe

Re: [PATCH V2] loop: aio inherit the ioprio of original request

[Christoph Hellwig]

On Mon, Apr 14, 2025 at 08:47:51AM -0600, Jens Axboe wrote:
> I think we layer yours on top of this one, which is something I
> can just do without much trouble. Do we want the vfs_iter removal
> in 6.15 or is 6.16 fine for that?

Sorry for the late reply, I was travelling to my Easter vacation.

Given that Darrick somehow managed to hit this old bug due to other
setup changes 6.15 would be great, and it looks like that's what you
did even without an answer from me.  Thanks!

Re: [PATCH V2] loop: aio inherit the ioprio of original request

[Jens Axboe]

On 4/15/25 10:32 PM, Christoph Hellwig wrote:
> On Mon, Apr 14, 2025 at 08:47:51AM -0600, Jens Axboe wrote:
>> I think we layer yours on top of this one, which is something I
>> can just do without much trouble. Do we want the vfs_iter removal
>> in 6.15 or is 6.16 fine for that?
> 
> Sorry for the late reply, I was travelling to my Easter vacation.
> 
> Given that Darrick somehow managed to hit this old bug due to other
> setup changes 6.15 would be great, and it looks like that's what you
> did even without an answer from me.  Thanks!

Exactly, that's what pushed it over the edge for me. So all queued
up.

-- 
Jens Axboe