From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout05.his.huawei.com (canpmsgout05.his.huawei.com [113.46.200.220]) (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 EC19019004A for ; Sat, 14 Feb 2026 01:04:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.220 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771031099; cv=none; b=e3oKlyGF2bPTOW1IoLoZkooY/Ek1OXJKJWi4Z2oYInfveO6BpvLcWBzfOPpnNbuv2oH2hjqoCI9zt3RocqDZGO8QsshAuTLVZ96WGWyi3nJ+wNhhUWPEnLST1xBHFT35L+Hqeqj7zaEMR/E+ublwzpbWnC+1pOGjQZHYarUfvCc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771031099; c=relaxed/simple; bh=gDzAhzxzcoM8e6yn1rEv1+xJYbpi/K8lVulRbYqXPMI=; h=Message-ID:Date:MIME-Version:Subject:To:References:CC:From: In-Reply-To:Content-Type; b=fcH9UWJrQ2rEQSE2wTffUJk+qPrsTq9Wq2eFEPRVTZ5x1sOftwHSav/NbL1+rMKv0QzNZaWD856RTfqCTQWSLOnxTCkOc3nLQ64pCSL1OuEDhtuWuXiTdcqqmn3Qi1B04+CLTy8AIdxmRC0CGShqrLxlnFMVeGw4+qedNmIMRY4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=JFU45E0k; arc=none smtp.client-ip=113.46.200.220 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="JFU45E0k" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=b8jpKimESx6PTjh1R8HBGFIOfiD1ZYYbNxc4mg8sUxE=; b=JFU45E0kfomb8J/BbVltQXIzVybu4oSLohBviveEztAUfCyY+2KLj/4i2BG2tdsjqQGsr7xSD 6X6+POroXpSPNMV28pUASz7eLTNNTA8xMGFG2zg4Kx1UvoVBX38o4TuKsBtxu60HgW//hWDKAIh 6dYs5BErJPbb5mC6cHjVeLs= Received: from mail.maildlp.com (unknown [172.19.162.140]) by canpmsgout05.his.huawei.com (SkyGuard) with ESMTPS id 4fCW0c5CjDz12LDJ; Sat, 14 Feb 2026 09:00:00 +0800 (CST) Received: from kwepemr500015.china.huawei.com (unknown [7.202.195.162]) by mail.maildlp.com (Postfix) with ESMTPS id CE3D42012A; Sat, 14 Feb 2026 09:04:47 +0800 (CST) Received: from [10.67.111.104] (10.67.111.104) by kwepemr500015.china.huawei.com (7.202.195.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Sat, 14 Feb 2026 09:04:47 +0800 Message-ID: Date: Sat, 14 Feb 2026 09:04:46 +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: allow sharing page cache with the same aops only To: References: <20260213073345.768320-1-lihongbo22@huawei.com> Content-Language: en-US CC: , , , From: Hongbo Li In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: kwepems200002.china.huawei.com (7.221.188.68) To kwepemr500015.china.huawei.com (7.202.195.162) On 2026/2/14 7:27, Gao Xiang wrote: > Hi Hongbo, > > On Fri, Feb 13, 2026 at 07:33:45AM +0000, Hongbo Li wrote: >> Inode with identical data but different @aops cannot be mixed >> because the page cache is managed by different subsystems (e.g., >> @aops for compressed on-disk inodes cannot handle plain on-disk >> inodes). >> ... >> >> diff --git a/fs/erofs/inode.c b/fs/erofs/inode.c >> index 4f86169c23f1..5b05272fd9c4 100644 >> --- a/fs/erofs/inode.c >> +++ b/fs/erofs/inode.c >> @@ -254,7 +254,8 @@ static int erofs_fill_inode(struct inode *inode) >> } >> >> mapping_set_large_folios(inode->i_mapping); >> - return erofs_inode_set_aops(inode, inode, false); >> + inode->i_mapping->a_ops = erofs_get_aops(inode, false); >> + return IS_ERR(inode->i_mapping->a_ops) ? PTR_ERR(inode->i_mapping->a_ops) : 0; > > I hope there is an aops variable instead of assigning > inode->i_mapping->a_ops directly. > Ok, thank you. >> } >> >> /* >> diff --git a/fs/erofs/internal.h b/fs/erofs/internal.h >> index d1634455e389..764e81b3bc08 100644 >> --- a/fs/erofs/internal.h >> +++ b/fs/erofs/internal.h >> @@ -471,26 +471,24 @@ static inline void *erofs_vm_map_ram(struct page **pages, unsigned int count) >> return NULL; >> } >> >> -static inline int erofs_inode_set_aops(struct inode *inode, >> - struct inode *realinode, bool no_fscache) >> +static inline const struct address_space_operations * >> +erofs_get_aops(struct inode *realinode, bool no_fscache) >> { >> if (erofs_inode_is_data_compressed(EROFS_I(realinode)->datalayout)) { >> if (!IS_ENABLED(CONFIG_EROFS_FS_ZIP)) >> - return -EOPNOTSUPP; >> + return ERR_PTR(-EOPNOTSUPP); >> DO_ONCE_LITE_IF(realinode->i_blkbits != PAGE_SHIFT, >> erofs_info, realinode->i_sb, >> "EXPERIMENTAL EROFS subpage compressed block support in use. Use at your own risk!"); >> - inode->i_mapping->a_ops = &z_erofs_aops; >> - return 0; >> + return &z_erofs_aops; >> } >> - inode->i_mapping->a_ops = &erofs_aops; >> - if (IS_ENABLED(CONFIG_EROFS_FS_ONDEMAND) && !no_fscache && >> - erofs_is_fscache_mode(realinode->i_sb)) >> - inode->i_mapping->a_ops = &erofs_fscache_access_aops; >> if (IS_ENABLED(CONFIG_EROFS_FS_BACKED_BY_FILE) && >> erofs_is_fileio_mode(EROFS_SB(realinode->i_sb))) >> - inode->i_mapping->a_ops = &erofs_fileio_aops; >> - return 0; >> + return &erofs_fileio_aops; >> + if (IS_ENABLED(CONFIG_EROFS_FS_ONDEMAND) && !no_fscache && >> + erofs_is_fscache_mode(realinode->i_sb)) >> + return &erofs_fscache_access_aops; > > Can you rearrange it as > if (IS_ENABLED(CONFIG_EROFS_FS_ONDEMAND) && !no_fscache && > erofs_is_fscache_mode(realinode->i_sb)) > return &erofs_fscache_access_aops; > if (IS_ENABLED(CONFIG_EROFS_FS_BACKED_BY_FILE) && > erofs_is_fileio_mode(EROFS_SB(realinode->i_sb))) > inode->i_mapping->a_ops = &erofs_fileio_aops; > return &erofs_aops; > Ok, they are equal. Since the EROFS in fscache mode can be fileio mode. And I will rearrange it in next version. Thanks, Hongbo > ? > > Thanks, > Gao Xiang >