From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-124.freemail.mail.aliyun.com (out30-124.freemail.mail.aliyun.com [115.124.30.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 7805046EC95 for ; Thu, 20 Aug 2026 13:34:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787232897; cv=none; b=sAM0GLffDiQ5Am64eRMlHfkkqkrzCs2An4GSsf4khvJtQ2ZCn+oSgyaeF+4kYlXjC5N2kxOUhL5J/MxmCpvp+UH6rOJWyyC/0DafnoNacQ56gtvgZm9aqGdil/TOg3JguyItoEfi+D1oB7+1bHwhCeBaaX7Q6Y4I9J3XElr6cKU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787232897; c=relaxed/simple; bh=UXWZJxeuLCQv87RRjRDGxu0mw8pw+sE5ADvNEke3juI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=GI9UXexYe6yewzJulEpU9OOekChs1c2sz6c2uUzxQ0zRDWiKi16lKztBqrbO+NkTNUmbrNe7Xtgx2QYfw0ABC38QcDMGvbzRVho4S7vCjqQBE7FrKLXepQewvxawB39kj6yRPZQv6RbdbGD70Dc6ZNyAvDF9a1tIlpBug3MDjr0= 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=nFv80HCC; arc=none smtp.client-ip=115.124.30.124 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="nFv80HCC" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1787232890; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=NQQfCWFU8lTMyB4kZpp1AQfeK0U34PKN96OHaEuI3NM=; b=nFv80HCCRsg/wCDvnyqoe3fqKS0GKETeG1NokHcIi0lh3ZbuwfNI8hErrQ8/TqnHDVeAy2qsEcm0PmXKNpVoZ6eVFhoC5m9y51EYSa73Ue5TregGHMt8f/4awGbYFqx6+jZeqOqR6ZCqQBWwgPleeSGmn2ZP6e8/70AjNvf3mcQ= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R891e4;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_---0X9JeZM._1787232889; Received: from 30.42.155.165(mailfrom:jefflexu@linux.alibaba.com fp:SMTPD_---0X9JeZM._1787232889 cluster:ay36) by smtp.aliyun-inc.com; Thu, 20 Aug 2026 21:34:50 +0800 Message-ID: <76ee52de-1dcb-44da-b2cf-329864adca07@linux.alibaba.com> Date: Thu, 20 Aug 2026 21:34:49 +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] erofs: use the shared page cache for splice in inode_share mode To: Zhan Xusheng , Gao Xiang , Chao Yu Cc: Zhan Xusheng , linux-erofs@lists.ozlabs.org, linux-kernel@vger.kernel.org References: <20260820064441.1083470-1-zhanxusheng@xiaomi.com> <3d735f18-2d26-4b4c-be68-b000742e9826@linux.alibaba.com> <20260820123705.1748738-1-zhanxusheng@xiaomi.com> Content-Language: en-US From: Jingbo Xu In-Reply-To: <20260820123705.1748738-1-zhanxusheng@xiaomi.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 8/20/26 8:37 PM, Zhan Xusheng wrote: > On Thu, 20 Aug 2026 17:53:20 +0800, Jingbo Xu wrote: >> Please refer to backing_file_splice_read() called from >> ovl_splice_read(), file_accessed() needs to be called on the original >> file (just as what .read_iter() i.e. filemap_read() does), and the input >> @ppos needs to be updated accordingly. > > Taking the file_accessed() one, thanks. filemap_splice_read() calls it at > mm/filemap.c:3155 on whatever file it was handed, so on the backing file, > whereas backing_file_splice_read() ends in ctx->accessed(iocb->ki_filp), > which for ovl_splice_read() is the original. v2 adds file_accessed(in). > > @ppos looks already handled to me. filemap_splice_read() takes a loff_t * > and advances it itself, at mm/filemap.c:3144; its internal kiocb is seeded > from *ppos at 3083 and 3098, not the other way round. ovl_splice_read() > has to copy iocb.ki_pos back because backing_file_splice_read() takes a > struct kiocb and hands &iocb->ki_pos to vfs_splice_read(). Say if I have > that wrong. Make sense. > > One you may want for read_iter too: it clones the kiocb onto the backing > file, so filemap_read() marks that one accessed rather than the user's > file, which is the shape splice_read had. Neither is observable today, > since erofs_fc_fill_super() sets SB_RDONLY | SB_NOATIME and the backing > file is opened O_NOATIME, so both reach a no-op. That is why I left > read_iter alone here. Okay, it seems that file_accessed() shall also be added to erofs_ishare_file_read_iter()? -- Thanks, Jingbo