From: Brian Foster <bfoster@redhat.com>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Dave Chinner <david@fromorbit.com>,
Eric Sandeen <sandeen@sandeen.net>,
Catherine Hoang <catherine.hoang@oracle.com>,
linux-xfs@vger.kernel.org
Subject: Re: [PATCH v1 0/2] xfs: remove quota warning limits
Date: Wed, 27 Apr 2022 10:09:00 -0400 [thread overview]
Message-ID: <YmlOfJljvI49sZyW@bfoster> (raw)
In-Reply-To: <Ymg6yvbrE//70InS@bfoster>
On Tue, Apr 26, 2022 at 02:32:42PM -0400, Brian Foster wrote:
> On Tue, Apr 26, 2022 at 07:53:47AM -0700, Darrick J. Wong wrote:
> > On Tue, Apr 26, 2022 at 10:15:47AM -0400, Brian Foster wrote:
> > > On Mon, Apr 25, 2022 at 07:43:31PM -0700, Darrick J. Wong wrote:
> > > ...
> > > >
> > > > The biggest problem right now is that the pagecache is broken in 5.18
> > > > and apparently I'm the only person who can trigger this. It's the same
> > > > problem willy and I have been working on since -rc1 (where the
> > > > filemap/iomap debug asserts trip on generic/068 and generic/475) that's
> > > > documented on the fsdevel list. Unfortunately, I don't have much time
> > > > to work on this, because as team lead:
> > > >
> > >
> > > I seem to be able to reproduce this fairly reliably with generic/068.
> > > I've started a bisect if it's of any use...
> >
> > Thank you! Matthew has hinted that he suspects this is a case of the
> > page cache returning the wrong folio in certain cases, but neither of us
> > have been able to narrow it down to a specific commit, or even a range.
> >
>
> So my first stab at a bisect...
>
> git bisect start 'fs' 'mm' 'include/'
> ...
> # good: [65722ff6181aa52c3d5b0929004af22a3a63e148] drm/amdkfd: CRIU export dmabuf handles for GTT BOs
> git bisect good 65722ff6181aa52c3d5b0929004af22a3a63e148
> # good: [89695196f0ba78a17453f9616355f2ca6b293402] Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
> git bisect good 89695196f0ba78a17453f9616355f2ca6b293402
> # bad: [52deda9551a01879b3562e7b41748e85c591f14c] Merge branch 'akpm' (patches from Andrew)
> git bisect bad 52deda9551a01879b3562e7b41748e85c591f14c
> # bad: [169e77764adc041b1dacba84ea90516a895d43b2] Merge tag 'net-next-5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next
> git bisect bad 169e77764adc041b1dacba84ea90516a895d43b2
> # first bad commit: [169e77764adc041b1dacba84ea90516a895d43b2] Merge tag 'net-next-5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next
>
> ... landed on a netdev merge commit. :/ That doesn't seem terribly
> informative. I suspect either I was too aggressive with the testing or
> source dir tree filtering. I've manually confirmed that the last couple
> of marked merge commits are good and bad respectively, so I'll probably
> try a new bisect of that range without any filtering and a bit more
> deliberate testing (which will take a bit longer) and see if that yields
> anything more useful.
>
Bisect round two lands on commit 56a4d67c264e ("mm/readahead: Switch to
page_cache_ra_order"). I'm not sure how much of a smoking gun that is
given it looks like it switches mmapped readahead over to a different
code path, but I reproduced nearly instantly as of that commit and I'm
now spinning the test against a HEAD of the immediately previous commit
(1854bc6e2420 ("mm/readahead: Align file mappings for non-DAX")) with
probably 130+ successful iterations so far. I'll let it spin a while
longer just to be sure.
Brian
> Brian
>
> > --D
> >
> > > Brian
> > >
> >
prev parent reply other threads:[~2022-04-27 14:09 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-21 16:58 [PATCH v1 0/2] xfs: remove quota warning limits Catherine Hoang
2022-04-21 16:58 ` [PATCH v1 1/2] xfs: remove quota warning limit from struct xfs_quota_limits Catherine Hoang
2022-04-27 18:47 ` Alli
2022-04-27 20:29 ` Darrick J. Wong
2022-04-21 16:58 ` [RFC PATCH v1 2/2] xfs: don't set warns on the id==0 dquot Catherine Hoang
2022-04-22 1:40 ` Dave Chinner
2022-04-25 15:34 ` Catherine Hoang
2022-04-25 22:42 ` Dave Chinner
2022-04-29 17:20 ` Alli
2022-04-29 19:38 ` Darrick J. Wong
2022-04-27 20:29 ` Darrick J. Wong
2022-04-28 6:36 ` [xfs] 3937433c63: xfstests.xfs.153.fail kernel test robot
2022-04-25 18:19 ` [PATCH v1 0/2] xfs: remove quota warning limits Eric Sandeen
2022-04-25 22:21 ` Dave Chinner
2022-04-26 2:43 ` Darrick J. Wong
2022-04-26 4:29 ` Dave Chinner
2022-04-26 5:14 ` Darrick J. Wong
2022-04-26 14:15 ` Brian Foster
2022-04-26 14:53 ` Darrick J. Wong
2022-04-26 18:32 ` Brian Foster
2022-04-27 14:09 ` Brian Foster [this message]
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=YmlOfJljvI49sZyW@bfoster \
--to=bfoster@redhat.com \
--cc=catherine.hoang@oracle.com \
--cc=david@fromorbit.com \
--cc=djwong@kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@sandeen.net \
/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