[GIT PULL] erofs fix for 6.19-rc5

[GIT PULL] erofs fix for 6.19-rc5

[Gao Xiang]

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(-)

Re: [GIT PULL] erofs fix for 6.19-rc5

[pr-tracker-bot]

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

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

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

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

[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(-)

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

[Amir Goldstein]

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.

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/243f57b8-246f-47e7-9fb1-27a771e8e9e8@gmail.com/

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

[Gao Xiang]

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.

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

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

> 
> Thanks,
> Amir.
> 
> [1] https://lore.kernel.org/linux-fsdevel/243f57b8-246f-47e7-9fb1-27a771e8e9e8@gmail.com/

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

[Amir Goldstein]

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.

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

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

[Gao Xiang]

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.

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

[Gao Xiang]

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 <shengyong1@xiaomi.com>
Closes: https://lore.kernel.org/r/3acec686-4020-4609-aee4-5dae7b9b0093@gmail.com [1]
Fixes: 072a7c7cdbea ("erofs: don't bother with s_stack_depth increasing for now")
Link: https://lore.kernel.org/r/243f57b8-246f-47e7-9fb1-27a771e8e9e8@gmail.com [2]
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
---
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(-)

diff --git a/fs/erofs/super.c b/fs/erofs/super.c
index e93264034b5d..5136cda5972a 100644
--- a/fs/erofs/super.c
+++ b/fs/erofs/super.c
@@ -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;
-- 
2.43.5

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

[Linus Torvalds]

On Sat, 10 Jan 2026 at 01:47, Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>
> 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

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

[Gao Xiang]

On 2026/1/11 00:42, Linus Torvalds wrote:
> On Sat, 10 Jan 2026 at 01:47, Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>>
>> 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

> 
>              Linus