From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-118.freemail.mail.aliyun.com (out30-118.freemail.mail.aliyun.com [115.124.30.118]) (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 1FCD7329371 for ; Thu, 20 Aug 2026 13:55:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.118 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787234112; cv=none; b=IK0ayCItCLOvWA9InAbtuawIkOl5mM8zuajYWosk5pSlmcuz0iXuDZsFg4QHJc8nK9GpUWPgdT79PFNzZg8SXtM73TYIpinBuCmNGTuyktuOrWNNkqqPRkuQpGux0c/KJkhb7nNpYoVvFgHRmbcH+J7FvC1HLk1o01f4ua5ZF7U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787234112; c=relaxed/simple; bh=E5bVJoBrEXrEJBtbx3B3U78qt67bRAzTZrqcuX5BJBo=; h=Message-ID:Date:MIME-Version:Subject:To:References:From: In-Reply-To:Content-Type; b=pGdtkksVOUVxbmu8CpXyLs50qyP0L1ZuwtKLOumWgP5htcaufP0RTzZVMTj9sYQtlFNcXFQ1anqk0Igle2yp5IsUn5UMK70XPGSVT7Xc0cUa4/TaakwM4YvuD3AxcezhmTLncOR5LsKOVJuSrZCDjok3jyG1SdSI7z72WZOphmQ= 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=pHt9lmKX; arc=none smtp.client-ip=115.124.30.118 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="pHt9lmKX" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1787234104; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=jW+ucoig4ee8mNNSdkLaXNqqXddu8WqeUrvjviKK/eY=; b=pHt9lmKXd4SgWgm7vX0kSNLfs5Yqr0g38nOvKk+1dbxHIF6W8wEpcZW8QA6W72Pv/yO3zQvib4iw8TgyFR1M2Tvi7wGNmBAa3qJQ9lzoJvRjXplGMi1ujvs4u4Ao7PMUtEeoJU7SG37MhnakXEp19/UE3pzlBG317szDEzw9VrA= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R141e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037026112;MF=jefflexu@linux.alibaba.com;NM=1;PH=DS;RN=6;SR=0;TI=SMTPD_---0X9JfqFG_1787234103; Received: from 30.42.155.165(mailfrom:jefflexu@linux.alibaba.com fp:SMTPD_---0X9JfqFG_1787234103 cluster:ay36) by smtp.aliyun-inc.com; Thu, 20 Aug 2026 21:55:03 +0800 Message-ID: <19a0c827-1eda-454d-ac83-9e06fc59d3e4@linux.alibaba.com> Date: Thu, 20 Aug 2026 21:55:02 +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 , 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> <76ee52de-1dcb-44da-b2cf-329864adca07@linux.alibaba.com> Content-Language: en-US From: Jingbo Xu In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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