From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com [209.85.208.174]) (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 495333D1CA1 for ; Thu, 8 Jan 2026 12:15:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767874523; cv=none; b=M35IVm6OH/a2YrQP01I9p88UEiyLOJ0Kv/2sADGgt6gb+8YhZP4hHBjFU+jkr0wpTnkVTSI1sgXDfTmo+3LKH2fyWpVVCb9H7S2GwAzqL7uCwt6AHBJS5quFypcaEiGZVipp16vQUJ0X9jtXGEAyQPjZ6SX/UDNv6w3+7oWgWos= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767874523; c=relaxed/simple; bh=u0Rfh59JjBvib8jxFGPAzoq3QQzoRj4RCMEQjAlnJnU=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=iZ1uljvHH/Sk6xDMUN6NgYofADR1/Qe6Uqr7kDZQAexQAtqFr+u/evpllK7jK+0Mi5avOC/JOZ953mcYz9H2dEC0kCRDfFgGiln3s4fm6lYyNGP16vWDzPbYFInKj5hhkx2pfzESave3aEgZLW5v95jl4n3zr3TpPpe/5JgC/pc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Qm+EG0k7; arc=none smtp.client-ip=209.85.208.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Qm+EG0k7" Received: by mail-lj1-f174.google.com with SMTP id 38308e7fff4ca-382fb535b73so18408091fa.0 for ; Thu, 08 Jan 2026 04:15:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767874515; x=1768479315; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=xWXsVjPSBACvOUrTWUoZ6i3cfhSX/bnB+GsdyHt4Nog=; b=Qm+EG0k7DguKHtDq7CmyYoHx5NJy9RJ5zjwWDdN0W+EtdbVRnG6UAIJuojTZBvlfbF bTkTJqGTE0fV4aDU5HW2GQ7K0d9uSxiw5B0Q08SQ0U/9/YXU3HuaD7GK0D+uSBFEyFjM lwXz7j3QPdD8FQlzdogm61jQ2+MY1+934cX8ahdofFUFCit7umSgndIkfXZpsqOD27XK msZiINKyTdqeaK+EFwGawysQolWgWbBKtB25qo+dFlUZZTss1HOK1kMe61E4uHttnG2j a1QUpc7uniOxzRzt3wyxrNPmZFQ7o1sGqaoPzKWaOibOOYX9n3I4pZBrEt+kKhDeRlIx NuQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767874515; x=1768479315; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=xWXsVjPSBACvOUrTWUoZ6i3cfhSX/bnB+GsdyHt4Nog=; b=eCCrZSl5TGzqhUWx1taW8ljg1bHdt8dQdiQwenGUgd2U1OlQhBeYtrNz6DHPxmhRuu lrP2I63nixSs9wzD2B1rD7t//6yCMGwjWj+pCpDAaKwz8TEnjiqENE5mVAlwKBwF/bC2 Qna8yxInszmJ5Z6B/rAoUBAU6pU68tpuSek3mklJcakG0a3n1r7fYwqSTNZ9OWlca6Jt Ydrq56YXBHyai/rcIDHdnRiTOLbBAkmFM5uzIcWRoriZd45Y0X82d/lkTpU9frlBrxa0 Dmn6TjV6PiGyfnAc3QFL5xOJWseg+Hh7ZT2R7acS2Zs4CTeJ43BSmIC7xFMFY5KJq0hc njcA== X-Forwarded-Encrypted: i=1; AJvYcCV6uTBk7lMBNmq5GBgHMrvQFNLw1F5N+gNeQiigQn/lfAI1N/KVGHx4vt/UB1RxbazPaa0lL8GbWRH41II=@vger.kernel.org X-Gm-Message-State: AOJu0YxAoDmgwFgxHDrkkUPjTQSyv1cm96liwNZK3oUxeCXjqILmzYgq 19GiN5a7vrnnOZuIY783S6SaxaVbv+v3u+uyj40Jh0SAcRyc+ZCoQFJIyCTFjQ== X-Gm-Gg: AY/fxX61a+DlrpPJ2h4clQVJAWZTfnYNybiP+lJosQzTlt/EEmGArl8qdn8Keox35I3 5xZyj+rOTvhWewGjkPWVpt0BQ5he56xb2h5fXsN5qLCCQvbkR5CrVyrdLGcsRs89mrtVXp2MVO+ 9AadhfqysSEWdDzHIm2BMutvaNIP6V3/92aQLWr0k0BX1A3/6pumbJiD6Y5RBfUEuGpD9MokJt/ DvcaI9OJ+Y4dxT6sHDxFFSE2aum2OOMjWTqm5yPxcOxlao1Rpabft0IhgTGuR40kMpgXxfr04oo 2vHw4HdXSJtEyUQcbnZW23wK+BDIbTihDCe924fve+YRYBCYi8xrAHqEyBXz4Fi7cz77WL3alAY d6XGIXjqCD3VT8Yt7gfRLPiMiU/Yrnf+7j5NPxZ+KEpbhmcUOcmuAuJP8hAZZuE/qaRwvQnUmFW uebV0m5LOKk6ehnoxTuJw2Uxq/T1CJzRFwM+AkCS120o2CZsN2Jl3N X-Google-Smtp-Source: AGHT+IFmC/s2zmdOBadT/g4NYT+5EdU6A/sY6V1s9b9j38zaQ6W1AyyE0nBMoGSOz8ZyH3UraVUgxg== X-Received: by 2002:a05:600c:4f53:b0:477:7991:5d1e with SMTP id 5b1f17b1804b1-47d84b3860fmr58019005e9.25.1767867978798; Thu, 08 Jan 2026 02:26:18 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5ee870sm15478511f8f.36.2026.01.08.02.26.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Jan 2026 02:26:18 -0800 (PST) Date: Thu, 8 Jan 2026 10:26:13 +0000 From: David Laight To: Gao Xiang Cc: Amir Goldstein , Sheng Yong , LKML , linux-fsdevel , Dusty Mabe , =?UTF-8?B?VGltb3Row6ll?= Ravier , =?UTF-8?B?QWxla3PDqWkgTmFpZMOpbm92?= , Alexander Larsson , Christian Brauner , Miklos Szeredi , Zhiguo Niu , shengyong1@xiaomi.com, linux-erofs mailing list Subject: Re: [PATCH v2] erofs: don't bother with s_stack_depth increasing for now Message-ID: <20260108102613.33bbc6d4@pumpkin> In-Reply-To: <4b427f6f-3b26-4dc8-bf6f-79eeabf6ba84@linux.alibaba.com> References: <0c34f3fa-c573-4343-b8ea-6832530f0069@linux.alibaba.com> <20260106170504.674070-1-hsiangkao@linux.alibaba.com> <3acec686-4020-4609-aee4-5dae7b9b0093@gmail.com> <41b8a0bb-96d3-4eba-a5b8-77b0b0ed4730@linux.alibaba.com> <121cb490-f13a-4957-97be-ea87baa10827@linux.alibaba.com> <4b427f6f-3b26-4dc8-bf6f-79eeabf6ba84@linux.alibaba.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) 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: quoted-printable On Thu, 8 Jan 2026 16:05:03 +0800 Gao Xiang wrote: > Hi Amir, >=20 > On 2026/1/8 16:02, Amir Goldstein wrote: > > On Thu, Jan 8, 2026 at 4:10=E2=80=AFAM Gao Xiang wrote: =20 >=20 > ... >=20 > >>>> > >>>> Hi, Xiang > >>>> > >>>> In Android APEX scenario, apex images formatted as EROFS are packed = in > >>>> system.img which is also EROFS format. As a result, it will always f= ail > >>>> to do APEX-file-backed mount since `inode->i_sb->s_op =3D=3D &erofs_= sops' > >>>> is true. > >>>> Any thoughts to handle such scenario? =20 > >>> > >>> Sorry, I forgot this popular case, I think it can be simply resolved > >>> by the following diff: > >>> > >>> diff --git a/fs/erofs/super.c b/fs/erofs/super.c > >>> index 0cf41ed7ced8..e93264034b5d 100644 > >>> --- a/fs/erofs/super.c > >>> +++ b/fs/erofs/super.c > >>> @@ -655,7 +655,7 @@ static int erofs_fc_fill_super(struct super_block= *sb, struct fs_context *fc) > >>> */ > >>> if (erofs_is_fileio_mode(sbi)) { > >>> inode =3D file_inode(sbi->dif0.file); > >>> - if (inode->i_sb->s_op =3D=3D &erofs_sops || > >>> + if ((inode->i_sb->s_op =3D=3D &erofs_sops && = !sb->s_bdev) || =20 > >> > >> Sorry it should be `!inode->i_sb->s_bdev`, I've > >> fixed it in v3 RESEND: =20 > >=20 > > A RESEND implies no changes since v3, so this is bad practice. > > =20 > >> https://lore.kernel.org/r/20260108030709.3305545-1-hsiangkao@linux.ali= baba.com > >> =20 > >=20 > > Ouch! If the erofs maintainer got this condition wrong... twice... > > Maybe better using the helper instead of open coding this non trivial c= heck? > >=20 > > if ((inode->i_sb->s_op =3D=3D &erofs_sops && > > erofs_is_fileio_mode(EROFS_I_SB(inode))) =20 >=20 > I was thought to use that, but it excludes fscache as the > backing fs.. so I suggest to use !s_bdev directly to > cover both file-backed mounts and fscache cases directly. Is it worth just allocating each fs a 'stack needed' value and then allowing the mount if the total is low enough. This is equivalent to counting the recursion depth, but lets erofs only add (say) 0.5. Ideally you'd want to do static analysis to find the value to add, but 'inspired guesswork' is probably good enough. Isn't there also a big difference between recursive mounts (which need to do read/write on the underlying file) and overlay mounts (which just pass the request onto the lower filesystem). David >=20 > Thanks, > Gao Xiang >=20 > >=20 > > Thanks, > > Amir. =20 >=20 >=20