Re: [PATCH v1 0/2] xfs: remove quota warning limits

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