Re: kernel BUG in ext4_free_blocks (2)

From: Aleksandr Nogikh <nogikh@google.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: Lee Jones <lee@kernel.org>,
	syzbot <syzbot+15cd994e273307bf5cfa@syzkaller.appspotmail.com>,
	adilger.kernel@dilger.ca, gregkh@linuxfoundation.org,
	lczerner@redhat.com, linux-ext4@vger.kernel.org,
	linux-kernel@vger.kernel.org, sashal@kernel.org,
	stable@vger.kernel.org, syzkaller-android-bugs@googlegroups.com,
	tadeusz.struk@linaro.org
Subject: Re: kernel BUG in ext4_free_blocks (2)
Date: Fri, 16 Dec 2022 18:14:50 +0100	[thread overview]
Message-ID: <CANp29Y4QVp1G83pSqpxeETbw_+kQQ5CZUz+Vgi767WxE8AuhHQ@mail.gmail.com> (raw)
In-Reply-To: <Y5ylNxoN2p7dmcRD@mit.edu>

On Fri, Dec 16, 2022 at 6:05 PM Theodore Ts'o <tytso@mit.edu> wrote:
>
> On Fri, Dec 16, 2022 at 03:09:04PM +0100, Aleksandr Nogikh wrote:
> >
> > Syzbot is actually reacting here to this bug from the Android namespace:
> >
> > https://syzkaller.appspot.com/bug?id=5266d464285a03cee9dbfda7d2452a72c3c2ae7c
>
> Thanks for the clarification; stupid question, though -- I see
> "upstream" is listed on the dashboard link above.  Assuming that
> "usptream" is "Linus's tree", why was it still saying, "I can't find
> this patch in any of my trees"?  What about the upstream tree?

Bugs from different namespaces are treated independently, so in this
particular case syzbot was expecting the fixing commit to reach the
Android trees that it fuzzes.

--
Aleksandr

>
> > > Although this does appear to be a Stable candidate, I do not see it
> > > in any of the Stable branches yet.  So I suspect the answer here is to
> > > wait for the fix to filter down.
>
> The reason why it's not hit any of the long-term stable trees is
> because the patch doesn't apply cleanly, because there are
> pre-requisite commits that were required.  Here are the required
> commits for 5.15:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git ext4_for_5.15.83
>
> % git log --reverse --oneline  v5.15.83..
> 96d070a12a7c ext4: refactor ext4_free_blocks() to pull out ext4_mb_clear_bb()
>     [ Upstream commit 8ac3939db99f99667b8eb670cf4baf292896e72d ]
> 2fa7a1780ecd ext4: add ext4_sb_block_valid() refactored out of ext4_inode_block_valid()
>     [ Upstream commit 6bc6c2bdf1baca6522b8d9ba976257d722423085 ]
> 8dc76aa246b1 ext4: add strict range checks while freeing blocks
>     [ Upstream commit a00b482b82fb098956a5bed22bd7873e56f152f1 ]
> deb2e1554497 ext4: block range must be validated before use in ext4_mb_clear_bb()
>     [ Upstream commit 1e1c2b86ef86a8477fd9b9a4f48a6bfe235606f6 ]
>
> Further backports to LTS kernels for 5.10, 5.4, etc., are left as an
> exercise to the reader.  :-)
>
>                                              - Ted
>
> P.S.  I have not tried to run gce-xfstests regressions yet. so the
> only QA done on these backports is "it builds, ship it!"  (And it
> fixes the syzbot reproducers.)  Then again, we're not running this
> kind of regression tests on the LTS kernels.
>
> P.P.S.  If anyone is willing to volunteer to be an ext4 backports
> maintainer, please contact me.  The job description is (a) dealing
> with the stable backport failures and addressing the patch conflicts,
> potentially by dragging in patch prerequisites, and (b) running
> "gce-xfstests ltm -c ext4/all -g auto" and making sure there are no
> regressions.
>
>                                               - Ted