From a4bc6fc79f94c5b4f850aabca9c5249adc597094 Mon Sep 17 00:00:00 2001 From: Paul Gortmaker Date: Fri, 1 May 2015 20:08:20 -0400 Subject: [PATCH 01/11] mm: replace module_init usages with subsys_initcall in nommu.c Compiling some arm/m68k configs with "# CONFIG_MMU is not set" reveals two more instances of module_init being used for code that can't possibly be modular, as CONFIG_MMU is either on or off. We replace them with subsys_initcall as per what was done in other mmu-enabled code. Note that direct use of __initcall is discouraged, vs. one of the priority categorized subgroups. As __initcall gets mapped onto device_initcall, our use of subsys_initcall (which makes sense for these files) will thus change this registration from level 6-device to level 4-subsys (i.e. slightly earlier). One might think that core_initcall (l2) or postcore_initcall (l3) would be more appropriate for anything in mm/ but if we look at the actual init functions themselves, we see they are just sysctl setup stuff, and hence the choice of subsys_initcall (l4) seems reasonable. At the same time it minimizes the risk of changing the priority too drastically all at once. We can adjust further in the future. Also, a couple instances of missing ";" at EOL are fixed. Cc: Andrew Morton Cc: linux-mm@kvack.org Signed-off-by: Paul Gortmaker --- mm/nommu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/nommu.c b/mm/nommu.c index e544508e2a4b..e7b24dcec505 100644 --- a/mm/nommu.c +++ b/mm/nommu.c @@ -2157,7 +2157,7 @@ static int __meminit init_user_reserve(void) sysctl_user_reserve_kbytes = min(free_kbytes / 32, 1UL << 17); return 0; } -module_init(init_user_reserve) +subsys_initcall(init_user_reserve); /* * Initialise sysctl_admin_reserve_kbytes. @@ -2178,4 +2178,4 @@ static int __meminit init_admin_reserve(void) sysctl_admin_reserve_kbytes = min(free_kbytes / 32, 1UL << 13); return 0; } -module_init(init_admin_reserve) +subsys_initcall(init_admin_reserve); From c013d5a4581203e074a1065e17378984544fcaef Mon Sep 17 00:00:00 2001 From: Paul Gortmaker Date: Fri, 1 May 2015 20:08:20 -0400 Subject: [PATCH 02/11] fs/notify: don't use module_init for non-modular inotify_user code The INOTIFY_USER option is bool, and hence this code is either present or absent. It will never be modular, so using module_init as an alias for __initcall is rather misleading. Fix this up now, so that we can relocate module_init from init.h into module.h in the future. If we don't do this, we'd have to add module.h to obviously non-modular code, and that would be a worse thing. Note that direct use of __initcall is discouraged, vs. one of the priority categorized subgroups. As __initcall gets mapped onto device_initcall, our use of fs_initcall (which makes sense for fs code) will thus change this registration from level 6-device to level 5-fs (i.e. slightly earlier). However no observable impact of that small difference has been observed during testing, or is expected. Cc: John McCutchan Cc: Robert Love Cc: Eric Paris Signed-off-by: Paul Gortmaker --- fs/notify/inotify/inotify_user.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/notify/inotify/inotify_user.c b/fs/notify/inotify/inotify_user.c index 450648697433..5b1e2a497e51 100644 --- a/fs/notify/inotify/inotify_user.c +++ b/fs/notify/inotify/inotify_user.c @@ -26,7 +26,7 @@ #include /* struct inode */ #include #include -#include /* module_init */ +#include /* fs_initcall */ #include #include /* roundup() */ #include /* LOOKUP_FOLLOW */ @@ -812,4 +812,4 @@ static int __init inotify_user_setup(void) return 0; } -module_init(inotify_user_setup); +fs_initcall(inotify_user_setup); From 55331060096f0e9a57356ec36476a49e4bf22bc1 Mon Sep 17 00:00:00 2001 From: Paul Gortmaker Date: Fri, 1 May 2015 20:08:20 -0400 Subject: [PATCH 03/11] netfilter: don't use module_init/exit in core IPV4 code The file net/ipv4/netfilter.o is created based on whether CONFIG_NETFILTER is set. However that is defined as a bool, and hence this file with the core netfilter hooks will never be modular. So using module_init as an alias for __initcall can be somewhat misleading. Fix this up now, so that we can relocate module_init from init.h into module.h in the future. If we don't do this, we'd have to add module.h to obviously non-modular code, and that would be a worse thing. Also add an inclusion of init.h, as that was previously implicit here in the netfilter.c file. Note that direct use of __initcall is discouraged, vs. one of the priority categorized subgroups. As __initcall gets mapped onto device_initcall, our use of subsys_initcall (which seems to make sense for netfilter code) will thus change this registration from level 6-device to level 4-subsys (i.e. slightly earlier). However no observable impact of that small difference has been observed during testing, or is expected. (i.e. the location of the netfilter messages in dmesg remains unchanged with respect to all the other surrounding messages.) As for the module_exit, rather than replace it with __exitcall, we simply remove it, since it appears only UML does anything with those, and even for UML, there is no relevant cleanup to be done here. Cc: Pablo Neira Ayuso Acked-by: Pablo Neira Ayuso Cc: Patrick McHardy Cc: Jozsef Kadlecsik Cc: "David S. Miller" Cc: netfilter-devel@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Paul Gortmaker --- net/ipv4/netfilter.c | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/net/ipv4/netfilter.c b/net/ipv4/netfilter.c index 65de0684e22a..61eafc9b4545 100644 --- a/net/ipv4/netfilter.c +++ b/net/ipv4/netfilter.c @@ -197,11 +197,4 @@ static int __init ipv4_netfilter_init(void) { return nf_register_afinfo(&nf_ip_afinfo); } - -static void __exit ipv4_netfilter_fini(void) -{ - nf_unregister_afinfo(&nf_ip_afinfo); -} - -module_init(ipv4_netfilter_init); -module_exit(ipv4_netfilter_fini); +subsys_initcall(ipv4_netfilter_init); From 1206f53589237b7e00b9b0a4e42815f14aedad2d Mon Sep 17 00:00:00 2001 From: Paul Gortmaker Date: Fri, 1 May 2015 20:08:21 -0400 Subject: [PATCH 04/11] x86: don't use module_init for non-modular core bootflag code The bootflag.o is obj-y (always built in). It will never be modular, so using module_init as an alias for __initcall is somewhat misleading. Fix this up now, so that we can relocate module_init from init.h into module.h in the future. If we don't do this, we'd have to add module.h to obviously non-modular code, and that would be a worse thing. Note that direct use of __initcall is discouraged, vs. one of the priority categorized subgroups. As __initcall gets mapped onto device_initcall, our use of arch_initcall (which makes sense for arch code) will thus change this registration from level 6-device to level 3-arch (i.e. slightly earlier). However no observable impact of that small difference has been observed during testing, or is expected. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x86@kernel.org Signed-off-by: Paul Gortmaker --- arch/x86/kernel/bootflag.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/bootflag.c b/arch/x86/kernel/bootflag.c index 5de7f4c56971..52c8e3c7789d 100644 --- a/arch/x86/kernel/bootflag.c +++ b/arch/x86/kernel/bootflag.c @@ -98,4 +98,4 @@ static int __init sbf_init(void) return 0; } -module_init(sbf_init); +arch_initcall(sbf_init); From 383d14a5365879bc193d29ad2ed17ac5299753c3 Mon Sep 17 00:00:00 2001 From: Paul Gortmaker Date: Fri, 1 May 2015 20:08:21 -0400 Subject: [PATCH 05/11] powerpc: use subsys_initcall for Freescale Local Bus The FSL_SOC option is bool, and hence this code is either present or absent. It will never be modular, so using module_init as an alias for __initcall is rather misleading. Fix this up now, so that we can relocate module_init from init.h into module.h in the future. If we don't do this, we'd have to add module.h to obviously non-modular code, and that would be a worse thing. Note that direct use of __initcall is discouraged, vs. one of the priority categorized subgroups. As __initcall gets mapped onto device_initcall, our use of subsys_initcall (which makes sense for bus code) will thus change this registration from level 6-device to level 4-subsys (i.e. slightly earlier). However no observable impact of that small difference has been observed during testing, or is expected. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Scott Wood Acked-by: Scott Wood Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Paul Gortmaker --- arch/powerpc/sysdev/fsl_lbc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/sysdev/fsl_lbc.c b/arch/powerpc/sysdev/fsl_lbc.c index d631022ffb4b..38138cf8d33e 100644 --- a/arch/powerpc/sysdev/fsl_lbc.c +++ b/arch/powerpc/sysdev/fsl_lbc.c @@ -407,4 +407,4 @@ static int __init fsl_lbc_init(void) { return platform_driver_register(&fsl_lbc_ctrl_driver); } -module_init(fsl_lbc_init); +subsys_initcall(fsl_lbc_init); From 6f114281c4ad543392f5b7c8345e11e103675cee Mon Sep 17 00:00:00 2001 From: Paul Gortmaker Date: Fri, 1 May 2015 20:08:21 -0400 Subject: [PATCH 06/11] powerpc: don't use module_init for non-modular core hugetlb code The hugetlbpage.o is obj-y (always built in). It will never be modular, so using module_init as an alias for __initcall is somewhat misleading. Fix this up now, so that we can relocate module_init from init.h into module.h in the future. If we don't do this, we'd have to add module.h to obviously non-modular code, and that would be a worse thing. Note that direct use of __initcall is discouraged, vs. one of the priority categorized subgroups. As __initcall gets mapped onto device_initcall, our use of arch_initcall (which makes sense for arch code) will thus change this registration from level 6-device to level 3-arch (i.e. slightly earlier). However no observable impact of that small difference has been observed during testing, or is expected. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Paul Gortmaker --- arch/powerpc/mm/hugetlbpage.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c index 3385e3d0506e..f1e00ac9283c 100644 --- a/arch/powerpc/mm/hugetlbpage.c +++ b/arch/powerpc/mm/hugetlbpage.c @@ -933,7 +933,7 @@ static int __init hugetlbpage_init(void) return 0; } #endif -module_init(hugetlbpage_init); +arch_initcall(hugetlbpage_init); void flush_dcache_icache_hugepage(struct page *page) { From 89f08f64408b630df7d559223f63e616d0814509 Mon Sep 17 00:00:00 2001 From: Paul Gortmaker Date: Fri, 1 May 2015 20:08:21 -0400 Subject: [PATCH 07/11] arm: use subsys_initcall in non-modular pl320 IPC code The drivers/mailbox/pl320-ipc.o is dependent on config PL320_MBOX which is declared as a bool. Hence the code is never going to be modular. So using module_init as an alias for __initcall can be somewhat misleading. Fix this up now, so that we can relocate module_init from init.h into module.h in the future. If we don't do this, we'd have to add module.h to obviously non-modular code, and that would be a worse thing. Also add an inclusion of init.h, as that was previously implicit. Note that direct use of __initcall is discouraged, vs. one of the priority categorized subgroups. As __initcall gets mapped onto device_initcall, our use of subsys_initcall (which seems to make sense for IPC code) will thus change this registration from level 6-device to level 4-subsys (i.e. slightly earlier). However no impact of that small difference is expected. Cc: Russell King Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Paul Gortmaker --- drivers/mailbox/pl320-ipc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mailbox/pl320-ipc.c b/drivers/mailbox/pl320-ipc.c index f3755e0aa935..f80acb36ff07 100644 --- a/drivers/mailbox/pl320-ipc.c +++ b/drivers/mailbox/pl320-ipc.c @@ -195,4 +195,4 @@ static int __init ipc_init(void) { return amba_driver_register(&pl320_driver); } -module_init(ipc_init); +subsys_initcall(ipc_init); From 4c7217f1f0fe70af7b9e213ef16f1d2f4a4bacaf Mon Sep 17 00:00:00 2001 From: Paul Gortmaker Date: Fri, 1 May 2015 21:57:34 -0400 Subject: [PATCH 08/11] lib/list_sort: use late_initcall to hook in self tests This was using module_init, but there is no way this code can be modular. In the non-modular case, a module_init becomes a device_initcall, but this really isn't a device. So we should choose a more appropriate initcall bucket to put it in. Assuming boot time self tests need to be observed over a console to be useful, and that the console device could possibly not be fully functional until after device_initcall, we move this to the late_initcall bucket, which is immediately after device_initcall. Cc: Andrew Morton Signed-off-by: Paul Gortmaker --- lib/list_sort.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/list_sort.c b/lib/list_sort.c index b29015102698..3fe401067e20 100644 --- a/lib/list_sort.c +++ b/lib/list_sort.c @@ -289,5 +289,5 @@ static int __init list_sort_test(void) kfree(elts); return err; } -module_init(list_sort_test); +late_initcall(list_sort_test); #endif /* CONFIG_TEST_LIST_SORT */ From 44c5af96de8230ff7268500f48995f9fea5cffe7 Mon Sep 17 00:00:00 2001 From: Paul Gortmaker Date: Fri, 1 May 2015 21:57:34 -0400 Subject: [PATCH 09/11] mm/page_owner.c: use late_initcall to hook in enabling This was using module_init, but there is no way this code can be modular. In the non-modular case, a module_init becomes a device_initcall, but this really isn't a device. So we should choose a more appropriate initcall bucket to put it in. In order of execution, our close choices are: fs_initcall(fn) rootfs_initcall(fn) device_initcall(fn) late_initcall(fn) ..and since the initcall here goes after debugfs, we really should be post-rootfs, which means late_initcall makes the most sense here. Cc: Andrew Morton Cc: linux-mm@kvack.org Signed-off-by: Paul Gortmaker --- mm/page_owner.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/page_owner.c b/mm/page_owner.c index 0993f5f36b01..bd5f842b56d2 100644 --- a/mm/page_owner.c +++ b/mm/page_owner.c @@ -310,4 +310,4 @@ static int __init pageowner_init(void) return 0; } -module_init(pageowner_init) +late_initcall(pageowner_init) From ca41d24cf56458a699b44e918c5a19b7077df422 Mon Sep 17 00:00:00 2001 From: Paul Gortmaker Date: Fri, 1 May 2015 21:57:34 -0400 Subject: [PATCH 10/11] x86: perf_event_intel_bts.c: use arch_initcall to hook in enabling This was using module_init, but the current Kconfig situation is as follows: In arch/x86/kernel/cpu/Makefile: obj-$(CONFIG_CPU_SUP_INTEL) += perf_event_intel_pt.o perf_event_intel_bts.o and in arch/x86/Kconfig.cpu: config CPU_SUP_INTEL default y bool "Support Intel processors" if PROCESSOR_SELECT So currently, the end user can not build this code into a module. If in the future, there is desire for this to be modular, then it can be changed to include and use module_init. But currently, in the non-modular case, a module_init becomes a device_initcall. But this really isn't a device, so we should choose a more appropriate initcall bucket to put it in. The obvious choice here seems to be arch_initcall, but that does make it earlier than it was currently through device_initcall. As long as perf_pmu_register() is functional, we should be OK. Cc: Peter Zijlstra Cc: Paul Mackerras Cc: Ingo Molnar Cc: Arnaldo Carvalho de Melo Cc: Thomas Gleixner Cc: "H. Peter Anvin" Cc: x86@kernel.org Signed-off-by: Paul Gortmaker --- arch/x86/kernel/cpu/perf_event_intel_bts.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/x86/kernel/cpu/perf_event_intel_bts.c b/arch/x86/kernel/cpu/perf_event_intel_bts.c index ac1f0c55f379..7b2fec86dead 100644 --- a/arch/x86/kernel/cpu/perf_event_intel_bts.c +++ b/arch/x86/kernel/cpu/perf_event_intel_bts.c @@ -521,5 +521,4 @@ static __init int bts_init(void) return perf_pmu_register(&bts_pmu, "intel_bts", -1); } - -module_init(bts_init); +arch_initcall(bts_init); From 5b00c1eb94e5936e5bf5cdd9ad1ddfbed0c39159 Mon Sep 17 00:00:00 2001 From: Paul Gortmaker Date: Fri, 1 May 2015 21:57:34 -0400 Subject: [PATCH 11/11] x86: perf_event_intel_pt.c: use arch_initcall to hook in enabling This was using module_init, but the current Kconfig situation is as follows: In arch/x86/kernel/cpu/Makefile: obj-$(CONFIG_CPU_SUP_INTEL) += perf_event_intel_pt.o perf_event_intel_bts.o and in arch/x86/Kconfig.cpu: config CPU_SUP_INTEL default y bool "Support Intel processors" if PROCESSOR_SELECT So currently, the end user can not build this code into a module. If in the future, there is desire for this to be modular, then it can be changed to include and use module_init. But currently, in the non-modular case, a module_init becomes a device_initcall. But this really isn't a device, so we should choose a more appropriate initcall bucket to put it in. The obvious choice here seems to be arch_initcall, but that does make it earlier than it was currently through device_initcall. As long as perf_pmu_register() is functional, we should be OK. Cc: Peter Zijlstra Cc: Paul Mackerras Cc: Ingo Molnar Cc: Arnaldo Carvalho de Melo Cc: Thomas Gleixner Cc: "H. Peter Anvin" Cc: x86@kernel.org Signed-off-by: Paul Gortmaker --- arch/x86/kernel/cpu/perf_event_intel_pt.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/x86/kernel/cpu/perf_event_intel_pt.c b/arch/x86/kernel/cpu/perf_event_intel_pt.c index 123ff1bb2f60..0d52d76f1397 100644 --- a/arch/x86/kernel/cpu/perf_event_intel_pt.c +++ b/arch/x86/kernel/cpu/perf_event_intel_pt.c @@ -1106,5 +1106,4 @@ static __init int pt_init(void) return ret; } - -module_init(pt_init); +arch_initcall(pt_init);