From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 9401A1A2545 for ; Mon, 24 Aug 2026 00:46:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787532404; cv=none; b=M3ocd4Vdtu3chJIAwR1p4EvjtfnBIDbiHLH7X7l5Iva396F40IniTauN0ionIdfRSQ6QItBJPLcIAi352h85l+TceTEWDGpjAa3V7XPlflb3qtnood87Jq1VKltDreXv0+d39XVxIIbS4byp1U9pZ2QtAuVCxHgNUlmIhGrYZF0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787532404; c=relaxed/simple; bh=er0cBzH1RpuK8wf8XyJC1gkLvrKnQKdDrGhjxwPd4uw=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=Ds4Yx/zhtm7v1MRRCnqPA2LwNekUa3/IV9FfS5zLukICc01ElxOFiIG/RF3wvAu+od5JStPh9QNgn43vRQrBN0Wc9soWtWj/Sd7Pzk5WcTad/b3gRA89MiZl/PHw3+7JgbZgBicqBZuEXPwbX3Azxidc6nhSqzEuo91xC7TFzpY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Z4jbfSSB; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Z4jbfSSB" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B46521F000E9; Mon, 24 Aug 2026 00:46:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787532403; bh=R/3OWfaIF1a/3j0UN2xNBi9yIyeiwvp1Q+6gqCJ7gQQ=; h=Date:Cc:Subject:To:References:From:In-Reply-To; b=Z4jbfSSB8+JFnf8woci6zxuz5eiJ2W6ZQ8ye3NMmlH07CkJHnpNzCaXDIq+bAFzve KAj12r2yjfkLY7Kr62Q9HAA/7MVcGrTMhcuS/SEkcxwU/ufOjkMF4d/GiZnJhP1NiG 3b7f7Sv6v+Oj1wQ9vcZT+C9cva88/jr3yhSONzuv1nlCvK0fd8NQ6Z2Itf2Al63t5G pjcRM0yQGHeNP8oZv8ZsClQcAZti4K3zI1Kllu6HzDJWYlQ87hCZvB9He544oR3mx+ l9fiMkT+BA5M8L6P2mlLwII5+N2iW91PbhTSR9sOkbrjmYYnE4tvILl7+AGHBxS4on 8W8RmKq46KPDg== Message-ID: Date: Mon, 24 Aug 2026 08:46:39 +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 Cc: chao@kernel.org, Jingbo Xu , zhanxusheng@xiaomi.com, linux-erofs@lists.ozlabs.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] erofs: support splice() in inode_share mode To: Zhan Xusheng , Gao Xiang References: <20260821015641.1936276-1-zhanxusheng@xiaomi.com> Content-Language: en-US From: Chao Yu In-Reply-To: <20260821015641.1936276-1-zhanxusheng@xiaomi.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 8/21/26 09:56, 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 Reviewed-by: Chao Yu Thanks,