public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Tso" <tytso@mit.edu>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Mark Brown <broonie@kernel.org>, Jan Kara <jack@suse.cz>,
	Francesco Dolcini <francesco@dolcini.it>,
	Brian Foster <bfoster@redhat.com>,
	Yongjian Sun <sunyongjian1@huawei.com>,
	Matthew Wilcox <willy@infradead.org>,
	Gou Hao <gouhao@uniontech.com>,
	Kemeng Shi <shikemeng@huaweicloud.com>,
	Zhang Yi <yi.zhang@huawei.com>, Baokun Li <libaokun1@huawei.com>,
	stable@vger.kernel.org, patches@lists.linux.dev,
	linux-kernel@vger.kernel.org, torvalds@linux-foundation.org,
	akpm@linux-foundation.org, linux@roeck-us.net, shuah@kernel.org,
	patches@kernelci.org, lkft-triage@lists.linaro.org,
	pavel@nabladev.com, jonathanh@nvidia.com, f.fainelli@gmail.com,
	sudipm.mukherjee@gmail.com, rwarsow@gmx.de, conor@kernel.org,
	hargar@microsoft.com, achill@achill.org, sr@sladewatkins.com
Subject: Re: [PATCH 6.1 000/481] 6.1.167-rc1 review
Date: Mon, 6 Apr 2026 23:37:10 -0400	[thread overview]
Message-ID: <20260407033710.GA12536@macsyma-wired.lan> (raw)
In-Reply-To: <2026032547-spleen-mortify-1cf9@gregkh>

On Wed, Mar 25, 2026 at 02:31:28PM +0100, Greg Kroah-Hartman wrote:
> > Thanks!  Just as another heads up, I decided to run a full regression
> > test suite on 6.1.167-rc1 with those three reverts, and there ar still
> > some crashes with generic/051 and ext4/039:
> > 
> > ext4/4k: 711 tests, 1 errors, 83 skipped, 4645 seconds
> >   Errors: generic/051
> > ext4/1k: 636 tests, 7 failures, 1 errors, 78 skipped, 5612 seconds
> >   Errors: ext4/039
> > ....

> > I'll start trying to bisect this as I have time today.  Are you going
> > to put out another rc and restart the 48 hour testing clock?
> 
> No, I've already done a release, I dropped more than just those 3, I
> dropped all the dependent ext4 patches.
> 
> If you could test the last release and if I should do any reverts there,
> please let me know.

I finally got around to doing the bisect, and found the guilty commit:

# first bad commit: [b6a01b66cdaa2da526b512fc0f9938ea5d6c7a1c] ext4: get rid of ppath in ext4_ext_insert_extent()

As it turns out, this is one of (5!) prerequisite commits needed for
commit 1606176c5c6c ("ext4: subdivide EXT4_EXT_DATA_VALID1").  And
unfortunately, commit 1606176c5c6c doesn't revert cleanly.

... and with that, I've exhausted my available time to support ext4 on
an ancient 6.1 LTS kernel.  I will note that I'm no longer regularly
running ext4 regression tests on 6.1.  (I stopped last year, when 6.18
got elevanted to be the YE2025 LTS kernel, since I only have bandwidth
to evaluate the regression test results of 3 LTS kernels.)

So if there's someone who is willing to the ext4 LTS 6.1 stable
maintainer, I wonder if we should just stop trying to backport ext4
fixes to 6.1 LTS, lest that attempts to backport patches all the way
to 6.1 might result in more bug escapes.  If someone is interested in
applying for the job, and/or working on figuring out how to revert
these commits, please let me know:

1606176c5c6c - ext4: subdivide EXT4_EXT_DATA_VALID1 (13 days ago)
  4d03e2046f73 - ext4: get rid of ppath in ext4_split_extent_at() (13 days ago)
  b6a01b66cdaa - ext4: get rid of ppath in ext4_ext_insert_extent() (13 days ago
)
  15908fc35056 - ext4: get rid of ppath in ext4_ext_create_new_leaf() (13 days a
go)
  b5a010bc7dba - ext4: get rid of ppath in ext4_find_extent() (13 days ago)
  bfe24a48c1d5 - ext4: make ext4_es_remove_extent() return void (13 days ago)

       	       	    			    	   - Ted
							   
