From: Dominique Martinet <[email protected]>
To: Stefan Hajnoczi <[email protected]>
Cc: Jens Axboe <[email protected]>,
Stefano Garzarella <[email protected]>,
Aarushi Mehta <[email protected]>,
Julia Suvorova <[email protected]>, Kevin Wolf <[email protected]>,
Hanna Reitz <[email protected]>,
[email protected], [email protected],
Filipe Manana <[email protected]>,
[email protected]
Subject: Re: [PATCH v2] io_uring: fix short read slow path
Date: Wed, 6 Jul 2022 07:52:54 +0900 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <YsQ8aM3/[email protected]>
Stefan Hajnoczi wrote on Tue, Jul 05, 2022 at 02:28:08PM +0100:
> > The older kernel I have installed right now is 5.16 and that can
> > reproduce it -- I'll give my laptop some work over the weekend to test
> > still maintained stable branches if that's useful.
>
> Linux 5.16 contains commit 9d93a3f5a0c ("io_uring: punt short reads to
> async context"). The comment above QEMU's luring_resubmit_short_read()
> claims that short reads are a bug that was fixed by Linux commit
> 9d93a3f5a0c.
>
> If the comment is inaccurate it needs to be fixed. Maybe short writes
> need to be handled too.
>
> I have CCed Jens and the io_uring mailing list to clarify:
> 1. Are short IORING_OP_READV reads possible on files/block devices?
> 2. Are short IORING_OP_WRITEV writes possible on files/block devices?
Jens replied before me, so I won't be adding much (I agree with his
reply -- linux tries hard to avoid short reads but we should assume they
can happen)
In this particular case it was another btrfs bug with O_DIRECT and mixed
compression in a file, that's been fixed by this patch:
https://lore.kernel.org/all/20220630151038.GA459423@falcondesktop/
queued here:
https://git.kernel.org/pub/scm/linux/kernel/git/fdmanana/linux.git/commit/?h=dio_fixes&id=b3864441547e49a69d45c7771aa8cc5e595d18fc
It should be backported to 5.10, but the problem will likely persist in
5.4 kernels if anyone runs on that as the code changed enough to make
backporting non-trivial.
So, WRT that comment, we probably should remove the reference to that
commit and leave in that they should be very rare but we need to handle
them anyway.
For writes in particular, I haven't seen any and looking at the code
qemu would blow up that storage (IO treated as ENOSPC would likely mark
disk read-only?)
It might make sense to add some warning message that it's what happened
so it'll be obvious what needs doing in case anyone falls on that but I
think the status-quo is good enough here.
--
Dominique
next prev parent reply other threads:[~2022-07-05 22:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <[email protected]>
[not found] ` <[email protected]>
[not found] ` <20220630154921.ekl45dzer6x4mkvi@sgarzare-redhat>
[not found] ` <[email protected]>
2022-07-05 13:28 ` [PATCH v2] io_uring: fix short read slow path Stefan Hajnoczi
2022-07-05 19:23 ` Jens Axboe
2022-07-06 7:16 ` Stefan Hajnoczi
2022-07-05 22:52 ` Dominique Martinet [this message]
2022-07-06 7:17 ` Stefan Hajnoczi
2022-07-06 7:26 ` Dominique Martinet
2022-07-06 7:51 ` Stefan Hajnoczi
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 \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/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