Re: [PATCH 5.15 CANDIDATE 00/10] more xfs fixes for 5.15

[Dave Chinner <david@fromorbit.com>]

On Wed, Feb 08, 2023 at 11:40:59AM -0800, Darrick J. Wong wrote:
> On Wed, Feb 08, 2023 at 09:02:58PM +0200, Amir Goldstein wrote:
> > On Wed, Feb 8, 2023 at 7:52 PM Leah Rumancik <leah.rumancik@gmail.com> wrote:
> > >
> > > Hello again,
> > >
> > > Here is the next batch of backports for 5.15.y. Testing included
> > > 25 runs of auto group on 12 xfs configs. No regressions were seen.
> > > I checked xfs/538 was run without issue as this test was mentioned
> > > in 56486f307100. Also, from 86d40f1e49e9, I ran ran xfs/117 with
> > > XFS compiled as a module and TEST_FS_MODULE_REOLOAD set, but I was
> > > unable to reproduce the issue.
> > 
> > Did you find any tests that started to pass or whose failure rate reduced?
> 
> I wish Leah had, but there basically aren't any tests for the problems
> fixed in this set for her to find. :(
.....
> > There are very few Fixes: annotations in these commits so it is hard for
> > me to assess if any of them are relevant/important/worth the effort/risk
> > to backport to 5.10.
> 
> <nod> Dave's fixpatches rarely have Fixes tags attached.  It's difficult
> to get him to do that because he has so much bad history with AUTOSEL.
> I've tried to get him to add them in the past, but if I'm already
> stressed out and Dave doesn't reply then I tend to merge the fix and
> move on.

In my defense, all the "fixes" from me in this series (except for
the one with a fixes tag on it) date back so long ago it was
difficult to identify what commit actually introduced the issue.
Once we're talking about "it's been there for at least a decade" -
espcially for fuzzer issues - identifying the exact commit is time
consuming and often not possible, nor really useful for anything.

I'm also not going to tag a patch with "fixes commit xyz" when
commit xyz isn't actually the cause of the problem just so that
someone can blindly use that as a "it's got a fixes tag on it, we
should back port it" trigger.

That's the whole problem with AUTOSEL - blindly applying anything
with a fixes tag on it that merges cleanly into an older kernel -
and the whole point of having a human actually manage the stable
kernel backports.

The stable XFS kernel maintainer is supposed to be actively looking
at the commits that go into the upstream kernel to determine if they
are relevant or not to the given stable kernel, regardless of
whether they address fstests failures, have fixes/stable tags on
them, etc. If all we needed stable maintainers to do is turn a crank
handle, then we'd be perfectly OK with AUTOSEL and the upstream
stable kernel process....

-Dave.
-- 
Dave Chinner
david@fromorbit.com