linux-ext4 - Re: [RFC PATCHv2 1/1] fs: ext4: Don't use CMA for buffer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGWkznG5ZLkmp45hi2AHA3dZyf1tDgRtVQP=JhRdkVj53dpjDw@mail.gmail.com>
Date: Fri, 23 Aug 2024 16:53:43 +0800
From: Zhaoyang Huang <huangzhaoyang@...il.com>
To: "zhaoyang.huang" <zhaoyang.huang@...soc.com>
Cc: "Theodore Ts'o" <tytso@....edu>, Andreas Dilger <adilger.kernel@...ger.ca>, 
	Baolin Wang <baolin.wang@...ux.alibaba.com>, linux-fsdevel@...r.kernel.org, 
	linux-ext4@...r.kernel.org, steve.kang@...soc.com
Subject: Re: [RFC PATCHv2 1/1] fs: ext4: Don't use CMA for buffer_head

On Fri, Aug 23, 2024 at 4:24 PM zhaoyang.huang
<zhaoyang.huang@...soc.com> wrote:
>
> From: Zhaoyang Huang <zhaoyang.huang@...soc.com>
>
> cma_alloc() keep failed in our system which thanks to a jh->bh->b_page
> can not be migrated out of CMA area[1] as the jh has one cp_transaction
> pending on it because of j_free > j_max_transaction_buffers[2][3][4][5][6].
> We temporarily solve this by launching jbd2_log_do_checkpoint forcefully
> somewhere. Since journal is common mechanism to all JFSs and
> cp_transaction has a little fewer opportunity to be launched, the
> cma_alloc() could be affected under the same scenario. This patch
> would like to have buffer_head of ext4 not use CMA pages when doing
> sb_getblk.
>
> [1]
> crash_arm64_v8.0.4++> kmem -p|grep ffffff808f0aa150(sb->s_bdev->bd_inode->i_mapping)
> fffffffe01a51c00  e9470000 ffffff808f0aa150        3  2 8000000008020 lru,private //within CMA area
> fffffffe03d189c0 174627000 ffffff808f0aa150        4  2 2004000000008020 lru,private
> fffffffe03d88e00 176238000 ffffff808f0aa150      3f9  2 2008000000008020 lru,private
> fffffffe03d88e40 176239000 ffffff808f0aa150        6  2 2008000000008020 lru,private
> fffffffe03d88e80 17623a000 ffffff808f0aa150        5  2 2008000000008020 lru,private
> fffffffe03d88ec0 17623b000 ffffff808f0aa150        1  2 2008000000008020 lru,private
> fffffffe03d88f00 17623c000 ffffff808f0aa150        0  2 2008000000008020 lru,private
> fffffffe040e6540 183995000 ffffff808f0aa150      3f4  2 2004000000008020 lru,private
>
> [2] page -> buffer_head
> crash_arm64_v8.0.4++> struct page.private fffffffe01a51c00 -x
>       private = 0xffffff802fca0c00
>
> [3] buffer_head -> journal_head
> crash_arm64_v8.0.4++> struct buffer_head.b_private 0xffffff802fca0c00
>   b_private = 0xffffff8041338e10,
>
> [4] journal_head -> b_cp_transaction
> crash_arm64_v8.0.4++> struct journal_head.b_cp_transaction 0xffffff8041338e10 -x
>   b_cp_transaction = 0xffffff80410f1900,
>
> [5] transaction_t -> journal
> crash_arm64_v8.0.4++> struct transaction_t.t_journal 0xffffff80410f1900 -x
>   t_journal = 0xffffff80e70f3000,
>
> [6] j_free & j_max_transaction_buffers
> crash_arm64_v8.0.4++> struct journal_t.j_free,j_max_transaction_buffers 0xffffff80e70f3000 -x
>   j_free = 0x3f1,
>   j_max_transaction_buffers = 0x100,
>
> Signed-off-by: Zhaoyang Huang <zhaoyang.huang@...soc.com>
> ---
> v2: update commit message
> ---
> ---
>  fs/ext4/inode.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 941c1c0d5c6e..4422246851fe 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -869,7 +869,11 @@ struct buffer_head *ext4_getblk(handle_t *handle, struct inode *inode,
>         if (nowait)
>                 return sb_find_get_block(inode->i_sb, map.m_pblk);
>
> +#ifndef CONFIG_CMA
>         bh = sb_getblk(inode->i_sb, map.m_pblk);
> +#else
> +       bh = sb_getblk_gfp(inode->i_sb, map.m_pblk, 0);
> +#endif
>         if (unlikely(!bh))
>                 return ERR_PTR(-ENOMEM);
>         if (map.m_flags & EXT4_MAP_NEW) {
> --
> 2.25.1
>
A hint for these, from my understanding, other FSs such as f2fs and
erofs have had the meta data avoid using the CMA area by using
GFP_NOFS/GFP_KERNEL on meta inode.

struct inode *f2fs_iget(struct super_block *sb, unsigned long ino)
{
...
        if (ino == F2FS_NODE_INO(sbi)) {
                inode->i_mapping->a_ops = &f2fs_node_aops;
                mapping_set_gfp_mask(inode->i_mapping, GFP_NOFS);
        } else if (ino == F2FS_META_INO(sbi)) {
                inode->i_mapping->a_ops = &f2fs_meta_aops;
                mapping_set_gfp_mask(inode->i_mapping, GFP_NOFS);

int erofs_init_managed_cache(struct super_block *sb)
{
        struct inode *const inode = new_inode(sb);

        if (!inode)
                return -ENOMEM;

        set_nlink(inode, 1);
        inode->i_size = OFFSET_MAX;
        inode->i_mapping->a_ops = &z_erofs_cache_aops;
        mapping_set_gfp_mask(inode->i_mapping, GFP_KERNEL);