Re: [PATCH] erofs: reuse superblock for file-backed mounts

On Fri, Jul 31, 2026 at 03:19:58PM +0200, Giuseppe Scrivano wrote:
> Christian Brauner <[email protected]> writes:
> 
> >> >>> The time difference shows that sharing the superblock also benefits
> >> >>> the page cache and inode cache, as subsequent mounts of the same image
> >> >>> avoid re-reading the backing file.  This is particularly useful for
> >> >>> container hosts running multiple containers from the same base image.
> >> >>
> >> >> Doesn't this approach break-down as soon as you get to change SB flags (through
> >> >> e.g mount -o remount)? It will change superblock flags for all of them, right?
> >> >>
> >> >> (I don't think you can switch off the superblock transparently on a
> >> >> reconfigure?)
> >> >
> >> > This is the same preexisting behavior for block device mounts.  That
> >
> > Yeah, and it sucks ass. :)
> > Only an incompatible vfs-level RO/RW property causes a silent reuse to
> > fail. Otherwise it not possible to detect that a superblock has been
> > created and requested mount options silently ignore.
> >
> > In other words, doing this unconditionally is incompatible with current
> > userspace.
> >
> > Btw, I added FSCONFIG_CMD_CREATE_EXCL for this reason which refuses to
> > reuse an existing superblock for filesystems that would otherwise end up
> > sharing a superblock. This way userspace is guaranteed to not silently
> > get filesystem options ignored.
> >
> >> > said, I realize this can feel confusing since EROFS is not a block
> >> > device and allowed this so far.
> >> >
> >> > One way to solve this could be an explicit mount option "share_sb" that
> >> > is opt-in and, once set, blocks any remount operations.  Would that
> >> > work?
> >> 
> >> Would something like the following fixup on top of the previous patch be
> >> acceptable (suggestions for better names are welcome)?
> >
> > The patch as written still means that a task A creates a new erofs mount
> > with for file F and marks it as shared. Another task B creates new erofs
> > mount expecting to get a new superblock and will end up sharing it with
> > task A instead.
> >
> > That is still quite the behavior change and could be used to subvert
> > workloads expectations and be used in (odd) attacks.
> 
> no, my suggestion is that task B gets the same superblock created by A
> only if it also specifies share_sb.

Yeah, that works.

> If the option is not specified, as is the case for existing workloads,
> then it gets a new superblock even if A is already mounted with
> share_sb.

Sounds good! Ship it.