Re: [PATCH slab/for-next 02/14] lib/maple_tree: specify SLAB_MAY_ACCOUNT for maple_node cache

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] lib/maple_tree: missing SLAB_MAY_ACCOUNT in tools/include/linux/slab.h
--

commit d151188bc6327587207caf458d171cfa4b32a0d5
Author: Harry Yoo (Meta) <harry@kernel.org>

lib/maple_tree: specify SLAB_MAY_ACCOUNT for maple_node cache

This commit adds SLAB_MAY_ACCOUNT to the maple_node kmem_cache creation in
maple_tree_init() so that maple tree node allocations using __GFP_ACCOUNT
can be charged to a memcg.

> diff --git a/lib/maple_tree.c b/lib/maple_tree.c
> index 1aba6cced7130..e4794b31e5bfc 100644
> --- a/lib/maple_tree.c
> +++ b/lib/maple_tree.c
> @@ -5790,7 +5790,7 @@ void __init maple_tree_init(void)
>  
>  	maple_node_cache = kmem_cache_create("maple_node",
>  			sizeof(struct maple_node), &args,
> -			SLAB_PANIC);
> +			SLAB_PANIC | SLAB_MAY_ACCOUNT);
>  }

[Severity: Medium]
Does this break the build for the userspace test suites in
tools/testing/radix-tree/, tools/testing/vma/, and tools/testing/rbtree/?

Those suites compile tools/testing/shared/maple-shim.c, which includes
tools/include/linux/slab.h and directly includes lib/maple_tree.c:

tools/testing/shared/maple-shim.c:
    #include "maple-shared.h"
    #include <linux/slab.h>

    #include "../../../lib/maple_tree.c"

However, tools/include/linux/slab.h does not define SLAB_MAY_ACCOUNT in
enum _slab_flag_bits or its SLAB_* macros:

tools/include/linux/slab.h:
    enum _slab_flag_bits {
        _SLAB_KMALLOC,
        _SLAB_HWCACHE_ALIGN,
        _SLAB_PANIC,
        _SLAB_TYPESAFE_BY_RCU,
        _SLAB_ACCOUNT,
        _SLAB_FLAGS_LAST_BIT
    };

Should SLAB_MAY_ACCOUNT also be defined in tools/include/linux/slab.h so
that maple_tree_init() continues to compile in userspace tests?

>  
>  /**

iala

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261021-memalloc-prof-dont-waste-slabobj-ext-metadata-v1-0-096800aa3330@kernel.org?part=2