From: David Laight <david.laight.linux@gmail.com>
To: Gao Xiang <hsiangkao@linux.alibaba.com>
Cc: "Amir Goldstein" <amir73il@gmail.com>,
"Sheng Yong" <shengyong2021@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
"Dusty Mabe" <dusty@dustymabe.com>,
"Timothée Ravier" <tim@siosm.fr>,
"Alekséi Naidénov" <an@digitaltide.io>,
"Alexander Larsson" <alexl@redhat.com>,
"Christian Brauner" <brauner@kernel.org>,
"Miklos Szeredi" <mszeredi@redhat.com>,
"Zhiguo Niu" <niuzhiguo84@gmail.com>,
shengyong1@xiaomi.com,
"linux-erofs mailing list" <linux-erofs@lists.ozlabs.org>
Subject: Re: [PATCH v2] erofs: don't bother with s_stack_depth increasing for now
Date: Thu, 8 Jan 2026 10:26:13 +0000 [thread overview]
Message-ID: <20260108102613.33bbc6d4@pumpkin> (raw)
In-Reply-To: <4b427f6f-3b26-4dc8-bf6f-79eeabf6ba84@linux.alibaba.com>
On Thu, 8 Jan 2026 16:05:03 +0800
Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
> Hi Amir,
>
> On 2026/1/8 16:02, Amir Goldstein wrote:
> > On Thu, Jan 8, 2026 at 4:10 AM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>
> ...
>
> >>>>
> >>>> Hi, Xiang
> >>>>
> >>>> In Android APEX scenario, apex images formatted as EROFS are packed in
> >>>> system.img which is also EROFS format. As a result, it will always fail
> >>>> to do APEX-file-backed mount since `inode->i_sb->s_op == &erofs_sops'
> >>>> is true.
> >>>> Any thoughts to handle such scenario?
> >>>
> >>> Sorry, I forgot this popular case, I think it can be simply resolved
> >>> by the following diff:
> >>>
> >>> diff --git a/fs/erofs/super.c b/fs/erofs/super.c
> >>> index 0cf41ed7ced8..e93264034b5d 100644
> >>> --- a/fs/erofs/super.c
> >>> +++ b/fs/erofs/super.c
> >>> @@ -655,7 +655,7 @@ 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 ||
> >>> + if ((inode->i_sb->s_op == &erofs_sops && !sb->s_bdev) ||
> >>
> >> Sorry it should be `!inode->i_sb->s_bdev`, I've
> >> fixed it in v3 RESEND:
> >
> > A RESEND implies no changes since v3, so this is bad practice.
> >
> >> https://lore.kernel.org/r/20260108030709.3305545-1-hsiangkao@linux.alibaba.com
> >>
> >
> > Ouch! If the erofs maintainer got this condition wrong... twice...
> > Maybe better using the helper instead of open coding this non trivial check?
> >
> > if ((inode->i_sb->s_op == &erofs_sops &&
> > erofs_is_fileio_mode(EROFS_I_SB(inode)))
>
> I was thought to use that, but it excludes fscache as the
> backing fs.. so I suggest to use !s_bdev directly to
> cover both file-backed mounts and fscache cases directly.
Is it worth just allocating each fs a 'stack needed' value and then
allowing the mount if the total is low enough.
This is equivalent to counting the recursion depth, but lets erofs only
add (say) 0.5.
Ideally you'd want to do static analysis to find the value to add,
but 'inspired guesswork' is probably good enough.
Isn't there also a big difference between recursive mounts (which need
to do read/write on the underlying file) and overlay mounts (which just
pass the request onto the lower filesystem).
David
>
> Thanks,
> Gao Xiang
>
> >
> > Thanks,
> > Amir.
>
>
next prev parent reply other threads:[~2026-01-08 12:13 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20251231204225.2752893-1-hsiangkao@linux.alibaba.com>
[not found] ` <CAOQ4uxjjxUHr3Tkxo9PkrBUPcYG1C309cYA9EEvk1-oVGcV_Og@mail.gmail.com>
[not found] ` <18246672-2c4f-415e-8667-2f826eb4fe19@linux.alibaba.com>
2026-01-04 10:01 ` [PATCH] erofs: don't bother with s_stack_depth increasing for now Amir Goldstein
2026-01-04 10:42 ` Gao Xiang
2026-01-04 18:44 ` Amir Goldstein
2026-01-04 21:14 ` Gao Xiang
2026-01-06 17:05 ` [PATCH v2] " Gao Xiang
2026-01-07 14:11 ` Dusty Mabe
2026-01-08 2:26 ` Sheng Yong
2026-01-08 2:32 ` Gao Xiang
2026-01-08 3:10 ` Gao Xiang
2026-01-08 8:02 ` Amir Goldstein
2026-01-08 8:05 ` Gao Xiang
2026-01-08 8:24 ` Amir Goldstein
2026-01-08 8:34 ` Gao Xiang
2026-01-08 10:26 ` David Laight [this message]
2026-01-08 12:30 ` Gao Xiang
2026-01-08 2:38 ` [PATCH v3] " Gao Xiang
2026-01-08 3:07 ` [PATCH v3 RESEND] " Gao Xiang
2026-01-08 9:14 ` Sheng Yong
2026-01-08 9:25 ` Gao Xiang
2026-01-08 9:30 ` Sheng Yong
2026-01-08 9:28 ` Zhiguo Niu
2026-01-08 9:31 ` Gao Xiang
2026-01-10 1:45 ` Chao Yu
2026-01-12 12:46 ` Christian Brauner
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=20260108102613.33bbc6d4@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=alexl@redhat.com \
--cc=amir73il@gmail.com \
--cc=an@digitaltide.io \
--cc=brauner@kernel.org \
--cc=dusty@dustymabe.com \
--cc=hsiangkao@linux.alibaba.com \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mszeredi@redhat.com \
--cc=niuzhiguo84@gmail.com \
--cc=shengyong1@xiaomi.com \
--cc=shengyong2021@gmail.com \
--cc=tim@siosm.fr \
/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