From: Brian Foster <bfoster@redhat.com>
To: gregkh <gregkh@linuxfoundation.org>
Cc: Alvin Zheng <Alvin@linux.alibaba.com>,
"darrick.wong" <darrick.wong@oracle.com>, axboe <axboe@kernel.dk>,
linux-block <linux-block@vger.kernel.org>,
linux-xfs <linux-xfs@vger.kernel.org>,
caspar <caspar@linux.alibaba.com>,
"joseph.qi" <joseph.qi@linux.alibaba.com>
Subject: Re: [bug report][stable] xfstests:generic/538 failed on xfs
Date: Wed, 5 Jun 2019 09:57:59 -0400 [thread overview]
Message-ID: <20190605135756.GA15671@bfoster> (raw)
In-Reply-To: <20190605124227.GC17558@kroah.com>
On Wed, Jun 05, 2019 at 02:42:27PM +0200, gregkh wrote:
> On Wed, Jun 05, 2019 at 08:21:44PM +0800, Alvin Zheng wrote:
> > Hi,
> > I was using kernel v4.19.48 and found that it cannot pass the generic/538 on xfs. The error output is as follows:
>
> Has 4.19 ever been able to pass that test? If not, I wouldn't worry
> about it :)
>
FWIW, the fstests commit references the following kernel patches for
fixes in XFS and ext4:
xfs: serialize unaligned dio writes against all other dio writes
ext4: fix data corruption caused by unaligned direct AIO
It looks like both of those patches landed in 5.1.
Brian
> >
> > FSTYP -- xfs (non-debug)
> > PLATFORM -- Linux/x86_64 alinux2-6 4.19.48
> > MKFS_OPTIONS -- -f -bsize=4096 /dev/vdc
> > MOUNT_OPTIONS -- /dev/vdc /mnt/testarea/scra
> > generic/538 0s ... - output mismatch (see /root/usr/local/src/xfstests/results//generic/538.out.bad)
> > --- tests/generic/538.out 2019-05-27 13:57:06.505666465 +0800
> > +++ /root/usr/local/src/xfstests/results//generic/538.out.bad 2019-06-05 16:43:14.702002326 +0800
> > @@ -1,2 +1,10 @@
> > QA output created by 538
> > +Data verification fails
> > +Find corruption
> > +00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> > +*
> > +00000200 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ
> > +00002000
> > ...
> > (Run 'diff -u /root/usr/local/src/xfstests/tests/generic/538.out /root/usr/local/src/xfstests/results//generic/538.out.bad' to see the entire diff)
> > Ran: generic/538
> > Failures: generic/538
> > Failed 1 of 1 tests
> >
> > I also found that the latest kernel (v5.2.0-rc2) of upstream can pass the generic/538 test. Therefore, I bisected and found the first good commit is 3110fc79606. This commit adds the hardware queue into the sort function. Besides, the sort function returns a negative value when the offset and queue (software and hardware) of two I/O requests are same. I think the second part of the change make senses. The kernel should not change the relative position of two I/O requests when their offset and queue are same. So I made the following changes and merged it into the kernel 4.19.48. After the modification, we can pass the generic/538 test on xfs. The same case can be passed on ext4, since ext4 has corresponding fix 0db24122bd7f ("ext4: fix data corruption caused by overlapping unaligned and aligned IO"). Though I think xfs should be responsible for this issue, the block layer code below is also problematic. Any ideas?
> >
> > diff --git a/block/blk-mq.c b/block/blk-mq.c
> > index 4e563ee..a7309cd 100644
> > --- a/block/blk-mq.c
> > +++ b/block/blk-mq.c
> > @@ -1610,7 +1610,7 @@ static int plug_ctx_cmp(void *priv, struct list_head *a, struct list_head *b)
> >
> > return !(rqa->mq_ctx < rqb->mq_ctx ||
> > (rqa->mq_ctx == rqb->mq_ctx &&
> > - blk_rq_pos(rqa) < blk_rq_pos(rqb)));
> > + blk_rq_pos(rqa) <= blk_rq_pos(rqb)));
> > }
> >
> > void blk_mq_flush_plug_list(struct blk_plug *plug, bool from_schedule)
>
> I would not like to take a patch that is not upstream, but rather take
> the original commit.
>
> Can 3110fc79606f ("blk-mq: improve plug list sorting") on its own
> resolve this issue for 4.19.y?
>
> thanks,
>
> greg k-h
next prev parent reply other threads:[~2019-06-05 13:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-05 12:21 [bug report][stable] xfstests:generic/538 failed on xfs Alvin Zheng
2019-06-05 12:42 ` gregkh
2019-06-05 13:57 ` Brian Foster [this message]
2019-06-05 22:51 ` Joseph Qi
2019-06-06 3:13 ` Alvin Zheng
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=20190605135756.GA15671@bfoster \
--to=bfoster@redhat.com \
--cc=Alvin@linux.alibaba.com \
--cc=axboe@kernel.dk \
--cc=caspar@linux.alibaba.com \
--cc=darrick.wong@oracle.com \
--cc=gregkh@linuxfoundation.org \
--cc=joseph.qi@linux.alibaba.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-xfs@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.