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

Commit Message

Yunlong Xing April 14, 2025, 3:01 a.m. UTC

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 <[e-mail]>
Signed-off-by: Zhiguo Niu <[e-mail]>=
---
V2:
- Assign cmd->iocb.ki_ioprio in lo_rw_aio()
---
 drivers/block/loop.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Christoph Hellwig April 14, 2025, 6:12 a.m. UTC | #1

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 <[e-mail]>

Jens Axboe April 14, 2025, 2:47 p.m. UTC | #2

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 April 14, 2025, 2:48 p.m. UTC | #3

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,

Christoph Hellwig April 16, 2025, 4:32 a.m. UTC | #4

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!

Jens Axboe April 16, 2025, 2:58 p.m. UTC | #5

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.

Patch

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);