From: Gao Xiang <hsiangkao@linux.alibaba.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
linux-erofs@lists.ozlabs.org, LKML <linux-kernel@vger.kernel.org>,
Alexander Larsson <alexl@redhat.com>,
Dusty Mabe <dusty@dustymabe.com>, Chao Yu <chao@kernel.org>,
Sheng Yong <shengyong1@xiaomi.com>,
Zhiguo Niu <zhiguo.niu@unisoc.com>,
Christian Brauner <brauner@kernel.org>,
Miklos Szeredi <mszeredi@redhat.com>,
Gao Xiang <xiang@kernel.org>
Subject: Re: [GIT PULL] erofs fix for 6.19-rc5 (fix the stupid mistake)
Date: Sat, 10 Jan 2026 19:54:29 +0800 [thread overview]
Message-ID: <fba595da-9bd9-42c6-8b1d-1511feafda14@linux.alibaba.com> (raw)
In-Reply-To: <CAOQ4uxi99wRKca1M-tvgb5SrhcuK=R_8q9nYRsf=CxLOTtU5Og@mail.gmail.com>
On 2026/1/10 18:48, Amir Goldstein wrote:
> On Sat, Jan 10, 2026 at 11:30 AM Gao Xiang <hsiangkao@linux.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@kernel.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.
For stable kernels, Yes.
But there could be customized downstream kernels, yet I totally
agree with you, "revert + patch with same title" won't be better
in any aspect.
>
>>>
>>> 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...
I've sent out a delta fix:
https://lore.kernel.org/r/20260110114703.3461706-1-hsiangkao@linux.alibaba.com
Hopefully it's the end of the disaster.
Thanks,
Gao Xiang
>
> Thanks,
> Amir.
next prev parent reply other threads:[~2026-01-10 11:54 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-10 5:23 [GIT PULL] erofs fix for 6.19-rc5 Gao Xiang
2026-01-10 6:01 ` pr-tracker-bot
2026-01-10 7:27 ` [GIT PULL] erofs fix for 6.19-rc5 (fix the stupid mistake) Gao Xiang
2026-01-10 9:50 ` Amir Goldstein
2026-01-10 10:30 ` Gao Xiang
2026-01-10 10:48 ` Amir Goldstein
2026-01-10 11:54 ` Gao Xiang [this message]
2026-01-10 11:47 ` [PATCH] erofs: fix file-backed mounts no longer working on EROFS partitions Gao Xiang
2026-01-10 16:42 ` Linus Torvalds
2026-01-11 0:00 ` Gao Xiang
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=fba595da-9bd9-42c6-8b1d-1511feafda14@linux.alibaba.com \
--to=hsiangkao@linux.alibaba.com \
--cc=alexl@redhat.com \
--cc=amir73il@gmail.com \
--cc=brauner@kernel.org \
--cc=chao@kernel.org \
--cc=dusty@dustymabe.com \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mszeredi@redhat.com \
--cc=shengyong1@xiaomi.com \
--cc=torvalds@linux-foundation.org \
--cc=xiang@kernel.org \
--cc=zhiguo.niu@unisoc.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
all inboxes | Powered by JetHome®