Re: PROBLEM: NULL pointer dereference in ext4_mb_load_buddy_gfp

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

On Tue, Nov 03, 2026 at 08:47:21PM -0500, Bartos-Elekes Zsolt wrote:
> Eric Biggers wrote:
> 
> > On Tue, Nov 03, 2026 at 03:26:08PM +0100, Bartos-Elekes Zsolt wrote:
> > > Linux version 6.1.191 (me@hostname) (gcc (Debian 12.2.0-14+deb12u1) 12.2.0,
> > 
> > Yes, the stable maintainers broke ext4 in 6.1.191.  The fix is
> > https://lore.kernel.org/linux-ext4/20261102-ext4-ntfs3-null-folio-v1-1-4fd91ee23a4a@elliotjb.com/

Note that I *strongly* recommend that people use a kernel newer than
6.1 or 6.6.  A lot of security fixes don't get backported to the older
LTS kernels due to merge/cherry-pick conflicts, so your security team
might be prohibiting or strongly disuading you from using such ancient
LTS kernels.

Furthermore, the "it builds, ship it" approach towards backporting
fixes (including security fixes) is understandable, given the huge
influx of fixes to AI-discovered security vulnerability.
Unfortunately, it leads to frequent breakages to the older LTS
kernels, and I no longer have time to debug ext4 failures to 6.1 and
6.6 LTS kernels.

This is not to criticize those people who supply fixes to the 6.1 and
6.6 LTS kernels; in fact, I'm quite grateful for the people who do the
work to support those older LTS kernels.  And BTW, if someone is
willing to be the ext4 stable backports maintainer for the older LTS
kernels, and take on that responsibility in a more formal way. please
contact me off-line.

Cheers,

					- Ted

P.S.  It's not hard to monitor the 6.1-rc and 6.6-rc LTS kernels.
That part is automated, and I can supply an e-mail feed of the
automated runs of "gce-xfstests ltm -c ext4/all -g auto --repo
stable-rc.git --watch linux-6.1.y"

It's having a human being look at the huge number of test failures and
notice when there are new failures (regressions), and then when there
inevitably is a regression, doing the bisect to figure out which
backport caused the failure is the thing I don't have time to do.