mm/slab: fix 'variable obj_exts set but not used' warning

PATCH Applied Suren Baghdasaryan 2 participants 6 messages Jun 14, 2024 – Jul 3, 2024

Subsystems (2)

Memory management Slab allocator

lore

Share & tools

lore

Suren Baghdasaryan

author

2024-06-14 22:59 UTC #0 lore raw

PATCH 1/1 mm/slab: fix 'variable obj_exts set but not used' warning

slab_post_alloc_hook() uses prepare_slab_obj_exts_hook() to obtain slabobj_ext object. Currently the only user of slabobj_ext object in this path is memory allocation profiling, therefore when it's not enabled this object is not needed. This also generates a warning when compiling with CONFIG_MEM_ALLOC_PROFILING=n. Move the code under this configuration to fix the warning. If more slabobj_ext users appear in the future, the code will have to be changed back to call prepare_slab_obj_exts_hook().

Fixes 4b8736964640 ("mm/slab: add allocation accounting into slab allocation and free paths")

Reported-by kernel test robot <[email protected]>

Closes https://lore.kernel.org/oe-kbuild-all/[email protected]/ open here

Signed-off-by Suren Baghdasaryan <[email protected]>

---
 mm/slub.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

mm/slub.c +4 -3

index 1373ac365a46..4927edec6a8c 100644
@@ -3902,7 +3902,6 @@ bool slab_post_alloc_hook(struct kmem_cache *s, struct list_lru *lru,
 			  unsigned int orig_size)
 {
 	unsigned int zero_size = s->object_size;
-	struct slabobj_ext *obj_exts;
 	bool kasan_init = init;
 	size_t i;
 	gfp_t init_flags = flags & gfp_allowed_mask;

@@ -3945,9 +3944,11 @@ bool slab_post_alloc_hook(struct kmem_cache *s, struct list_lru *lru,
 		kmemleak_alloc_recursive(p[i], s->object_size, 1,
 					 s->flags, init_flags);
 		kmsan_slab_alloc(s, p[i], init_flags);
+#ifdef CONFIG_MEM_ALLOC_PROFILING
 		if (need_slab_obj_ext()) {
+			struct slabobj_ext *obj_exts;
+
 			obj_exts = prepare_slab_obj_exts_hook(s, flags, p[i]);
-#ifdef CONFIG_MEM_ALLOC_PROFILING
 			/*
 			 * Currently obj_exts is used only for allocation profiling.
 			 * If other users appear then mem_alloc_profiling_enabled()

@@ -3955,8 +3956,8 @@ bool slab_post_alloc_hook(struct kmem_cache *s, struct list_lru *lru,
 			 */
 			if (likely(obj_exts))
 				alloc_tag_add(&obj_exts->ref, current->alloc_tag, s->size);
-#endif
 		}
+#endif
 	}
 
 	return memcg_slab_post_alloc_hook(s, lru, flags, size, p);

base-commit: c286c21ff94252f778515b21b6bebe749454a852

Signature · 1 line

2.45.2.627.g7a2c4fd464-goog

Vlastimil Babka

Acked-by on v1 1/1

2024-06-17 10:04 UTC #1 lore raw

Quoted 8 lines · Suren Baghdasaryan

slab_post_alloc_hook() uses prepare_slab_obj_exts_hook() to obtain slabobj_ext object. Currently the only user of slabobj_ext object in this path is memory allocation profiling, therefore when it's not enabled this object is not needed. This also generates a warning when compiling with CONFIG_MEM_ALLOC_PROFILING=n. Move the code under this configuration to fix the warning. If more slabobj_ext users appear in the future, the code will have to be changed back to call prepare_slab_obj_exts_hook().

Quoted 4 lines

Fixes 4b8736964640 ("mm/slab: add allocation accounting into slab allocation and free paths")
Reported-by kernel test robot <[email protected]>
Closes https://lore.kernel.org/oe-kbuild-all/[email protected]/ open here
Signed-off-by Suren Baghdasaryan <[email protected]>

Acked-by Vlastimil Babka <[email protected]>

But it seems to me we could remove the whole #ifdef if current->alloc_tag (which doesn't exist with !MEM_ALLOC_PROFILING) had an access helper, or there was a alloc_tag_add_current() variant?

Quoted 41 lines

---
 mm/slub.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

mm/slub.c +4 -3

index 1373ac365a46..4927edec6a8c 100644
@@ -3902,7 +3902,6 @@ bool slab_post_alloc_hook(struct kmem_cache *s, struct list_lru *lru,
 			  unsigned int orig_size)
 {
 	unsigned int zero_size = s->object_size;
-	struct slabobj_ext *obj_exts;
 	bool kasan_init = init;
 	size_t i;
 	gfp_t init_flags = flags & gfp_allowed_mask;

@@ -3945,9 +3944,11 @@ bool slab_post_alloc_hook(struct kmem_cache *s, struct list_lru *lru,
 		kmemleak_alloc_recursive(p[i], s->object_size, 1,
 					 s->flags, init_flags);
 		kmsan_slab_alloc(s, p[i], init_flags);
+#ifdef CONFIG_MEM_ALLOC_PROFILING
 		if (need_slab_obj_ext()) {
+			struct slabobj_ext *obj_exts;
+
 			obj_exts = prepare_slab_obj_exts_hook(s, flags, p[i]);
-#ifdef CONFIG_MEM_ALLOC_PROFILING
 			/*
 			 * Currently obj_exts is used only for allocation profiling.
 			 * If other users appear then mem_alloc_profiling_enabled()

@@ -3955,8 +3956,8 @@ bool slab_post_alloc_hook(struct kmem_cache *s, struct list_lru *lru,
 			 */
 			if (likely(obj_exts))
 				alloc_tag_add(&obj_exts->ref, current->alloc_tag, s->size);
-#endif
 		}
+#endif
 	}
 
 	return memcg_slab_post_alloc_hook(s, lru, flags, size, p);

base-commit: c286c21ff94252f778515b21b6bebe749454a852

Suren Baghdasaryan

author

2024-06-30 19:20 UTC #2 lore raw

Quoted 15 lines · Vlastimil Babka

Quoted 8 lines · Suren Baghdasaryan
slab_post_alloc_hook() uses prepare_slab_obj_exts_hook() to obtain slabobj_ext object. Currently the only user of slabobj_ext object in this path is memory allocation profiling, therefore when it's not enabled this object is not needed. This also generates a warning when compiling with CONFIG_MEM_ALLOC_PROFILING=n. Move the code under this configuration to fix the warning. If more slabobj_ext users appear in the future, the code will have to be changed back to call prepare_slab_obj_exts_hook().
Quoted 4 lines
Fixes 4b8736964640 ("mm/slab: add allocation accounting into slab allocation and free paths")
Reported-by kernel test robot <[email protected]>
Closes https://lore.kernel.org/oe-kbuild-all/[email protected]/ open here
Signed-off-by Suren Baghdasaryan <[email protected]>

Quoted 5 lines

Acked-by Vlastimil Babka <[email protected]>
But it seems to me we could remove the whole #ifdef if current->alloc_tag (which doesn't exist with !MEM_ALLOC_PROFILING) had an access helper, or there was a alloc_tag_add_current() variant?

Hmm. I'll check if current->alloc_tag is the only reason for this ifdef. If so then you are correct and we can simplify this code.

Quoted 43 lines

Quoted 42 lines

---
 mm/slub.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

mm/slub.c +4 -3

index 1373ac365a46..4927edec6a8c 100644
@@ -3902,7 +3902,6 @@ bool slab_post_alloc_hook(struct kmem_cache *s, struct list_lru *lru,
                        unsigned int orig_size)
 {
      unsigned int zero_size = s->object_size;
-     struct slabobj_ext *obj_exts;
      bool kasan_init = init;
      size_t i;
      gfp_t init_flags = flags & gfp_allowed_mask;

@@ -3945,9 +3944,11 @@ bool slab_post_alloc_hook(struct kmem_cache *s, struct list_lru *lru,
              kmemleak_alloc_recursive(p[i], s->object_size, 1,
                                       s->flags, init_flags);
              kmsan_slab_alloc(s, p[i], init_flags);
+#ifdef CONFIG_MEM_ALLOC_PROFILING
              if (need_slab_obj_ext()) {
+                     struct slabobj_ext *obj_exts;
+
                      obj_exts = prepare_slab_obj_exts_hook(s, flags, p[i]);
-#ifdef CONFIG_MEM_ALLOC_PROFILING
                      /*
                       * Currently obj_exts is used only for allocation profiling.
                       * If other users appear then mem_alloc_profiling_enabled()

@@ -3955,8 +3956,8 @@ bool slab_post_alloc_hook(struct kmem_cache *s, struct list_lru *lru,
                       */
                      if (likely(obj_exts))
                              alloc_tag_add(&obj_exts->ref, current->alloc_tag, s->size);
-#endif
              }
+#endif
      }
 
      return memcg_slab_post_alloc_hook(s, lru, flags, size, p);

base-commit: c286c21ff94252f778515b21b6bebe749454a852

Vlastimil Babka

2024-07-02 09:31 UTC #3 lore raw

Quoted 16 lines · Suren Baghdasaryan

Quoted 15 lines · Vlastimil Babka
Quoted 12 lines · Suren Baghdasaryan
slab_post_alloc_hook() uses prepare_slab_obj_exts_hook() to obtain slabobj_ext object. Currently the only user of slabobj_ext object in this path is memory allocation profiling, therefore when it's not enabled this object is not needed. This also generates a warning when compiling with CONFIG_MEM_ALLOC_PROFILING=n. Move the code under this configuration to fix the warning. If more slabobj_ext users appear in the future, the code will have to be changed back to call prepare_slab_obj_exts_hook().
Fixes 4b8736964640 ("mm/slab: add allocation accounting into slab allocation and free paths")
Reported-by kernel test robot <[email protected]>
Closes https://lore.kernel.org/oe-kbuild-all/[email protected]/ open here
Signed-off-by Suren Baghdasaryan <[email protected]>

Quoted 8 lines

Quoted 5 lines
Acked-by Vlastimil Babka <[email protected]>
But it seems to me we could remove the whole #ifdef if current->alloc_tag (which doesn't exist with !MEM_ALLOC_PROFILING) had an access helper, or there was a alloc_tag_add_current() variant?
Hmm. I'll check if current->alloc_tag is the only reason for this ifdef. If so then you are correct and we can simplify this code.

The fix is now in mm-hotfixes-stable but we can cleanup for the future as a non-hotfix.

Suren Baghdasaryan

author

2024-07-02 15:16 UTC #4 lore raw

Quoted 24 lines · Vlastimil Babka

Quoted 22 lines · Suren Baghdasaryan
Quoted 20 lines · Vlastimil Babka
Quoted 8 lines · Suren Baghdasaryan
slab_post_alloc_hook() uses prepare_slab_obj_exts_hook() to obtain slabobj_ext object. Currently the only user of slabobj_ext object in this path is memory allocation profiling, therefore when it's not enabled this object is not needed. This also generates a warning when compiling with CONFIG_MEM_ALLOC_PROFILING=n. Move the code under this configuration to fix the warning. If more slabobj_ext users appear in the future, the code will have to be changed back to call prepare_slab_obj_exts_hook().
Quoted 4 lines
Fixes 4b8736964640 ("mm/slab: add allocation accounting into slab allocation and free paths")
Reported-by kernel test robot <[email protected]>
Closes https://lore.kernel.org/oe-kbuild-all/[email protected]/ open here
Signed-off-by Suren Baghdasaryan <[email protected]>
Acked-by Vlastimil Babka <[email protected]>
But it seems to me we could remove the whole #ifdef if current->alloc_tag (which doesn't exist with !MEM_ALLOC_PROFILING) had an access helper, or there was a alloc_tag_add_current() variant?

Quoted 5 lines

Quoted 2 lines
Hmm. I'll check if current->alloc_tag is the only reason for this ifdef. If so then you are correct and we can simplify this code.
The fix is now in mm-hotfixes-stable but we can cleanup for the future as a non-hotfix.

Yes, it's on my TODO list now. Thanks!

Quoted 1 line

Suren Baghdasaryan

author

2024-07-03 01:58 UTC #5 lore raw

Quoted 26 lines · Suren Baghdasaryan

Quoted 24 lines · Vlastimil Babka
Quoted 22 lines · Suren Baghdasaryan
Quoted 20 lines · Vlastimil Babka
Quoted 8 lines · Suren Baghdasaryan
slab_post_alloc_hook() uses prepare_slab_obj_exts_hook() to obtain slabobj_ext object. Currently the only user of slabobj_ext object in this path is memory allocation profiling, therefore when it's not enabled this object is not needed. This also generates a warning when compiling with CONFIG_MEM_ALLOC_PROFILING=n. Move the code under this configuration to fix the warning. If more slabobj_ext users appear in the future, the code will have to be changed back to call prepare_slab_obj_exts_hook().
Quoted 4 lines
Fixes 4b8736964640 ("mm/slab: add allocation accounting into slab allocation and free paths")
Reported-by kernel test robot <[email protected]>
Closes https://lore.kernel.org/oe-kbuild-all/[email protected]/ open here
Signed-off-by Suren Baghdasaryan <[email protected]>
Acked-by Vlastimil Babka <[email protected]>
But it seems to me we could remove the whole #ifdef if current->alloc_tag (which doesn't exist with !MEM_ALLOC_PROFILING) had an access helper, or there was a alloc_tag_add_current() variant?

Quoted 7 lines

Quoted 5 lines
Quoted 2 lines
Hmm. I'll check if current->alloc_tag is the only reason for this ifdef. If so then you are correct and we can simplify this code.
The fix is now in mm-hotfixes-stable but we can cleanup for the future as a non-hotfix.
Yes, it's on my TODO list now. Thanks!

obj_exts->ref was also undefined when !MEM_ALLOC_PROFILING, so I moved that call into a separate hook. It's posted at
https://lore.kernel.org/all/[email protected]/
Thanks,
Suren.

Quoted 2 lines

Quoted 2 lines