)]}'
{
  "commit": "072a7c7cdbea4f91df854ee2bb216256cd619f2a",
  "tree": "aab8613a5bbfd7a1c0fe8e8273a81599000fb2b5",
  "parents": [
    "f8f9c1f4d0c7a64600e2ca312dec824a0bc2f1da"
  ],
  "author": {
    "name": "Gao Xiang",
    "email": "hsiangkao@linux.alibaba.com",
    "time": "Thu Jan 08 10:38:31 2026 +0800"
  },
  "committer": {
    "name": "Gao Xiang",
    "email": "hsiangkao@linux.alibaba.com",
    "time": "Sat Jan 10 13:01:15 2026 +0800"
  },
  "message": "erofs: don\u0027t bother with s_stack_depth increasing for now\n\nPreviously, commit d53cd891f0e4 (\"erofs: limit the level of fs stacking\nfor file-backed mounts\") bumped `s_stack_depth` by one to avoid kernel\nstack overflow when stacking an unlimited number of EROFS on top of\neach other.\n\nThis fix breaks composefs mounts, which need EROFS+ovl^2 sometimes\n(and such setups are already used in production for quite a long time).\n\nOne way to fix this regression is to bump FILESYSTEM_MAX_STACK_DEPTH\nfrom 2 to 3, but proving that this is safe in general is a high bar.\n\nAfter a long discussion on GitHub issues [1] about possible solutions,\none conclusion is that there is no need to support nesting file-backed\nEROFS mounts on stacked filesystems, because there is always the option\nto use loopback devices as a fallback.\n\nAs a quick fix for the composefs regression for this cycle, instead of\nbumping `s_stack_depth` for file backed EROFS mounts, we disallow\nnesting file-backed EROFS over EROFS and over filesystems with\n`s_stack_depth` \u003e 0.\n\nThis works for all known file-backed mount use cases (composefs,\ncontainerd, and Android APEX for some Android vendors), and the fix is\nself-contained.\n\nEssentially, we are allowing one extra unaccounted fs stacking level of\nEROFS below stacking filesystems, but EROFS can only be used in the read\npath (i.e. overlayfs lower layers), which typically has much lower stack\nusage than the write path.\n\nWe can consider increasing FILESYSTEM_MAX_STACK_DEPTH later, after more\nstack usage analysis or using alternative approaches, such as splitting\nthe `s_stack_depth` limitation according to different combinations of\nstacking.\n\nFixes: d53cd891f0e4 (\"erofs: limit the level of fs stacking for file-backed mounts\")\nReported-and-tested-by: Dusty Mabe \u003cdusty@dustymabe.com\u003e\nReported-by: Timothée Ravier \u003ctim@siosm.fr\u003e\nCloses: https://github.com/coreos/fedora-coreos-tracker/issues/2087 [1]\nReported-by: \"Alekséi Naidénov\" \u003can@digitaltide.io\u003e\nCloses: https://lore.kernel.org/r/CAFHtUiYv4+\u003d+JP_-JjARWjo6OwcvBj1wtYN\u003dz0QXwCpec9sXtg@mail.gmail.com\nAcked-by: Amir Goldstein \u003camir73il@gmail.com\u003e\nAcked-by: Alexander Larsson \u003calexl@redhat.com\u003e\nReviewed-and-tested-by: Sheng Yong \u003cshengyong1@xiaomi.com\u003e\nReviewed-by: Zhiguo Niu \u003czhiguo.niu@unisoc.com\u003e\nReviewed-by: Chao Yu \u003cchao@kernel.org\u003e\nCc: Christian Brauner \u003cbrauner@kernel.org\u003e\nCc: Miklos Szeredi \u003cmszeredi@redhat.com\u003e\nSigned-off-by: Gao Xiang \u003chsiangkao@linux.alibaba.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "937a215f626c1ccaa5071f13ba70809b1e2ab0ee",
      "old_mode": 33188,
      "old_path": "fs/erofs/super.c",
      "new_id": "e93264034b5db662eff357a380369a2b19aff52e",
      "new_mode": 33188,
      "new_path": "fs/erofs/super.c"
    }
  ]
}