[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJuCfpHDeafjETF2RhBvk1CzJ6=D6Xaur90-XUFWo9AJnF1RhQ@mail.gmail.com>
Date: Thu, 11 Jul 2024 11:33:04 -0700
From: Suren Baghdasaryan <surenb@...gle.com>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: akpm@...ux-foundation.org, sxwjean@...com, xiongwei.song@...ux.dev,
willy@...radead.org, nathan@...nel.org, cl@...ux.com, penberg@...nel.org,
rientjes@...gle.com, iamjoonsoo.kim@....com, roman.gushchin@...ux.dev,
42.hyeyoo@...il.com, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
kernel test robot <lkp@...el.com>
Subject: Re: [PATCH 1/1] mm, slab: move prepare_slab_obj_exts_hook under CONFIG_MEM_ALLOC_PROFILING
On Thu, Jul 11, 2024 at 10:21 AM Vlastimil Babka <vbabka@...e.cz> wrote:
>
> On 7/11/24 7:02 PM, Suren Baghdasaryan wrote:
> > The only place prepare_slab_obj_exts_hook() is currently being used is
> > from alloc_tagging_slab_alloc_hook() when CONFIG_MEM_ALLOC_PROFILING=y.
> > Move its definition under CONFIG_MEM_ALLOC_PROFILING to prevent unused
> > function warning for CONFIG_SLAB_OBJ_EXT=n case.
> >
> > Reported-by: kernel test robot <lkp@...el.com>
> > Closes: https://lore.kernel.org/oe-kbuild-all/202407050845.zNONqauD-lkp@intel.com/
>
> Hm so that's a mainline report, but being a clang-only W=1 warning I think
> it can just wait for the merge window and no need for last-minute 6.10 fix.
Correct. I was wrong thinking that [1] caused this. The warning was
there even before but adding this into slab/for-next simply avoids
merge conflicts.
>
> > Signed-off-by: Suren Baghdasaryan <surenb@...gle.com>
> > Cc: Vlastimil Babka <vbabka@...e.cz>
> > ---
> > Applied over slab/for-next because of the refactoring [1] in that branch.
>
> And thus took it there. thanks.
Thanks!
>
> >
> > [1] 302a3ea38aec ("mm, slab: move allocation tagging code in the alloc path into a hook")
> >
> > mm/slub.c | 48 +++++++++++++++++++++---------------------------
> > 1 file changed, 21 insertions(+), 27 deletions(-)
> >
> > diff --git a/mm/slub.c b/mm/slub.c
> > index ce39544acf7c..829a1f08e8a2 100644
> > --- a/mm/slub.c
> > +++ b/mm/slub.c
> > @@ -2027,6 +2027,27 @@ static inline bool need_slab_obj_ext(void)
> > return false;
> > }
> >
> > +#else /* CONFIG_SLAB_OBJ_EXT */
> > +
> > +static int alloc_slab_obj_exts(struct slab *slab, struct kmem_cache *s,
> > + gfp_t gfp, bool new_slab)
> > +{
> > + return 0;
> > +}
> > +
> > +static inline void free_slab_obj_exts(struct slab *slab)
> > +{
> > +}
> > +
> > +static inline bool need_slab_obj_ext(void)
> > +{
> > + return false;
> > +}
> > +
> > +#endif /* CONFIG_SLAB_OBJ_EXT */
> > +
> > +#ifdef CONFIG_MEM_ALLOC_PROFILING
> > +
> > static inline struct slabobj_ext *
> > prepare_slab_obj_exts_hook(struct kmem_cache *s, gfp_t flags, void *p)
> > {
> > @@ -2051,33 +2072,6 @@ prepare_slab_obj_exts_hook(struct kmem_cache *s, gfp_t flags, void *p)
> > return slab_obj_exts(slab) + obj_to_index(s, slab, p);
> > }
> >
> > -#else /* CONFIG_SLAB_OBJ_EXT */
> > -
> > -static int alloc_slab_obj_exts(struct slab *slab, struct kmem_cache *s,
> > - gfp_t gfp, bool new_slab)
> > -{
> > - return 0;
> > -}
> > -
> > -static inline void free_slab_obj_exts(struct slab *slab)
> > -{
> > -}
> > -
> > -static inline bool need_slab_obj_ext(void)
> > -{
> > - return false;
> > -}
> > -
> > -static inline struct slabobj_ext *
> > -prepare_slab_obj_exts_hook(struct kmem_cache *s, gfp_t flags, void *p)
> > -{
> > - return NULL;
> > -}
> > -
> > -#endif /* CONFIG_SLAB_OBJ_EXT */
> > -
> > -#ifdef CONFIG_MEM_ALLOC_PROFILING
> > -
> > static inline void
> > alloc_tagging_slab_alloc_hook(struct kmem_cache *s, void *object, gfp_t flags)
> > {
> >
> > base-commit: fe4e761669ab4d8b388fdb6e9dbe9a110eed8009
>
Powered by blists - more mailing lists