[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

[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 at lists.infradead.org
Cc: linux-mm at kvack.org
Cc: linuxppc-dev at lists.ozlabs.org
Cc: netdev at vger.kernel.org
Cc: netfilter-devel at vger.kernel.org
Cc: x86 at 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

[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 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 01/11] mm: replace module_init usages with subsys_initcall in nommu.c

[Paul Gortmaker]

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 <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 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);
-- 
2.2.1

[PATCH 01/11] mm: replace module_init usages with subsys_initcall in nommu.c

[Paul Gortmaker]

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 <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 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);
-- 
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 02/11] fs/notify: don't use module_init for non-modular inotify_user code

[Paul Gortmaker]

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 <john@johnmccutchan.com>
Cc: Robert Love <rlove@rlove.org>
Cc: Eric Paris <eparis@parisplace.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 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 <linux/fs.h> /* struct inode */
 #include <linux/fsnotify_backend.h>
 #include <linux/idr.h>
-#include <linux/init.h> /* module_init */
+#include <linux/init.h> /* fs_initcall */
 #include <linux/inotify.h>
 #include <linux/kernel.h> /* roundup() */
 #include <linux/namei.h> /* 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);
-- 
2.2.1

[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.
> 

[PATCH 04/11] x86: don't use module_init for non-modular core bootflag code

[Paul Gortmaker]

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 <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 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);
-- 
2.2.1

[PATCH 05/11] powerpc: use subsys_initcall for Freescale Local Bus

[Paul Gortmaker]

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 <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Scott Wood <scottwood@freescale.com>
Acked-by: Scott Wood <scottwood@freescale.com>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 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);
-- 
2.2.1

[PATCH 06/11] powerpc: don't use module_init for non-modular core hugetlb code

[Paul Gortmaker]

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 <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 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)
 {
-- 
2.2.1

[PATCH 07/11] arm: use subsys_initcall in non-modular pl320 IPC code

[Paul Gortmaker]

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 <linux@arm.linux.org.uk>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 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);
-- 
2.2.1

[PATCH 07/11] arm: use subsys_initcall in non-modular pl320 IPC code

[Paul Gortmaker]

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 <linux@arm.linux.org.uk>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 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);
-- 
2.2.1

[PATCH 08/11] lib/list_sort: use late_initcall to hook in self tests

[Paul Gortmaker]

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 <akpm@linux-foundation.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 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 @@ exit:
 	kfree(elts);
 	return err;
 }
-module_init(list_sort_test);
+late_initcall(list_sort_test);
 #endif /* CONFIG_TEST_LIST_SORT */
-- 
2.2.1

[PATCH 09/11] mm/page_owner.c: use late_initcall to hook in enabling

[Paul Gortmaker]

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 <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 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)
-- 
2.2.1

[PATCH 09/11] mm/page_owner.c: use late_initcall to hook in enabling

[Paul Gortmaker]

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 <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 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)
-- 
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 10/11] x86: perf_event_intel_bts.c: use arch_initcall to hook in enabling

[Paul Gortmaker]

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.

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 <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 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);
-- 
2.2.1

Re: [PATCH 10/11] x86: perf_event_intel_bts.c: use arch_initcall to hook in enabling

[Peter Zijlstra]

On Sun, May 31, 2015 at 08:54:11PM -0400, Paul Gortmaker wrote:
> This was using module_init, but there is no way this code can
> be modular.  

No, I think you could actually make it modular if you really wanted to.

Re: [PATCH 10/11] x86: perf_event_intel_bts.c: use arch_initcall to hook in enabling

[Paul Gortmaker]

On 15-06-01 03:04 AM, Peter Zijlstra wrote:
> On Sun, May 31, 2015 at 08:54:11PM -0400, Paul Gortmaker wrote:
>> This was using module_init, but there is no way this code can
>> be modular.  
> 
> No, I think you could actually make it modular if you really wanted to.

