erofs fix for 6.19-rc5

GIT PULL In review Gao Xiang 5 participants 10 messages Jan 10 – Jan 11 EROFS file system

lore

Share & tools

lore

Gao Xiang

author maintainer

2026-01-10 05:24 UTC #0 lore raw

Hi Linus,

Could you consider this urgent fix for 6.19-rc5?

Actually upstream commit d53cd891f0e4 ("erofs: limit the level of fs stacking for file-backed mounts") causes composefs regressions since EROFS + ovl^2 cannot be mounted properly anymore and we all agree to land this band-aid fix as the first step.

The more backgound details are shown in the commit message.

Thanks,
Gao Xiang

The following changes since commit f8f9c1f4d0c7a64600e2ca312dec824a0bc2f1da:

Linux 6.19-rc3 (2025-12-28 13:24:26 -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

for you to fetch changes up to 072a7c7cdbea4f91df854ee2bb216256cd619f2a:

erofs: don't bother with s_stack_depth increasing for now (2026-01-10 13:01:15 +0800)

----------------------------------------------------------------
Change since last update:

- Don't bother with s_stack_depth increasing to band-aid regressions in some composefs mount setups (EROFS + ovl^2)

----------------------------------------------------------------
Gao Xiang (1):
erofs: don't bother with s_stack_depth increasing for now

 fs/erofs/super.c | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

[email protected]

merge bot Merged

2026-01-10 06:04 UTC #1 lore raw

The pull request you sent on Sat, 10 Jan 2026 13:23:56 +0800:

Quoted 1 line

git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs.git tags/erofs-for-6.19-rc5-fixes

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b6151c4e60e5f695fac8b5c3e011cfcfd6e27cba

Thank you!

Signature · 2 lines

Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Gao Xiang

author maintainer

2026-01-10 07:27 UTC #2 lore raw

[GIT PULL] erofs fix for 6.19-rc5 (fix the stupid mistake)

In reply to Gao Xiang

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]

 fs/erofs/super.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Amir Goldstein

2026-01-10 09:50 UTC #3 lore raw

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

Quoted 33 lines · Gao Xiang

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

Quoted 8 lines

- 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.

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.

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.

Thanks,
Amir.

[1] https://lore.kernel.org/linux-fsdevel/[email protected]/

Gao Xiang

2026-01-10 10:30 UTC #4 lore raw

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

Hi Amir,

Quoted 43 lines · Amir Goldstein

Quoted 33 lines · Gao Xiang
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
Quoted 8 lines
- 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]

Quoted 3 lines

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.

Quoted 3 lines

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.

Quoted 6 lines

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.

Thanks,
Gao Xiang

Quoted 5 lines

Thanks,
Amir.
[1] https://lore.kernel.org/linux-fsdevel/[email protected]/

Amir Goldstein

2026-01-10 10:48 UTC #5 lore raw

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

Quoted 49 lines · Gao Xiang

Hi Amir,
Quoted 45 lines · Amir Goldstein
Quoted 33 lines · Gao Xiang
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
Quoted 8 lines
- 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,

Quoted 8 lines

Quoted 1 line
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.

Quoted 7 lines

Quoted 3 lines
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.

Quoted 20 lines

Quoted 6 lines
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)) {
(quoted diff) +2 -4
-                       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.

Quoted 8 lines

+ 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.

Gao Xiang

2026-01-10 11:54 UTC #6 lore raw

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

Quoted 65 lines · Amir Goldstein

Quoted 49 lines · Gao Xiang
Hi Amir,
Quoted 45 lines · Amir Goldstein
Quoted 33 lines · Gao Xiang
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
Quoted 8 lines
- 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,
Quoted 8 lines
Quoted 1 line
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.
Quoted 4 lines
Quoted 3 lines
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.

Quoted 6 lines

Quoted 3 lines
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.

Quoted 26 lines

Quoted 26 lines
Quoted 7 lines
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)) {
(quoted diff) +2 -4
-                       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.

Quoted 8 lines

Quoted 3 lines
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

Quoted 3 lines

Thanks,
Amir.

Gao Xiang

2026-01-10 11:47 UTC #7 lore raw

PATCH 1/1 erofs: fix file-backed mounts no longer working on EROFS partitions

In reply to Amir Goldstein

Sheng Yong reported [1] that Android APEX images didn't work with [PATCH v2] of upstream commit 072a7c7cdbea ("erofs: don't bother with s_stack_depth increasing for now") because "EROFS-formatted APEX file images can be stored within an EROFS-formatted Android system partition."

In response, I sent a quick fat-fingered [PATCH v3] to address the report. Unfortunately, the updated condition was incorrect:

         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) ||
+ inode->i_sb->s_stack_depth) {

The condition !sb->s_bdev is always true for all file-backed EROFS mounts, making the check effectively a no-op.

The real fix tested and confirmed by Sheng Yong [2] at that time was [PATCH v3 RESEND], which correctly ensures the following EROFS^2 setup works:
EROFS (on a block device) + EROFS (file-backed mount)

But sadly I screwed it up again by upstreaming the outdated [PATCH v3] and I should be blamed.

This patch applies the same logic as the delta between the upstream [PATCH v3] and the real fix [PATCH v3 RESEND].

Reported-by Sheng Yong <[email protected]>

Closes https://lore.kernel.org/r/[email protected] [1] open here

Fixes 072a7c7cdbea ("erofs: don't bother with s_stack_depth increasing for now")

Link https://lore.kernel.org/r/[email protected] [2] open here

Signed-off-by Gao Xiang <[email protected]>

---
Hi Linus,

As suggested by Amir, I send out the patch to fix the broken fix.

If possible, could you help apply this patch directly?

If you perfer another pull request I will do later too after a sleep, but I guess I will just repeat my stupid mistake again in the pull request and the tag message.

Thanks,
Gao Xiang

 fs/erofs/super.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

fs/erofs/super.c +2 -1

index e93264034b5d..5136cda5972a 100644
@@ -655,7 +655,8 @@ static int erofs_fc_fill_super(struct super_block *sb, struct fs_context *fc)
 		 */
 		if (erofs_is_fileio_mode(sbi)) {
 			inode = file_inode(sbi->dif0.file);
-			if ((inode->i_sb->s_op == &erofs_sops && !sb->s_bdev) ||
+			if ((inode->i_sb->s_op == &erofs_sops &&
+			     !inode->i_sb->s_bdev) ||
 			    inode->i_sb->s_stack_depth) {
 				erofs_err(sb, "file-backed mounts cannot be applied to stacked fses");
 				return -ENOTBLK;

Signature · 1 line

2.43.5

Linus Torvalds

2026-01-10 16:42 UTC #8 lore raw

Re: [PATCH] erofs: fix file-backed mounts no longer working on EROFS partitions

Quoted 3 lines · Gao Xiang

But sadly I screwed it up again by upstreaming the outdated [PATCH v3] and I should be blamed.

No need to be quite that harsh on yourself. Mistakes happen, and this one was fixed very quickly.

Patch applied. Thanks,

Linus

Gao Xiang

2026-01-11 00:01 UTC #9 lore raw

Re: [PATCH] erofs: fix file-backed mounts no longer working on EROFS partitions

Quoted 9 lines · Linus Torvalds

Quoted 3 lines · Gao Xiang
But sadly I screwed it up again by upstreaming the outdated [PATCH v3] and I should be blamed.
No need to be quite that harsh on yourself. Mistakes happen, and this one was fixed very quickly.
Patch applied. Thanks,

Okay, thanks very much too.

Thanks,
Gao Xiang

Quoted 2 lines

Linus