On 2026/1/10 18:48, Amir Goldstein wrote:
On Sat, Jan 10, 2026 at 11:30 AM Gao Xiang <[email protected]> wrote:
Hi Amir,
On 2026/1/10 17:50, Amir Goldstein wrote:
On Sat, Jan 10, 2026 at 8:27 AM Gao Xiang <[email protected]> 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/[email protected]
Hopefully it's the end of the disaster.
Thanks,
Gao Xiang
Thanks,
Amir.