By "really wanted to" -- do you mean future changes that someone might do?

Since currently, I can't see how this could be modular.  We have...

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 this seems always built in to me, in the current code base.

Paul.

Re: [PATCH 10/11] x86: perf_event_intel_bts.c: use arch_initcall to hook in enabling

[Peter Zijlstra]

On Mon, 2015-06-01 at 10:11 -0400, Paul Gortmaker wrote:
> On 15-06-01 03:04 AM, Peter Zijlstra wrote:
> > On Sun, May 31, 2015 at 08:54:11PM -0400, Paul Gortmaker wrote:
> >> This was using module_init, but there is no way this code can
> >> be modular.  
> > 
> > No, I think you could actually make it modular if you really wanted to.
> 
> By "really wanted to" -- do you mean future changes that someone might do?

Yeah, I think we read "no way this code can be modular" differently.

I'm reading it like; it can easily be, all it requires is this little
patch, where you're reading it like Kconfig changes.

Re: [PATCH 10/11] x86: perf_event_intel_bts.c: use arch_initcall to hook in enabling

[Paul Gortmaker]

On 15-06-01 10:14 AM, Peter Zijlstra wrote:
> On Mon, 2015-06-01 at 10:11 -0400, Paul Gortmaker wrote:
>> On 15-06-01 03:04 AM, Peter Zijlstra wrote:
>>> On Sun, May 31, 2015 at 08:54:11PM -0400, Paul Gortmaker wrote:
>>>> This was using module_init, but there is no way this code can
>>>> be modular.  
>>>
>>> No, I think you could actually make it modular if you really wanted to.
>>
>> By "really wanted to" -- do you mean future changes that someone might do?
> 
> Yeah, I think we read "no way this code can be modular" differently.
> 
> I'm reading it like; it can easily be, all it requires is this little
> patch, where you're reading it like Kconfig changes.

OK, so how about I update both logs with something like this, to
clarify I meant "no way this code can be modular currently, given
the existing Kconfig situation":

----------------------8<---------------------------

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 <linux/module.h> 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.

 
----------------------8<----------------------------------

Paul.

> 
> 

Re: [PATCH 10/11] x86: perf_event_intel_bts.c: use arch_initcall to hook in enabling

[Peter Zijlstra]

On Mon, Jun 01, 2015 at 11:35:18AM -0400, Paul Gortmaker wrote:
> OK, so how about I update both logs with something like this, to
> clarify I meant "no way this code can be modular currently, given
> the existing Kconfig situation":

That looks good to me; thanks!

[PATCH 11/11] x86: perf_event_intel_pt.c: use arch_initcall to hook in enabling

[Paul Gortmaker]

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.

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 <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 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 ffe666c2c6b5..201d010ab87e 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_pt.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_pt.c
@@ -1096,5 +1096,4 @@ static __init int pt_init(void)
 
 	return ret;
 }
-
-module_init(pt_init);
+arch_initcall(pt_init);
-- 
2.2.1

Re: [PATCH 11/11] x86: perf_event_intel_pt.c: use arch_initcall to hook in enabling

[Peter Zijlstra]

On Sun, May 31, 2015 at 08:54:12PM -0400, Paul Gortmaker wrote:
> This was using module_init, but there is no way this code can
> be modular.

Same thing; you could actually make this modular if you wanted to.

Re: [PATCH 11/11] x86: perf_event_intel_pt.c: use arch_initcall to hook in enabling

[Paul Gortmaker]

On 15-06-01 03:05 AM, Peter Zijlstra wrote:
> On Sun, May 31, 2015 at 08:54:12PM -0400, Paul Gortmaker wrote:
>> This was using module_init, but there is no way this code can
>> be modular.
> 
> Same thing; you could actually make this modular if you wanted to.
> 

..and this file is even in the same Makefile line of the prev. one:

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 again, unless I'm missing something obvious (entirely possible
for a Monday) this too seems always built in to me.

Paul.