[PATCH 00/11] Replace module_init with an alternate initcall in non modules

[PATCH 00/11] Replace module_init with an alternate initcall in non modules

[Paul Gortmaker]

This series of commits converts non-modular code that is using the
module_init() call to hook itself into the system to instead use one of
the alternate priority initcalls.

Unlike the earlier series[1] that used device_initcall and hence was a
runtime no-op, these commits change to one of the alternate initcalls,
because (a) we have them and (b) it seems like the right thing to do.
For example, it would seem logical to use arch_initcall for arch
specific setup code and fs_initcall for filesystem setup code.

This does mean however, that changes in the init ordering will be taking
place, and so there is a small risk that some kind of implicit init
ordering issue may lie uncovered.  But I think it is still better to
give these ones sensible priorities than to just assign them all to
device_initcall in order to exactly preserve the old ordering.

Thad said, we have already made similar changes in core kernel code
in commit c96d6660dc65b0a90aea9834bfd8be1d5656da18 ("kernel: audit/fix
non-modular users of module_init in core code") without any regressions
reported, so this type of change isn't without precedent.

This work is factored out from what was a previously larger series[2] so
that there is a common theme and lower patch count to ease review.

Paul.

[1] https://lkml.org/lkml/2015/5/28/809
[2] https://marc.info/?l=linux-kernel&m=139033951228828

---

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Paris <eparis@parisplace.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: John McCutchan <john@johnmccutchan.com>
Cc: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Patrick McHardy <kaber@trash.net>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Robert Love <rlove@rlove.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mm@kvack.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: netdev@vger.kernel.org
Cc: netfilter-devel@vger.kernel.org
Cc: x86@kernel.org


Paul Gortmaker (11):
  mm: replace module_init usages with subsys_initcall in nommu.c
  fs/notify: don't use module_init for non-modular inotify_user code
  netfilter: don't use module_init/exit in core IPV4 code
  x86: don't use module_init for non-modular core bootflag code
  powerpc: use subsys_initcall for Freescale Local Bus
  powerpc: don't use module_init for non-modular core hugetlb code
  arm: use subsys_initcall in non-modular pl320 IPC code
  lib/list_sort: use late_initcall to hook in self tests
  mm/page_owner.c: use late_initcall to hook in enabling
  x86: perf_event_intel_bts.c: use arch_initcall to hook in enabling
  x86: perf_event_intel_pt.c: use arch_initcall to hook in enabling

 arch/powerpc/mm/hugetlbpage.c              | 2 +-
 arch/powerpc/sysdev/fsl_lbc.c              | 2 +-
 arch/x86/kernel/bootflag.c                 | 2 +-
 arch/x86/kernel/cpu/perf_event_intel_bts.c | 3 +--
 arch/x86/kernel/cpu/perf_event_intel_pt.c  | 3 +--
 drivers/mailbox/pl320-ipc.c                | 2 +-
 fs/notify/inotify/inotify_user.c           | 4 ++--
 lib/list_sort.c                            | 2 +-
 mm/nommu.c                                 | 4 ++--
 mm/page_owner.c                            | 2 +-
 net/ipv4/netfilter.c                       | 9 +--------
 11 files changed, 13 insertions(+), 22 deletions(-)

-- 
2.2.1

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH 03/11] netfilter: don't use module_init/exit in core IPV4 code

[Paul Gortmaker]

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 <pablo@netfilter.org>
Cc: Patrick McHardy <kaber@trash.net>
Cc: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netfilter-devel@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 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);
-- 
2.2.1

Re: [PATCH 03/11] netfilter: don't use module_init/exit in core IPV4 code

[Pablo Neira Ayuso]

On Sun, May 31, 2015 at 08:54:04PM -0400, Paul Gortmaker wrote:
> 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 <pablo@netfilter.org>
> Cc: Patrick McHardy <kaber@trash.net>
> Cc: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: netfilter-devel@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>

Or I can integrate this into the nf-next tree if you prefer it.

Thanks.

Re: [PATCH 03/11] netfilter: don't use module_init/exit in core IPV4 code

[Paul Gortmaker]

On 15-06-03 12:04 PM, Pablo Neira Ayuso wrote:
> On Sun, May 31, 2015 at 08:54:04PM -0400, Paul Gortmaker wrote:
>> 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 <pablo@netfilter.org>
>> Cc: Patrick McHardy <kaber@trash.net>
>> Cc: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
>> Cc: "David S. Miller" <davem@davemloft.net>
>> Cc: netfilter-devel@vger.kernel.org
>> Cc: netdev@vger.kernel.org
>> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> 
> Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>
> 
> Or I can integrate this into the nf-next tree if you prefer it.

I need to keep it in my series to avoid introducing compile
fails into the bisect history, so I'll just add your Ack.

Thanks,
Paul.
--

> 
> Thanks.
>