From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-113.freemail.mail.aliyun.com (out30-113.freemail.mail.aliyun.com [115.124.30.113]) (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 D350A2931C0 for ; Fri, 21 Aug 2026 06:33:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.113 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787294025; cv=none; b=EEak4OI5RrNg/l+fGZa8bkApgRfL6eoJMzLCEJYK0AgxWyZBwhtgog3TvHuMlw3D+vb24F+y8RGeRdPr+gafZsJn1P66KRHDdzOrLq6iIQ6QabpTlkn8IELYPjUDV3nB8RGW+jNYxsThBD1VTa2EQ/VwWCqNIKRSPkD8rJ+S6uI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787294025; c=relaxed/simple; bh=T6lxguNAqN56/EWe1nNz0Ms935oNN1tEPQzLlz7TRPc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=KIoszKNVJytqOMuTeKuVeQYWN6YdzNM20YUCGX0yQD4FIrBF3FRcNB2ykM85mzzCbBkQ/CG+JeBeNXCY7Iwp9VKThMkHP2MSCPi7qVNPXmk7uAmTVGsBjH4tyy66w8UgVIKHk0t7ugs3HAkIijUssNXiQUgXY6P3CL+ZbdEJWIo= 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=Qf3gLKUd; arc=none smtp.client-ip=115.124.30.113 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="Qf3gLKUd" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1787294018; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=A2dL1eEVT2+14dzzJ8BeskCqbSp+ITcLrJsYW8Szvuo=; b=Qf3gLKUdrjL3SVlypKXRCoV8Q8O7c0hYEozQiQqhp6BN7fonrglkYc+PkCjLFGtmsXcUzguq+vqDNsCpcRHZSccprN2+oyoc2VDzPSzFpYIHtZFelkgMB6fraQy8qN+n5gtp+AOaKDl+VLuJjX3kNGoAgiwEn9go62gzm7p2mPk= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R151e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033032089153;MF=jefflexu@linux.alibaba.com;NM=1;PH=DS;RN=6;SR=0;TI=SMTPD_---0X9LOWQM_1787294017; Received: from 30.221.150.0(mailfrom:jefflexu@linux.alibaba.com fp:SMTPD_---0X9LOWQM_1787294017 cluster:ay36) by smtp.aliyun-inc.com; Fri, 21 Aug 2026 14:33:37 +0800 Message-ID: <866a9563-70e3-444f-909c-bb8b85688657@linux.alibaba.com> Date: Fri, 21 Aug 2026 14:33:36 +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 v2] erofs: support splice() in inode_share mode To: Zhan Xusheng , Gao Xiang , Chao Yu Cc: zhanxusheng@xiaomi.com, linux-erofs@lists.ozlabs.org, linux-kernel@vger.kernel.org References: <20260821015641.1936276-1-zhanxusheng@xiaomi.com> Content-Language: en-US From: Jingbo Xu In-Reply-To: <20260821015641.1936276-1-zhanxusheng@xiaomi.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 8/21/26 9:56 AM, Zhan Xusheng wrote: > From: Zhan Xusheng > > From: Zhan Xusheng > > erofs_ishare_fops routes everything that touches the page cache to the > backing file in ->private_data: read_iter clones the iocb onto it, mmap > does vma_set_file(), fadvise calls vfs_fadvise() on it. splice_read was > left as filemap_splice_read(), which works on the user file's own mapping: > it does init_sync_kiocb(&iocb, in), and filemap_get_pages() then takes > iocb->ki_filp->f_mapping. > > So splice() and sendfile() fill the per-inode page cache rather than the > shared one. The content is the same either way, since erofs_fill_inode() > sets a_ops on that mapping too, which is why this went unnoticed. Two > identical 8 MiB files under inode_share, reading one of them with splice(2) > alone, in pages: > > before own 2048 shared 0 > after own 0 shared 2048 > > "own" is cachestat(fd), which reports the file's own mapping; "shared" is > mmap()+mincore(), which erofs_ishare_mmap() redirects to the backing file. > > Read through the backing file, as read_iter already does. > > Link: https://lore.kernel.org/all/b7dc7192-d586-45a2-bc4a-b41dc681c9bb@linux.alibaba.com/ > Signed-off-by: Zhan Xusheng LGTM. Reviewed-by: Jingbo Xu \ > --- > v1->v2: > - Retitled and dropped the Fixes tag: the sharing is best effort, so > this is an enhancement rather than a fix. > - Added the measured before/after. > - Left file_accessed() alone, since it is a no-op under SB_NOATIME. > - An erofs-utils test is sent separately against experimental-tests. > > v1: https://lore.kernel.org/all/20260820064441.1083470-1-zhanxusheng@xiaomi.com > > fs/erofs/ishare.c | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/fs/erofs/ishare.c b/fs/erofs/ishare.c > index fa7d4112dec5..01dc53e9e3ad 100644 > --- a/fs/erofs/ishare.c > +++ b/fs/erofs/ishare.c > @@ -148,6 +148,13 @@ static int erofs_ishare_mmap(struct file *file, struct vm_area_struct *vma) > return generic_file_readonly_mmap(file, vma); > } > > +static ssize_t erofs_ishare_splice_read(struct file *in, loff_t *ppos, > + struct pipe_inode_info *pipe, > + size_t len, unsigned int flags) > +{ > + return filemap_splice_read(in->private_data, ppos, pipe, len, flags); > +} > + > static int erofs_ishare_fadvise(struct file *file, loff_t offset, > loff_t len, int advice) > { > @@ -161,7 +168,7 @@ const struct file_operations erofs_ishare_fops = { > .mmap = erofs_ishare_mmap, > .release = erofs_ishare_file_release, > .get_unmapped_area = thp_get_unmapped_area, > - .splice_read = filemap_splice_read, > + .splice_read = erofs_ishare_splice_read, > .fadvise = erofs_ishare_fadvise, > }; > -- Thanks, Jingbo