linux-kernel - Re: [GIT PULL] erofs fix for 6.19-rc5 (fix the stupid mistake)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOQ4uxi99wRKca1M-tvgb5SrhcuK=R_8q9nYRsf=CxLOTtU5Og@mail.gmail.com>
Date: Sat, 10 Jan 2026 11:48:38 +0100
From: Amir Goldstein <amir73il@...il.com>
To: Gao Xiang <hsiangkao@...ux.alibaba.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, linux-erofs@...ts.ozlabs.org, 
	LKML <linux-kernel@...r.kernel.org>, Alexander Larsson <alexl@...hat.com>, 
	Dusty Mabe <dusty@...tymabe.com>, Chao Yu <chao@...nel.org>, 
	Sheng Yong <shengyong1@...omi.com>, Zhiguo Niu <zhiguo.niu@...soc.com>, 
	Christian Brauner <brauner@...nel.org>, Miklos Szeredi <mszeredi@...hat.com>, Gao Xiang <xiang@...nel.org>
Subject: Re: [GIT PULL] erofs fix for 6.19-rc5 (fix the stupid mistake)

On Sat, Jan 10, 2026 at 11:30 AM Gao Xiang <hsiangkao@...ux.alibaba.com> wrote:
>
> Hi Amir,
>
> On 2026/1/10 17:50, Amir Goldstein wrote:
> > On Sat, Jan 10, 2026 at 8:27 AM Gao Xiang <xiang@...nel.org> wrote:
> >>
> >> Hi Linus,
> >>
> >> Very sorry I sent an incorrect pull request which used an
> >> outdated PATCH version (I just manually applied tags on the
> >> incorrect version, but I didn't realize), I shouldn't make
> >> the stupid mistake in the beginning.
> >>
> >> Someone reminded me the mistake just now.
> >>
> >> Could you please apply this pull request, I promise that I
> >> won't make the similar fault again and I should be blamed.
> >>
> >> Thanks,
> >> Gao Xiang
> >>
> >> The following changes since commit 072a7c7cdbea4f91df854ee2bb216256cd619f2a:
> >>
> >>    erofs: don't bother with s_stack_depth increasing for now (2026-01-10 13:01:15 +0800)
> >>
> >> are available in the Git repository at:
> >>
> >>    git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs.git tags/erofs-for-6.19-rc5-fixes-2
> >>
> >> for you to fetch changes up to 0a7468a8de7a2721cc0cce30836726f2a3ac2120:
> >>
> >>    erofs: don't bother with s_stack_depth increasing for now [real fix] (2026-01-10 15:13:12 +0800)
> >>
> >> ----------------------------------------------------------------
> >> Changes since last update:
> >>
> >>   - Revert the incorrect outdated PATCH version
> >>
> >>   - Apply the correct fix of
> >>     "erofs: don't bother with s_stack_depth increasing for now"
> >>
> >> ----------------------------------------------------------------
> >> Gao Xiang (2):
> >>        Revert "erofs: don't bother with s_stack_depth increasing for now"
> >>        erofs: don't bother with s_stack_depth increasing for now [real fix]
> >>
> >
> > Gao,
> >
> > You merged the wrong patch version by mistake - no real harm done.
>
> Sadly, the merged one doesn't work for Android APEX (Sheng actually
> claimed that PATCH v3 RESEND works instead of PATCH v3 [I'm very sorry
> for v3 RESEND mark again here] and it was him found that the merged
> pull request used wrong version and he gave me a private text hours
> ago), see my explanation below.
>

Yes. That's what I said.

> >
> > But now that it was merged, for the sake of git history, I think it would
> > be better to merge a fix patch rather than revert + patch with same title.
>
> My concern would be that people could merge incomplete patch chain,
> but I'm fine to send a fix for the fix, I will do.
>

This is what the Fixes: tag is for.
Stable kernel maintainers know how to look for those when applying fixes.

> >
> > If you merge a fix patch you could properly attribute Report/Review/Tested-by
> > to Sheng Yong [1].
> >
> > It's true that the merged patch already claims to work for Android APEX,
> > but it had a braino bug and this is what fix patches are for.
>
> Sigh, the merged patch (PATCH v3) actually _breaks_ APEX (it's just
> like PATCH v1/v2), because:
>                 if (erofs_is_fileio_mode(sbi)) {
> -                       sb->s_stack_depth =
> -                               file_inode(sbi->dif0.file)->i_sb->s_stack_depth + 1;
> -                       if (sb->s_stack_depth > FILESYSTEM_MAX_STACK_DEPTH) {
> -                               erofs_err(sb, "maximum fs stacking depth exceeded");
> +                       inode = file_inode(sbi->dif0.file);
> +                       if ((inode->i_sb->s_op == &erofs_sops && !sb->s_bdev) ||
>
> Here `!sb->s_bdev` is true for all file-backed mounts all the time,
> so `!sb->s_bdev` equals to a no-op.
>
> +                           inode->i_sb->s_stack_depth) {
>
> I will make a delta patch candidate with his "Reported-by:" and
> "Tested-by:", I will try to send now.
>
> It seems I need to sleep later because my brain is exhaused,
> and always screwed things up, very very sorry about that.
>

Mistakes happen.
This is built into the process.
This will not be the first time that a fix patch is also a regression.
Sometimes its detected on the same day and sometimes weeks later...

Thanks,
Amir.