Re: [PATCH v2] erofs: use dedicated meta inodes for file-backed mounts

[Gao Xiang <xiang@kernel.org>]

Hi Christoph,

On Tue, Aug 25, 2026 at 09:44:03PM -0700, Christoph Hellwig wrote:
> On Thu, Aug 20, 2026 at 09:40:46PM +0800, Gao Xiang wrote:
> > Hi Christoph,
> > 
> > On Tue, Aug 18, 2026 at 10:55:47PM -0700, Christoph Hellwig wrote:
> > > On Tue, Aug 11, 2026 at 05:07:17PM +0800, Gao Xiang wrote:
> > > > access on file-backed mounts (although I still don't think it is
> > > > necessary due to the EROFS immutable model). As the result, metadata
> > > > cache won't use the page cache of backing inodes anymore.
> > > > 
> > > > The "managed cache" was originally used to cache physical compressed
> > > > data according to the current cache strategy and I/O patterns; since
> > > > file-backed mounts also need to access physical data for metadata
> > > > access, it's natural to reuse the managed cache for this too, providing
> > > > a unique inode for all physical data access.
> > > 
> > > This look sane.  Any reason to not use the meta inode unconditionally
> > > to simplify the code?
> > 
> > I guess you meant avoid using bd_inode page cache?
> 
> 
> Yes.
> 
> > I'm not sure if it simplifies a lot, also like fadvise(WILLNEED) to blkdev
> > can perform to bd_inode too so I think it can still have some benefits.
> 
> This is actually an artefact of why using the bdev page cache is a bad
> idea, because it opens your metadata cache up to external modification
> and side channel attacks.

See my reply to Christian before:
https://lore.kernel.org/r/95a5fc3a-4259-44a7-bb72-8ff35a49a26f@linux.alibaba.com

EROFS is unlike generic writable filesystems which need to consider
writing to the disk and keep various cache (extent cache, ...) and
complex metadata relationship.

EROFS itself is only designed for archive use cases (like tar/zip),
and it never changes its data and metadata itself at runtime, and it
intentionally only uses the physical view as the unique metadata
cache (never duplicate a different form of in-memory metadata
cache) by design.  For unexpected external modification, it generally
behaves undefined (nevertheless, the physical device can be modified
in various ways).  In short, our implementation is always designed
to harden and tolerate this so it won't cause severe in-memory <->
on-disk or on-disk <-> on-disk inconsistency.

You could doubt that, but here I claim again that one of EROFS main
ondisk/runtime design goals (which is very unlike to other generic
filesystems, and that is one of EROFS's main value), for human-made
random implementation bugs, we will fix them all after reported since
the implementation bug cannot be totally avoidable from an engineering
perspective (unless the implementation is totally auto code generated.)

For side channel attack, the Linux page cache model is always vulnerable
to that, and I really think it's a trade-off (for shared kernel
apporaches, cache side channel attack is unavoidable and no need to
avoid; if you need a strongest protection, you should use isolated kernels
or seperate VM instead.)

We could switch to use per-fs metadata cache, but in that way, we have to
develop a new way to warm up the cache instead, I guess in that way it
will be much like switched into an EROFS-specific ioctl interface instead
since fadvise no longer works.

> 
> > I think bd_inode page cache can be used for filesystems so maybe leave it
> > as-is for now, or maybe a follow-up work if it's really needed.
> 
> That's how it has historically been done.  We generally try to avoid
> it for newer designs.

TR;DR: I will switch later when I find another slot, but it should just
based on a fact is that bd_inode page cache is deprecated in the long
term simply.

Thanks,
Gao Xiang

> 
>