From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 443D9352947 for ; Wed, 7 Jan 2026 14:32:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767796381; cv=none; b=nSw58V35mCf10jbXDXXOBvPXikmbVwu2XydlpnevtwIS4eUiCEBJQNtL14O2GcULS8D34lZWbIAbQ3RE8xTUv8cwx8AftylAo3s/Kf071K1Qy7IwMEVVU4WMze4TYAeTwsyh3SZgpUTl/mzEXQP+tlz9Be+Sp1ah3Y+sjIAcfKo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767796381; c=relaxed/simple; bh=Wnjl40ttGCg9CN2ijL+r0Wql7gNIWvMa8Gy7n9OFABQ=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=blrQSKM7QRF2/xOt2dXnlaFDYX4XDp1sXNYDua5csqzzNaK73JWtoB5306cmm1ZYzDiSF6u8I+FVY4n02BFwSPXw3klpGFXw3B/klZKu2t75NhuXFGm8VTdmEVTwN6QRF8kKDR9OCInfe/LLjgAyGOaIjKA3N1t3Ru/eRsu/xuw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=iozVijpY; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=OiOLabmF; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="iozVijpY"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="OiOLabmF" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1767796378; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=YQ7Tvk+jfBLrINloRAmrmHd+axqfdv1XIyOCIBd2Vd4=; b=iozVijpYRyGLyzXddigug+LcPcN9U5iCIsZ1GhkCTdkMKuXhlfCZjgfbtjvHqSNk/3VUVi ourOAt0WVCna1ExatLbsmWTkSDGM2yKIjkcrti2ACKtAeZZQ4GlIDl443EM+vYAs0d6hdA jy9MMsQdjtp8c9zzuGwbZM7iXjfcUsE= Received: from mail-lf1-f71.google.com (mail-lf1-f71.google.com [209.85.167.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-479-yJ3JHn-kMy-CUbW1qGorJg-1; Wed, 07 Jan 2026 09:32:56 -0500 X-MC-Unique: yJ3JHn-kMy-CUbW1qGorJg-1 X-Mimecast-MFC-AGG-ID: yJ3JHn-kMy-CUbW1qGorJg_1767796375 Received: by mail-lf1-f71.google.com with SMTP id 2adb3069b0e04-59b67b93cf5so1433245e87.0 for ; Wed, 07 Jan 2026 06:32:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1767796375; x=1768401175; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=YQ7Tvk+jfBLrINloRAmrmHd+axqfdv1XIyOCIBd2Vd4=; b=OiOLabmF/ekXICBjUxerRWx1J+E36yAyC/iWCrVeBULWfHIwSTTLJbwoneHeLICFNZ T7V7HuMJGXhyjLa6U9JL1v0i4gW8x/x8GSersneQrX1wOhjiQtqBtI1I/hoWYup1PS2n bt2w9h6YU/vLypg5qq6qGQTxZrvLJgsIxgPfvq3LAexy/6h3cRqhC0ZHqORsvG+cWCFV pBtRPloFC4J7zrgaoqdW3Ulwb1zEtav39pZKFNL/0BY1mO2BXyRm58WFSokLNjM775Uh TiAdm+1AG7ofOLNdr/hhAvDVR1uVXQBRFqvY4i0saeIujO5aGriopdtvyI3mSOnFb3N7 4XSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767796375; x=1768401175; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=YQ7Tvk+jfBLrINloRAmrmHd+axqfdv1XIyOCIBd2Vd4=; b=hz4cYwuZTCtiCRgyi7X9xlaEcLmup3XocPW2MPkmeCJPQOa5Q6TrUJd2e0FK5pDlsg DlsUqKIuwtT04xvD/KKglTGYQSJTpDcSMUPIexegTurccWv0dee25UQoSXDAHuBkI1Xm tbYF1A4NwWUVyxnAHGubC4FDrbIoKWDekG9L9VG+bjZZeeHTe6kbmSxnHCXDppjle0uY 7P/0qyxQkm1trTUowrICR5Ag5a0JmcZMZjvTI7sVSDO2yA3ETEwNA+vHm5t9u6KPgaga xG3lCca6aQegFxErxKv6doV6Nczq30omh7/0vf6XCKm9923oZpUHrgI2BbV3QKLtIuqF XJvg== X-Gm-Message-State: AOJu0YxT7D0vcoV+/jY+D9aAVkWxymM8fXYMVJn+MnOkD2MCZnltF0SB V68OA1IA7wVyAkEFCh8u6iLw2fjf2sphdddr9GUoYUQqCLmGXFpcAHAZtd1qVP9m4YyoOYTQiez MtWVBu/SX/QikVY2NFaub+zQsX3YwyGP4OMOQLUvTzdcGkzpQuH2M+B6tDx0QodFeNQ== X-Gm-Gg: AY/fxX5Q+diyu0ScpmasnrgU+eH5EsEyclDNOWphGoCUzELuzDpnXgD0AdKOTMNi4aD VgJqhAE5JXzNuZ0hWnInaq/lhuGOYNhl1X/g38xIBS2RtxTLneMcyEtE1RDadmU9J0KuYyVmBBc jdNJSaw3iWzmO0es/YdBNnk02fVM0z3gHEcdbMfTOTVpT9NtrlXpnw6DN4gTWKxYcghnS3LrxGb zxOgFIg4G9BZN++4Suv8iAggr4uR1TJbQxBI3sDxLv/RlAGMerfOGQS2mL9nWvVz26siHN1+Jx3 +ANCjhwbg3VS/RkJs8TIfn8Z5afHzOsGishI/hmUhCxoDBzp/t2zPm/obtkTR5zKvKky9b80WUO hi7W+dqK6yQoID3iqxeDjDyydBi9SZ84+rujKR89STY2T/RyuJA== X-Received: by 2002:a05:6512:1584:b0:595:7e2d:9889 with SMTP id 2adb3069b0e04-59b6ef239bfmr608037e87.1.1767796375050; Wed, 07 Jan 2026 06:32:55 -0800 (PST) X-Google-Smtp-Source: AGHT+IHtXm8onTnrNt0hjPFspKf/dNpqVUyzW76wjDYiEENse9MSnI5knSD9dudvYlcaNyf5heesBw== X-Received: by 2002:a05:6512:1584:b0:595:7e2d:9889 with SMTP id 2adb3069b0e04-59b6ef239bfmr608027e87.1.1767796374366; Wed, 07 Jan 2026 06:32:54 -0800 (PST) Received: from [192.168.68.112] (c-85-226-160-236.bbcust.telenor.se. [85.226.160.236]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-59b6bebfa94sm943327e87.55.2026.01.07.06.32.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Jan 2026 06:32:53 -0800 (PST) Message-ID: Subject: Re: [PATCH] erofs: don't bother with s_stack_depth increasing for now From: Alexander Larsson To: Gao Xiang , linux-erofs@lists.ozlabs.org Cc: LKML , Amir Goldstein , Christian Brauner , Miklos Szeredi Date: Wed, 07 Jan 2026 15:32:53 +0100 In-Reply-To: <20251231204225.2752893-1-hsiangkao@linux.alibaba.com> References: <20251231204225.2752893-1-hsiangkao@linux.alibaba.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.56.2 (3.56.2-2.fc42) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Thu, 2026-01-01 at 04:42 +0800, Gao Xiang wrote: > Previously, commit d53cd891f0e4 ("erofs: limit the level of fs > stacking > for file-backed mounts") bumped `s_stack_depth` by one to avoid > kernel > stack overflow, but it breaks composefs mounts, which need > erofs+ovl^2 > sometimes (and such setups are already used in production for quite > long > time) since `s_stack_depth` can be 3 (i.e., > FILESYSTEM_MAX_STACK_DEPTH > needs to change from 2 to 3). >=20 > After a long discussion on GitHub issues [1] about possible > solutions, > it seems there is no need to support nesting file-backed mounts as > one > conclusion (especially when increasing FILESYSTEM_MAX_STACK_DEPTH to > 3). > So let's disallow this right now, since there is always a way to use > loopback devices as a fallback. >=20 > Then, I started to wonder about an alternative EROFS quick fix to > address the composefs mounts directly for this cycle: since EROFS is > the > only fs to support file-backed mounts and other stacked fses will > just > bump up `FILESYSTEM_MAX_STACK_DEPTH`, just check that `s_stack_depth` > !=3D 0 and the backing inode is not from EROFS instead. >=20 > At least it works for all known file-backed mount use cases > (composefs, > containerd, and Android APEX for some Android vendors), and the fix > is > self-contained. >=20 > Let's defer increasing FILESYSTEM_MAX_STACK_DEPTH for now. >=20 > Fixes: d53cd891f0e4 ("erofs: limit the level of fs stacking for file- > backed mounts") > Closes: > https://github.com/coreos/fedora-coreos-tracker/issues/2087=C2=A0[1] > Closes: > https://lore.kernel.org/r/CAFHtUiYv4+=3D+JP_-JjARWjo6OwcvBj1wtYN=3Dz0QXwC= pec9sXtg@mail.gmail.com > Cc: Amir Goldstein > Cc: Alexander Larsson > Cc: Christian Brauner > Cc: Miklos Szeredi > Signed-off-by: Gao Xiang > --- Acked-by: Alexander Larsson > =C2=A0fs/erofs/super.c | 18 ++++++++++++------ > =C2=A01 file changed, 12 insertions(+), 6 deletions(-) >=20 > diff --git a/fs/erofs/super.c b/fs/erofs/super.c > index 937a215f626c..0cf41ed7ced8 100644 > --- a/fs/erofs/super.c > +++ b/fs/erofs/super.c > @@ -644,14 +644,20 @@ static int erofs_fc_fill_super(struct > super_block *sb, struct fs_context *fc) > =C2=A0 * fs contexts (including its own) due to self- > controlled RO > =C2=A0 * accesses/contexts and no side-effect changes that > need to > =C2=A0 * context save & restore so it can reuse the > current thread > - * context.=C2=A0 However, it still needs to bump > `s_stack_depth` to > - * avoid kernel stack overflow from nested > filesystems. > + * context. > + * However, we still need to prevent kernel stack > overflow due > + * to filesystem nesting: just ensure that > s_stack_depth is 0 > + * to disallow mounting EROFS on stacked > filesystems. > + * Note: s_stack_depth is not incremented here for > now, since > + * EROFS is the only fs supporting file-backed > mounts for now. > + * It MUST change if another fs plans to support > them, which > + * may also require adjusting > FILESYSTEM_MAX_STACK_DEPTH. > =C2=A0 */ > =C2=A0 if (erofs_is_fileio_mode(sbi)) { > - sb->s_stack_depth =3D > - file_inode(sbi->dif0.file)->i_sb- > >s_stack_depth + 1; > - if (sb->s_stack_depth > > FILESYSTEM_MAX_STACK_DEPTH) { > - erofs_err(sb, "maximum fs stacking > depth exceeded"); > + inode =3D file_inode(sbi->dif0.file); > + if (inode->i_sb->s_op =3D=3D &erofs_sops || > + =C2=A0=C2=A0=C2=A0 inode->i_sb->s_stack_depth) { > + erofs_err(sb, "file-backed mounts > cannot be applied to stacked fses"); > =C2=A0 return -ENOTBLK; > =C2=A0 } > =C2=A0 } --=20 =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- =3D-=3D-=3D Alexander Larsson Red Hat, Inc=20 alexl@redhat.com alexander.larsson@gmail.com=20 He's an all-American dishevelled card sharp searching for his wife's true=20 killer. She's a scantily clad insomniac bounty hunter with an incredible=20 destiny. They fight crime!=20