Re: [PATCH] ext4: get rid of ppath in get_ext_path()

["Theodore Tso" <tytso@mit.edu>]

> 
> This patch is trying to fix the regression which Introduced by this series:
> 
>     [PATCH 6.6 046/567] ext4: get rid of ppath in ext4_ext_insert_extent()
>

The subject line in the patch did not make it clear that this was
fixing a breakage caused by a backport from upstream kernel into 6.6.
So I was quite confused, and given that no one pays me to work on LTS
kernels, and I wasted several days debugging the 6.1 backport before
figuring out what the guilty commit that needed reverting, and life
has gotten super busy at $WORK, I decided to say, oh well, the failure
was only triggered (as far as I know) by tests exercising the shutdown
path, and life was too short to figure out how to untangle 6.6 LTS.

Instead, I've just been telling people that they **really** should
just use far more recent LTS kernels, because from a security
perpsective, lots of patches never get backported to older LTS kernels
--- and in a post Mythos world, it's probably not reasonable to be
using 6.1 or 6.6 --- and sometimes the auto-backport results in flaky
LTS kernels --- and while there had been an attempt to organize
companies to contribute SWE effort to test and stablize xfs, (a) in
the past 18 months, all of the companies who had contriburted SWE time
had with drawn that effort, and (b) I've never been able to recruit
people willing to do this for ext4.  And I'm too busy to spend time
after midnight or on weekends doing it for older LTS kernels for free.

> So I'm confused about the next action will we accept Wang Jun's
> patch or we just revert it as 6.1 did ?

The commit description in Wang Jun's patch needs to explain that it's
fixing a but that was introduced in the LTS backport.  As memory
serves, after the several day effort to figure out the guilty commmt
in 6.1 LTS, we determined that the purported bug that the half-dozen
odd commits (including the dependencies), wasn't even **applicable**
for 6.1.  So it was all just a massive waste of my time.

I have not done the analysis to determine whether the patch series in
6.6 that caused the regression is actually fixing a bug in the 6.6 LTS
kernel.  If it doesn't, perhaps reverting the whole mess is the better
approach.  Or if someone wants to take Wang Jun's patch, and run it
through a full set of regression test suites, using something like:

   gce-xfstests ltm -c ext4/all -g auto

or the equivalent, and it passes without triggering crashes and
without causing more regressions, Wang Jun's patch seems to make
sense.  For more instructions on how to run the test, see [1][2].

[1] https://thunk.org/gce-xfstests
[2] https://github.com/tytso/xfstests-bld/blob/master/Documentation/gce-xfstests.md

And if you are interested in helping out with ext4 stable kernel
maintenace, I'd love the volunteer help.  After the mess with the 6.1
and 6.6 LTS backports, I've been tempted to just tell the stable
kernel maintainers to stop backporting fixes to 6.1 and 6.6.  (The XFS
community has standing instructions not to back *any* backports to LTS
kernels,b ecause of this instability problem.  The fix of having
developers actually do QA before sending out backports works, and is
certainly much better than the "it builds, ship it!" approach --- but
the downside is that most companies aren't willing to devote the time
to do that backports, especially now in the post Mythos world, your
internal security teams are probably requiring you to use much newer
LTS kernels anyway.)

Cheers,

						- Ted