From: Jingbo Xu <jefflexu@linux.alibaba.com>
To: Zhan Xusheng <zhanxusheng1024@gmail.com>,
Gao Xiang <xiang@kernel.org>, Chao Yu <chao@kernel.org>,
Zhan Xusheng <zhanxusheng@xiaomi.com>,
linux-erofs@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] erofs: use the shared page cache for splice in inode_share mode
Date: Thu, 20 Aug 2026 21:55:02 +0800 [thread overview]
Message-ID: <19a0c827-1eda-454d-ac83-9e06fc59d3e4@linux.alibaba.com> (raw)
In-Reply-To: <aocF3pQZFiDAIyTE@XiangdeMacBook-Pro.local>
On 8/20/26 9:49 PM, Gao Xiang wrote:
> On Thu, Aug 20, 2026 at 09:34:49PM +0800, Jingbo Xu wrote:
>>
>>
>> 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()?
>
> I think file_accessed() is a no-op for erofs?
Right. erofs unconditionally sets SB_NOATIME (sb->s_flags |= SB_RDONLY |
SB_NOATIME). Please ignore the noise..
--
Thanks,
Jingbo
next prev parent reply other threads:[~2026-08-20 13:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-20 6:44 Zhan Xusheng
2026-08-20 9:53 ` Jingbo Xu
2026-08-20 12:37 ` Zhan Xusheng
2026-08-20 13:34 ` Jingbo Xu
2026-08-20 13:49 ` Gao Xiang
2026-08-20 13:55 ` Jingbo Xu [this message]
2026-08-20 13:29 ` Gao Xiang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=19a0c827-1eda-454d-ac83-9e06fc59d3e4@linux.alibaba.com \
--to=jefflexu@linux.alibaba.com \
--cc=chao@kernel.org \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=xiang@kernel.org \
--cc=zhanxusheng1024@gmail.com \
--cc=zhanxusheng@xiaomi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®