| Message ID | 20231113191340.17482-33-vbabka@suse.cz (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | remove the SLAB allocator | expand |
On Mon, Nov 13, 2023 at 08:13:52PM +0100, Vlastimil Babka wrote: > The #include's are scattered at several places of the file, but it does > not seem this is needed to prevent any include loops (anymore?) so > consolidate them at the top. Also move the misplaced kmem_cache_init() > declaration away from the top. > > Signed-off-by: Vlastimil Babka <vbabka@suse.cz> > --- > mm/slab.h | 28 ++++++++++++++-------------- > 1 file changed, 14 insertions(+), 14 deletions(-) > > diff --git a/mm/slab.h b/mm/slab.h > index 6e76216ac74e..c278f8b15251 100644 > --- a/mm/slab.h > +++ b/mm/slab.h > @@ -1,10 +1,22 @@ > /* SPDX-License-Identifier: GPL-2.0 */ > #ifndef MM_SLAB_H > #define MM_SLAB_H > + > +#include <linux/reciprocal_div.h> > +#include <linux/list_lru.h> > +#include <linux/local_lock.h> > +#include <linux/random.h> > +#include <linux/kobject.h> > +#include <linux/sched/mm.h> > +#include <linux/memcontrol.h> > +#include <linux/fault-inject.h> > +#include <linux/kmemleak.h> > +#include <linux/kfence.h> > +#include <linux/kasan.h> I've seen kernel code style in other places ask that includes be organized alphabetically. Is the order here in this order for some particular reason?
On 11/14/23 05:41, Kees Cook wrote: > On Mon, Nov 13, 2023 at 08:13:52PM +0100, Vlastimil Babka wrote: >> The #include's are scattered at several places of the file, but it does >> not seem this is needed to prevent any include loops (anymore?) so >> consolidate them at the top. Also move the misplaced kmem_cache_init() >> declaration away from the top. >> >> Signed-off-by: Vlastimil Babka <vbabka@suse.cz> >> --- >> mm/slab.h | 28 ++++++++++++++-------------- >> 1 file changed, 14 insertions(+), 14 deletions(-) >> >> diff --git a/mm/slab.h b/mm/slab.h >> index 6e76216ac74e..c278f8b15251 100644 >> --- a/mm/slab.h >> +++ b/mm/slab.h >> @@ -1,10 +1,22 @@ >> /* SPDX-License-Identifier: GPL-2.0 */ >> #ifndef MM_SLAB_H >> #define MM_SLAB_H >> + >> +#include <linux/reciprocal_div.h> >> +#include <linux/list_lru.h> >> +#include <linux/local_lock.h> >> +#include <linux/random.h> >> +#include <linux/kobject.h> >> +#include <linux/sched/mm.h> >> +#include <linux/memcontrol.h> >> +#include <linux/fault-inject.h> >> +#include <linux/kmemleak.h> >> +#include <linux/kfence.h> >> +#include <linux/kasan.h> > > I've seen kernel code style in other places ask that includes be > organized alphabetically. Is the order here in this order for some > particular reason? Hm not aware of the alphabetical suggestion. I usually order by going from more low-level and self-contained headers to the more complex ones that transitively include more, so did that here as well but it's not a precise process.
diff --git a/mm/slab.h b/mm/slab.h index 6e76216ac74e..c278f8b15251 100644 --- a/mm/slab.h +++ b/mm/slab.h @@ -1,10 +1,22 @@ /* SPDX-License-Identifier: GPL-2.0 */ #ifndef MM_SLAB_H #define MM_SLAB_H + +#include <linux/reciprocal_div.h> +#include <linux/list_lru.h> +#include <linux/local_lock.h> +#include <linux/random.h> +#include <linux/kobject.h> +#include <linux/sched/mm.h> +#include <linux/memcontrol.h> +#include <linux/fault-inject.h> +#include <linux/kmemleak.h> +#include <linux/kfence.h> +#include <linux/kasan.h> + /* * Internal slab definitions */ -void __init kmem_cache_init(void); #ifdef CONFIG_64BIT # ifdef system_has_cmpxchg128 @@ -209,11 +221,6 @@ static inline size_t slab_size(const struct slab *slab) return PAGE_SIZE << slab_order(slab); } -#include <linux/kfence.h> -#include <linux/kobject.h> -#include <linux/reciprocal_div.h> -#include <linux/local_lock.h> - #ifdef CONFIG_SLUB_CPU_PARTIAL #define slub_percpu_partial(c) ((c)->partial) @@ -346,14 +353,6 @@ static inline int objs_per_slab(const struct kmem_cache *cache, return slab->objects; } -#include <linux/memcontrol.h> -#include <linux/fault-inject.h> -#include <linux/kasan.h> -#include <linux/kmemleak.h> -#include <linux/random.h> -#include <linux/sched/mm.h> -#include <linux/list_lru.h> - /* * State of the slab allocator. * @@ -404,6 +403,7 @@ gfp_t kmalloc_fix_flags(gfp_t flags); /* Functions provided by the slab allocators */ int __kmem_cache_create(struct kmem_cache *, slab_flags_t flags); +void __init kmem_cache_init(void); void __init new_kmalloc_cache(int idx, enum kmalloc_cache_type type, slab_flags_t flags); extern void create_boot_cache(struct kmem_cache *, const char *name,
The #include's are scattered at several places of the file, but it does not seem this is needed to prevent any include loops (anymore?) so consolidate them at the top. Also move the misplaced kmem_cache_init() declaration away from the top. Signed-off-by: Vlastimil Babka <vbabka@suse.cz> --- mm/slab.h | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-)