Re: [REGRESSION] erofs: new file-backed stacking limit breaks container overlay use case in 6.12.63

[Gao Xiang <hsiangkao@linux.alibaba.com>]

Hi Alekséi,

On 2025/12/26 20:17, Alekséi Naidénov wrote:
> Hello,
> 
> I am reporting a regression in the 6.12 stable series related to EROFS
> file-backed mounts.
> 
> After updating from Linux 6.12.62 to 6.12.63, a previously working setup
> using OSTree-backed composefs mounts as Podman rootfs no longer works.
> 
> The regression appears to be caused by the following commit:
> 
>    34447aeedbaea8f9aad3da5b07030a1c0e124639 ("erofs: limit the level of fs
> stacking for file-backed mounts")
>    (backport of upstream commit d53cd891f0e4311889349fff3a784dc552f814b9)
> 
> ## Setup description
> 
> We use OSTree to materialize filesystem trees, which are mounted via
> composefs (EROFS + overlayfs) as a read-only filesystem. This mounted
> composefs tree is then used as a Podman rootfs, with Podman mounting a
> writable overlayfs on top for each container.
> 
> This setup worked correctly on Linux 6.12.62 and earlier.

The following issue just tracks this:
https://github.com/coreos/fedora-coreos-tracker/issues/2087

I don't think more information is needed, but I really think the EROFS
commit is needed to avoid kernel stack overflow due to nested fses.

> 
> In short, the stacking looks like:
> 
>    EROFS (file-backed)
>      -> composefs (EROFS + overlayfs with ostree repo as datadir, read-only)
>          -> Podman rootfs overlays (RW upperdir)
> 
> There is no recursive or self-stacking of EROFS.
Yes, but there are two overlayfs + one file-backed EROFS already, and
it exceeds FILESYSTEM_MAX_STACK_DEPTH.

That is overlayfs refuses to mount the nested fses.

Thanks,
Gao Xiang