git bisect start
# status: waiting for both good and bad commits
# good: [f2ddafa93a259310ca47507153b7811ec54ab7fd] Linux 6.1.166
git bisect good f2ddafa93a259310ca47507153b7811ec54ab7fd
# status: waiting for bad commit, 1 good commit known
# bad: [1989cd3d56e257c783ac75200496a2341b50599c] Linux 6.1.167
git bisect bad 1989cd3d56e257c783ac75200496a2341b50599c
# bad: [7507fbaf81dab28d1d27216c533e228894e9d1f6] parisc: Check kernel mapping earlier at bootup
git bisect bad 7507fbaf81dab28d1d27216c533e228894e9d1f6
# bad: [30752d8bbd149abce36f37e83b89bd2934bfa33c] bpf: export bpf_link_inc_not_zero.
git bisect bad 30752d8bbd149abce36f37e83b89bd2934bfa33c
# bad: [6458b4908489029bc3bb3c0a7c2fc5cb0c2893f3] ALSA: hda/conexant: Fix headphone jack handling on Acer Swift SF314
git bisect bad 6458b4908489029bc3bb3c0a7c2fc5cb0c2893f3
# good: [5135f242e01e8fd602211703e94171b85bb87d4f] KVM: x86: Return "unsupported" instead of "invalid" on access to unsupported PV MSR
git bisect good 5135f242e01e8fd602211703e94171b85bb87d4f
# bad: [1606176c5c6c323167dcd7d4b4f7212b2c8d3d13] ext4: subdivide EXT4_EXT_DATA_VALID1
git bisect bad 1606176c5c6c323167dcd7d4b4f7212b2c8d3d13
# good: [b5452125f9bd60f90f06da080d3eb18445c61d24] drm/tegra: dsi: fix device leak on probe
git bisect good b5452125f9bd60f90f06da080d3eb18445c61d24
# good: [b5a010bc7dba7e3d0966c0231335ca76b3f8780e] ext4: get rid of ppath in ext4_find_extent()
git bisect good b5a010bc7dba7e3d0966c0231335ca76b3f8780e
# bad: [b6a01b66cdaa2da526b512fc0f9938ea5d6c7a1c] ext4: get rid of ppath in ext4_ext_insert_extent()
git bisect bad b6a01b66cdaa2da526b512fc0f9938ea5d6c7a1c
# good: [15908fc35056e9a6fd71552eda884a353496e6c7] ext4: get rid of ppath in ext4_ext_create_new_leaf()
git bisect good 15908fc35056e9a6fd71552eda884a353496e6c7
# first bad commit: [b6a01b66cdaa2da526b512fc0f9938ea5d6c7a1c] ext4: get rid of ppath in ext4_ext_insert_extent()

  reply	other threads:[~2026-04-07  3:39 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-23 13:39 [PATCH 6.1 000/481] 6.1.167-rc1 review Greg Kroah-Hartman
2026-03-23 15:20 ` Brett A C Sheffield
2026-03-23 16:39 ` Peter Schneider
2026-03-23 19:16 ` Florian Fainelli
2026-03-23 19:18 ` Pavel Machek
2026-03-23 22:14 ` Shuah Khan
2026-03-24  0:31 ` Slade Watkins
2026-03-24  7:34 ` Francesco Dolcini
2026-03-24 11:57   ` Greg Kroah-Hartman
2026-03-24 13:40   ` Jan Kara
2026-03-24 15:36     ` Mark Brown
2026-03-25  3:59       ` Theodore Tso
2026-03-25  9:49         ` Greg Kroah-Hartman
2026-03-25 13:11           ` Theodore Tso
2026-03-25 13:31             ` Greg Kroah-Hartman
2026-04-07  3:37               ` Theodore Tso [this message]
2026-03-25  9:03   ` Sun Yongjian
2026-03-25 13:34     ` Theodore Tso
2026-03-26  3:01       ` Sun Yongjian
2026-03-24  8:41 ` Ron Economos
2026-03-24  9:03 ` Jon Hunter
2026-03-24 15:38 ` Mark Brown
2026-03-24 23:53 ` Miguel Ojeda
2026-03-30  8:32 ` Guenter Roeck
2026-03-30  9:20   ` Greg Kroah-Hartman
2026-03-30 15:20     ` Guenter Roeck
2026-03-30  9:12 ` Guenter Roeck

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=20260407033710.GA12536@macsyma-wired.lan \
    --to=tytso@mit.edu \
    --cc=achill@achill.org \
    --cc=akpm@linux-foundation.org \
    --cc=bfoster@redhat.com \
    --cc=broonie@kernel.org \
    --cc=conor@kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=francesco@dolcini.it \
    --cc=gouhao@uniontech.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hargar@microsoft.com \
    --cc=jack@suse.cz \
    --cc=jonathanh@nvidia.com \
    --cc=libaokun1@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=lkft-triage@lists.linaro.org \
    --cc=patches@kernelci.org \
    --cc=patches@lists.linux.dev \
    --cc=pavel@nabladev.com \
    --cc=rwarsow@gmx.de \
    --cc=shikemeng@huaweicloud.com \
    --cc=shuah@kernel.org \
    --cc=sr@sladewatkins.com \
    --cc=stable@vger.kernel.org \
    --cc=sudipm.mukherjee@gmail.com \
    --cc=sunyongjian1@huawei.com \
    --cc=torvalds@linux-foundation.org \
    --cc=willy@infradead.org \
    --cc=yi.zhang@huawei.com \
    /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