From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-111.freemail.mail.aliyun.com (out30-111.freemail.mail.aliyun.com [115.124.30.111]) (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 2B75A42DFEB; Tue, 20 Jan 2026 14:11:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.111 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768918285; cv=none; b=gteH6D8WtHNEI/6sc4+9w5IC3O2ksYBxftt78C/zhS0c14w0PcZLFFbJedyyHz/GaHsIOcl4GpnAnwGiYTFiqK/nTAH3Thwal/33MsA0y0Infl/rGfaYn7eE6uD6s7OplXbd314HPKj3Y3hcHSoy2AUD8JgnMgIQIa6EuTJVxS4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768918285; c=relaxed/simple; bh=A3mcmkq1kiF93N1w5Wj6kWoL+UE6WOy8SceE10C2Z/c=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=hETjbk941E+XN6p3bJFmnGK+Xl/cV9at08pfWel/zLXaMePt2MchhQGTcwAst5DPin9L0sOwdPlGqX7hKmBACNK7U2cskJ0TQSxV+f2VypyTZ8AIjDGhOqqKuKETENkfhlP8+ZUoELvbDCHflsboIP/p0Oy9NEIyM7JDvYjsZ8A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=L4iMTokk; arc=none smtp.client-ip=115.124.30.111 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="L4iMTokk" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1768918272; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=23an09Q0biO5z22AKKKB/TBPcY7M6X9cJ2eW+LaU65A=; b=L4iMTokkPJvXYERROr6TJndXGqiGUghSIfo7QAZPDhll40aEzS9wSKocgBFYVRhsbKv06XwZIiwIvnKl6CAlx6CdMVfDJ8Lo0xeVhh316EfY0/qJMdcOXUbs8QoAbtHnzEnBBNGz6qFJ5D1Tpt1u5ID8FYcLAo4TxAv86OpUwas= Received: from 30.180.182.138(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0WxUigVY_1768918271 cluster:ay36) by smtp.aliyun-inc.com; Tue, 20 Jan 2026 22:11:12 +0800 Message-ID: <1e9134c2-d984-41a3-b294-166b7e3e6bcf@linux.alibaba.com> Date: Tue, 20 Jan 2026 22:11:11 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v15 5/9] erofs: introduce the page cache share feature To: Christian Brauner , Christoph Hellwig Cc: Hongbo Li , chao@kernel.org, djwong@kernel.org, amir73il@gmail.com, linux-fsdevel@vger.kernel.org, linux-erofs@lists.ozlabs.org, linux-kernel@vger.kernel.org, Linus Torvalds , oliver.yang@linux.alibaba.com References: <20260116154623.GC21174@lst.de> <20260119072932.GB2562@lst.de> <8e30bc4b-c97f-4ab2-a7ce-27f399ae7462@linux.alibaba.com> <20260119083251.GA5257@lst.de> <20260119092220.GA9140@lst.de> <73f2c243-e029-4f95-aa8e-285c7affacac@linux.alibaba.com> <50db56b8-4cf9-4d62-b242-c982a260a330@linux.alibaba.com> <20260120065242.GA3436@lst.de> <20260120-neuland-rastplatz-31cc7d61a196@brauner> From: Gao Xiang In-Reply-To: <20260120-neuland-rastplatz-31cc7d61a196@brauner> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Christian, On 2026/1/20 21:40, Christian Brauner wrote: > On Tue, Jan 20, 2026 at 07:52:42AM +0100, Christoph Hellwig wrote: >> On Tue, Jan 20, 2026 at 11:07:48AM +0800, Gao Xiang wrote: >>> >>> Hi Christoph, >>> >>> Sorry I didn't phrase things clearly earlier, but I'd still >>> like to explain the whole idea, as this feature is clearly >>> useful for containerization. I hope we can reach agreement >>> on the page cache sharing feature: Christian agreed on this >>> feature (and I hope still): >>> >>> https://lore.kernel.org/linux-fsdevel/20260112-begreifbar-hasten-da396ac2759b@brauner >> >> He has to ultimatively decide. I do have an uneasy feeling about this. >> It's not super informed as I can keep up, and I'm not the one in charge, >> but I hope it is helpful to share my perspective. > > It always is helpful, Christoph! I appreciate your input. Thanks, I will raise some extra comments for Hongbo to change to make this feature more safer. > > I'm fine with this feature. But as I've said in person: I still oppose > making any block-based filesystem mountable in unprivileged containers > without any sort of trust mechanism. Nevertheless, since Christoph put this topic on the community list, I had to repeat my own latest thoughts of this on the list for reference. Anyway, some people would just be nitpicky to the words above as a policy: they will re-invent new non-block-based trick filesystems (but with much odd kernel-parsed metadata design) for the kernel community. Honestly, my own idea is that we should find real threats instead of arbitary assumptions against different types of filesystems. The original question is still that what provents _kernel filesystems with kernel-parsed metadata_ from mountable in unprivileged containers. On my own perspective (in public, without any policy involved), I think it would be better to get some fair technical points & concerns, so that either we either fully get in agreement as the real dead end or really overcome some barriers since this feature is indeed useful. I will not repeat my thoughts again to annoy folks even further for this topic, but document here for reference. > > I am however open in the future for block devices protected by dm-verity > with the root hash signed by a sufficiently trusted key to be mountable > in unprivileged containers. Signed images will be a good start, I fully agree. No one really argues that, and I believe I've told the signed image ideas in person to Christoph and Darrick too. Thanks, Gao Xiang