io-uring.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andres Freund <andres@anarazel.de>
To: Jens Axboe <axboe@kernel.dk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	io-uring@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org,
	Bijan Mottahedeh <bijan.mottahedeh@oracle.com>,
	Sasha Levin <sashal@kernel.org>
Subject: Re: [PATCH 5.4 103/142] Revert "block: end bio with BLK_STS_AGAIN in case of non-mq devs and REQ_NOWAIT"
Date: Wed, 3 Feb 2021 15:59:41 -0800	[thread overview]
Message-ID: <20210203235941.2ibyrc5z3desyd2q@alap3.anarazel.de> (raw)
In-Reply-To: <14351e91-5a5f-d742-b087-dc9ec733bbfd@kernel.dk>

Hi,

On 2021-02-03 15:58:33 -0700, Jens Axboe wrote:
> On 2/3/21 3:06 PM, Greg Kroah-Hartman wrote:
> > On Wed, Feb 03, 2021 at 01:28:26PM -0800, Andres Freund wrote:
> >> On 2021-02-03 14:03:09 +0100, Greg Kroah-Hartman wrote:
> >>>> On v5.4.43-101-gbba91cdba612 this fails with
> >>>> fio: io_u error on file /mnt/t2/test.0.0: Input/output error: write offset=0, buflen=4096
> >>>> fio: pid=734, err=5/file:io_u.c:1834, func=io_u error, error=Input/output error
> >>>>
> >>>> whereas previously it worked. libaio still works...
> >>>>
> >>>> I haven't checked which major kernel version fixed this again, but I did
> >>>> verify that it's still broken in 5.4.94 and that 5.10.9 works.
> >>>>
> >>>> I would suspect it's
> >>>>
> >>>> commit 4503b7676a2e0abe69c2f2c0d8b03aec53f2f048
> >>>> Author: Jens Axboe <axboe@kernel.dk>
> >>>> Date:   2020-06-01 10:00:27 -0600
> >>>>
> >>>>     io_uring: catch -EIO from buffered issue request failure
> >>>>
> >>>>     -EIO bubbles up like -EAGAIN if we fail to allocate a request at the
> >>>>     lower level. Play it safe and treat it like -EAGAIN in terms of sync
> >>>>     retry, to avoid passing back an errant -EIO.
> >>>>
> >>>>     Catch some of these early for block based file, as non-mq devices
> >>>>     generally do not support NOWAIT. That saves us some overhead by
> >>>>     not first trying, then retrying from async context. We can go straight
> >>>>     to async punt instead.
> >>>>
> >>>>     Signed-off-by: Jens Axboe <axboe@kernel.dk>
> >>>>
> >>>>
> >>>> which isn't in stable/linux-5.4.y
> >>>
> >>> Can you test that if the above commit is added, all works well again?
> >>
> >> It doesn't apply cleanly, I'll try to resolve the conflict. However, I
> >> assume that the revert was for a concrete reason - but I can't quite
> >> figure out what b0beb28097fa04177b3769f4bb7a0d0d9c4ae76e was concretely
> >> solving, and whether reverting the revert in 5.4 would re-introduce a
> >> different problem.
> >>
> >> commit b0beb28097fa04177b3769f4bb7a0d0d9c4ae76e (tag: block-5.7-2020-05-29, linux-block/block-5.7)
> >> Author: Jens Axboe <axboe@kernel.dk>
> >> Date:   2020-05-28 13:19:29 -0600
> >>
> >>     Revert "block: end bio with BLK_STS_AGAIN in case of non-mq devs and REQ_NOWAIT"
> >>
> >>     This reverts commit c58c1f83436b501d45d4050fd1296d71a9760bcb.
> >>
> >>     io_uring does do the right thing for this case, and we're still returning
> >>     -EAGAIN to userspace for the cases we don't support. Revert this change
> >>     to avoid doing endless spins of resubmits.
> >>
> >>     Cc: stable@vger.kernel.org # v5.6
> >>     Reported-by: Bijan Mottahedeh <bijan.mottahedeh@oracle.com>
> >>     Signed-off-by: Jens Axboe <axboe@kernel.dk>
> >>
> >> I suspect it just wasn't aimed at 5.4, and that's that, but I'm not
> >> sure. In which case presumably reverting
> >> bba91cdba612fbce4f8575c5d94d2b146fb83ea3 would be the right fix, not
> >> backporting 4503b7676a2e0abe69c2f2c0d8b03aec53f2f048 et al.

Having looked a bit more through the history, I suspect that the reason
5.6 doesn't need c58c1f83436b501d45d4050fd1296d71a9760bcb - which I have
confirmed - is that ext4 was converted to the iomap infrastructure in
5.5, but not in 5.4.

I've confirmed that the repro I shared upthread triggers in
378f32bab3714f04c4e0c3aee4129f6703805550^ but not in
378f32bab3714f04c4e0c3aee4129f6703805550.


> > Ok, can you send a revert patch for this?
> > 
> > But it would be good to get Jens to weigh in on this...
> 
> I'll take a look at this.

Thanks.

Greetings,

Andres Freund

  reply	other threads:[~2021-02-04  0:00 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200601174037.904070960@linuxfoundation.org>
     [not found] ` <20200601174048.647302799@linuxfoundation.org>
2021-02-03 12:37   ` [PATCH 5.4 103/142] Revert "block: end bio with BLK_STS_AGAIN in case of non-mq devs and REQ_NOWAIT" Andres Freund
2021-02-03 13:03     ` Greg Kroah-Hartman
2021-02-03 21:28       ` Andres Freund
2021-02-03 22:06         ` Greg Kroah-Hartman
2021-02-03 22:58           ` Jens Axboe
2021-02-03 23:59             ` Andres Freund [this message]
2021-02-04 14:36               ` Jens Axboe
2021-02-04 15:04                 ` Greg Kroah-Hartman

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 \
    --in-reply-to=20210203235941.2ibyrc5z3desyd2q@alap3.anarazel.de \
    --to=andres@anarazel.de \
    --cc=axboe@kernel.dk \
    --cc=bijan.mottahedeh@oracle.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=io-uring@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sashal@kernel.org \
    --cc=stable@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).