From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5E2A41CAA4 for ; Fri, 26 Dec 2025 12:35:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766752522; cv=none; b=WVm3qo321wFb3BxL3VgeLQkgv3qkC7vlA6kMVsFRvrAXDW2wUpL4H2gzADMU3kSGE8p9a5iPUA7ALhIc8jJYF8/uc2jXuwuF6VUoKd6fjtG4keVaWZ8YAyscXbLuUdyMEQTfiykrpynJAhx4VNKFdviY4wW7ebOGXHiq9DiYrX8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766752522; c=relaxed/simple; bh=0rJ95WY4LkO1lS96o4vxvfUz6Rz7lIC7caKrw4+SpCE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=qVxmv8FV2KrxCrnPgQb14U7KlS6ujXEvEGheLSJrMzCNgwU0+fIWpfyHmag0X+h3MkVri1snx+3vBLyu0dGJbyC6mWEyJ0cZ+Z34O2sSZMdN/FvZdsblsPMuWxn/MloqmpDZhXwY8gTG522iA7ovCI6AaAGP2G6tCml6Kgjz0L0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=digitaltide.io; spf=pass smtp.mailfrom=itoolabs.com; dkim=pass (2048-bit key) header.d=itoolabs-com.20230601.gappssmtp.com header.i=@itoolabs-com.20230601.gappssmtp.com header.b=a2PDBHUx; arc=none smtp.client-ip=209.85.128.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=digitaltide.io Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=itoolabs.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=itoolabs-com.20230601.gappssmtp.com header.i=@itoolabs-com.20230601.gappssmtp.com header.b="a2PDBHUx" Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-477563e28a3so44421185e9.1 for ; Fri, 26 Dec 2025 04:35:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itoolabs-com.20230601.gappssmtp.com; s=20230601; t=1766752517; x=1767357317; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=V6tRdcuP0wqKPHELS2CPAX3klPxKMBxEEEHLvH3w9ao=; b=a2PDBHUxtKLEZJWp1kq+GQjQALJpdiAewwf+3uhkn+pESggN3cH631r+4tg7xOk74r KdbQU1YFjGvnDVc/lUIomXONO7l4j5F7ebfk7gvGALKp6kfvFPziT3DoaUoQZtcJP7+4 0SfPVvCRRErnM8PU1n81W6hbNOokhUzcwICcyppjlJ/Uwgkcpg2ZKZlkD5LKEajayrpq MkH07NwJ+122DH0u0IvRy7VV14Kc7rf6BgO4Nb3Jl+mQqcELatGBlDWP9H9Ey5DhZuS/ KhEuaSHAGRffN00sKLmw89TwWnFoMfGwpvp+/iCZMJnIJf3p6UCMhy6AhLphXX7gbw+x jwRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766752517; x=1767357317; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=V6tRdcuP0wqKPHELS2CPAX3klPxKMBxEEEHLvH3w9ao=; b=Qth0300KNfa5HnKch0dubTRPON9kY0B4mhDDiU6POiL5Jmn1wZFlDbxpDGAbMElGWn B9MaKdZb4dV50q7y7S4G3ac/dPT6mRxPYtm8Xj8DumQBOeS+/kG/JngNhRRu9K4xSlf6 //iQlglTbi6v2mLFFdYwgceMWCNlfce/KyfNDLTxI5ID93nmS7PiSepgbLVoNtrEtfCp jqPRhtXd8BqEV7Rc8vpa9g80ipS1msflZ3kNp9WSxuZio+vucApEL6nF5tyitOVyNjzc NFyOByPB3XsbzMK7poxcYX7ZG2QCw5Kt+blxzypvizzzlt76xh+r5vVjXXVh4uwmOx0f Chtw== X-Forwarded-Encrypted: i=1; AJvYcCU3LUCVNsguCjMSzj/mqODW/d3GhgPwRjr4EP7ps4EuUF0huFGpY82WlTNxtMUz779bSOoYhNM92hQ4xJU=@vger.kernel.org X-Gm-Message-State: AOJu0Yx/X/Jgr5EP6cX+ahYnmpPA3xb4x5neu6pIFF+sk0mAYbmQS3+E Rn8v9JZzHN31zzeToxq6Ps+eXrz99qKAW6KENAo72b5hhJrIvBrM14+upIm8WnsZE1M= X-Gm-Gg: AY/fxX5ugCGR4egk/xswLASdOfzQ8NTQ8OnMSecv89MrryYJsKcvvg4uz0UI9R6eOMn gFcnZRShKRXZmOAEyN2gEM95Svk9nLI5R+PVyPocQNKHDTlIVSGabBwG9U6cEWdm/lTXwuCOPe+ XCrCTApAFhFbfV6W8ArXLAx4m8djMp/x48oknH2eghjlppTxVkL8EtuT3YXViyNSIblSfvwzMjU 4oRjFdh/cmHHUN4L5Pa/SDq2PsnMMCVzoBN98XKj8iKDjyxAf6OgC+kItY2Hs/Kiy/IN7OBb3s/ jtftFoeWesYajiPmh1epjyFTgEsWmcghJYC9q4gD1NW/qpoyzokL2Asp/wHiYTBU0HZx5V29pSM 1z4Ni5nS6kITHL0fUl3r0c2m6b4a8jKRDofOzl5wMMPajCod7xArQ+T7iVQwqDkbJ5fRbZDQzBA hUL1geJLA= X-Google-Smtp-Source: AGHT+IGpcB6fzs67bzB42F3nEfa7jC6d98MoCdt0ERV86bPdMf/lMarUyr6A03ZLX3YHQkzarY7wEw== X-Received: by 2002:a7b:c454:0:b0:477:7588:c8cc with SMTP id 5b1f17b1804b1-47be29adacbmr184783165e9.7.1766752517546; Fri, 26 Dec 2025 04:35:17 -0800 (PST) Received: from gamestation ([188.26.196.207]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47be272e46fsm432931215e9.4.2025.12.26.04.35.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Dec 2025 04:35:17 -0800 (PST) From: =?UTF-8?q?Aleks=C3=A9i=20Naid=C3=A9nov?= To: stable@vger.kernel.org Cc: linux-erofs@lists.ozlabs.org, linux-kernel@vger.kernel.org, xiang@kernel.org Subject: [REGRESSION] erofs: new file-backed stacking limit breaks container overlay use case in 6.12.63 Date: Fri, 26 Dec 2025 13:34:37 +0100 Message-ID: <20251226123453.5914-1-an@digitaltide.io> X-Mailer: git-send-email 2.51.2 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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. 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. ## Working case (6.12.62) The composefs mount exists and Podman can successfully start a container using it as rootfs. Example composefs mount: ❯ mount | grep a31550cc69eef0e3227fa700623250592711fdfd51b5403a74288b55e89e7e8c a31550cc69eef0e3227fa700623250592711fdfd51b5403a74288b55e89e7e8c on /home/growler/.local/share/containers/ostree/a31550cc69eef0e3227fa700623250592711fdfd51b5403a74288b55e89e7e8c type overlay (ro,noatime,lowerdir+=/proc/self/fd/10,datadir+=/proc/self/fd/7,redirect_dir=on,metacopy=on) (lowedir is a handle for the erofs file-backed mount, datadir is a handle for the ostree repository objects directory) Running Podman: ❯ podman run --rm -it --rootfs $HOME/.local/share/containers/ostree/a31550cc69eef0e3227fa700623250592711fdfd51b5403a74288b55e89e7e8c:O bash -l root@d691e785bba3:/# uname -a Linux d691e785bba3 6.12.62 #1-NixOS SMP PREEMPT_DYNAMIC Fri Dec 12 17:37:22 UTC 2025 x86_64 GNU/Linux root@d691e785bba3:/# (succeed) ## Failing case (6.12.63) After upgrading to 6.12.63, the same command fails when Podman tries to create the writable overlay on top of the composefs mount. Error: ❯ podman run --rm -it --rootfs $HOME/.local/share/containers/ostree/a31550cc69eef0e3227fa700623250592711fdfd51b5403a74288b55e89e7e8c:O bash -l Error: rootfs-overlay: creating overlay failed "/home/growler/.local/share/containers/ostree/a31550cc69eef0e3227fa700623250592711fdfd51b5403a74288b55e89e7e8c" from native overlay: mount overlay:/home/growler/.local/share/containers/storage/overlay-containers/a0851294d6b5b18062d4f5316032ee84d7bae700ea7d12c5be949d9e1999b0a1/rootfs/merge, flags: 0x4, data: lowerdir=/home/growler/.local/share/containers/ostree/a31550cc69eef0e3227fa700623250592711fdfd51b5403a74288b55e89e7e8c,upperdir=/home/growler/.local/share/containers/storage/overlay-containers/a0851294d6b5b18062d4f5316032ee84d7bae700ea7d12c5be949d9e1999b0a1/rootfs/upper,workdir=/home/growler/.local/share/containers/storage/overlay-containers/a0851294d6b5b18062d4f5316032ee84d7bae700ea7d12c5be949d9e1999b0a1/rootfs/work,userxattr: invalid argument ❯ uname -a Linux ci-node-09 6.12.63 #1-NixOS SMP PREEMPT_DYNAMIC Thu Dec 18 12:55:23 UTC 2025 x86_64 GNU/Linux ## Expected behavior Using a composefs (EROFS + overlayfs) read-only mount as the lowerdir for a container rootfs overlay should continue to work as it did in 6.12.62. ## Actual behavior Overlayfs mounting fails with EINVAL when stacking on top of the composefs mount backed by EROFS. ## Notes The setup does not involve recursive EROFS mounting or unbounded stacking depth. It appears the new stacking limit rejects this valid and previously supported container use case. Please let me know if further details or testing would be helpful. Thank you, -- Alekséi Nadénov