linux-modules.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] modules: move module symbols from init/Kconfig
@ 2022-07-11 16:20 Luis Chamberlain
  2022-07-11 18:33 ` Christophe Leroy
  0 siblings, 1 reply; 6+ messages in thread
From: Luis Chamberlain @ 2022-07-11 16:20 UTC (permalink / raw)
  To: linux-modules, linux-kernel; +Cc: atomlin, christophe.leroy, Luis Chamberlain

This moves all the module symbols from init/Kconfig to its
own dedicated file now that we have all of the module code in
its own directory.

This does not introduce any functional changes.

Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
---
 init/Kconfig          | 298 +-----------------------------------------
 kernel/module/Kconfig | 296 +++++++++++++++++++++++++++++++++++++++++
 2 files changed, 297 insertions(+), 297 deletions(-)
 create mode 100644 kernel/module/Kconfig

diff --git a/init/Kconfig b/init/Kconfig
index c7900e8975f1..afb45347b775 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1918,303 +1918,6 @@ config BASE_SMALL
 	default 0 if BASE_FULL
 	default 1 if !BASE_FULL
 
-config MODULE_SIG_FORMAT
-	def_bool n
-	select SYSTEM_DATA_VERIFICATION
-
-menuconfig MODULES
-	bool "Enable loadable module support"
-	modules
-	help
-	  Kernel modules are small pieces of compiled code which can
-	  be inserted in the running kernel, rather than being
-	  permanently built into the kernel.  You use the "modprobe"
-	  tool to add (and sometimes remove) them.  If you say Y here,
-	  many parts of the kernel can be built as modules (by
-	  answering M instead of Y where indicated): this is most
-	  useful for infrequently used options which are not required
-	  for booting.  For more information, see the man pages for
-	  modprobe, lsmod, modinfo, insmod and rmmod.
-
-	  If you say Y here, you will need to run "make
-	  modules_install" to put the modules under /lib/modules/
-	  where modprobe can find them (you may need to be root to do
-	  this).
-
-	  If unsure, say Y.
-
-if MODULES
-
-config MODULE_FORCE_LOAD
-	bool "Forced module loading"
-	default n
-	help
-	  Allow loading of modules without version information (ie. modprobe
-	  --force).  Forced module loading sets the 'F' (forced) taint flag and
-	  is usually a really bad idea.
-
-config MODULE_UNLOAD
-	bool "Module unloading"
-	help
-	  Without this option you will not be able to unload any
-	  modules (note that some modules may not be unloadable
-	  anyway), which makes your kernel smaller, faster
-	  and simpler.  If unsure, say Y.
-
-config MODULE_FORCE_UNLOAD
-	bool "Forced module unloading"
-	depends on MODULE_UNLOAD
-	help
-	  This option allows you to force a module to unload, even if the
-	  kernel believes it is unsafe: the kernel will remove the module
-	  without waiting for anyone to stop using it (using the -f option to
-	  rmmod).  This is mainly for kernel developers and desperate users.
-	  If unsure, say N.
-
-config MODULE_UNLOAD_TAINT_TRACKING
-	bool "Tainted module unload tracking"
-	depends on MODULE_UNLOAD
-	default n
-	help
-	  This option allows you to maintain a record of each unloaded
-	  module that tainted the kernel. In addition to displaying a
-	  list of linked (or loaded) modules e.g. on detection of a bad
-	  page (see bad_page()), the aforementioned details are also
-	  shown. If unsure, say N.
-
-config MODVERSIONS
-	bool "Module versioning support"
-	help
-	  Usually, you have to use modules compiled with your kernel.
-	  Saying Y here makes it sometimes possible to use modules
-	  compiled for different kernels, by adding enough information
-	  to the modules to (hopefully) spot any changes which would
-	  make them incompatible with the kernel you are running.  If
-	  unsure, say N.
-
-config ASM_MODVERSIONS
-	bool
-	default HAVE_ASM_MODVERSIONS && MODVERSIONS
-	help
-	  This enables module versioning for exported symbols also from
-	  assembly. This can be enabled only when the target architecture
-	  supports it.
-
-config MODULE_SRCVERSION_ALL
-	bool "Source checksum for all modules"
-	help
-	  Modules which contain a MODULE_VERSION get an extra "srcversion"
-	  field inserted into their modinfo section, which contains a
-    	  sum of the source files which made it.  This helps maintainers
-	  see exactly which source was used to build a module (since
-	  others sometimes change the module source without updating
-	  the version).  With this option, such a "srcversion" field
-	  will be created for all modules.  If unsure, say N.
-
-config MODULE_SIG
-	bool "Module signature verification"
-	select MODULE_SIG_FORMAT
-	help
-	  Check modules for valid signatures upon load: the signature
-	  is simply appended to the module. For more information see
-	  <file:Documentation/admin-guide/module-signing.rst>.
-
-	  Note that this option adds the OpenSSL development packages as a
-	  kernel build dependency so that the signing tool can use its crypto
-	  library.
-
-	  You should enable this option if you wish to use either
-	  CONFIG_SECURITY_LOCKDOWN_LSM or lockdown functionality imposed via
-	  another LSM - otherwise unsigned modules will be loadable regardless
-	  of the lockdown policy.
-
-	  !!!WARNING!!!  If you enable this option, you MUST make sure that the
-	  module DOES NOT get stripped after being signed.  This includes the
-	  debuginfo strip done by some packagers (such as rpmbuild) and
-	  inclusion into an initramfs that wants the module size reduced.
-
-config MODULE_SIG_FORCE
-	bool "Require modules to be validly signed"
-	depends on MODULE_SIG
-	help
-	  Reject unsigned modules or signed modules for which we don't have a
-	  key.  Without this, such modules will simply taint the kernel.
-
-config MODULE_SIG_ALL
-	bool "Automatically sign all modules"
-	default y
-	depends on MODULE_SIG || IMA_APPRAISE_MODSIG
-	help
-	  Sign all modules during make modules_install. Without this option,
-	  modules must be signed manually, using the scripts/sign-file tool.
-
-comment "Do not forget to sign required modules with scripts/sign-file"
-	depends on MODULE_SIG_FORCE && !MODULE_SIG_ALL
-
-choice
-	prompt "Which hash algorithm should modules be signed with?"
-	depends on MODULE_SIG || IMA_APPRAISE_MODSIG
-	help
-	  This determines which sort of hashing algorithm will be used during
-	  signature generation.  This algorithm _must_ be built into the kernel
-	  directly so that signature verification can take place.  It is not
-	  possible to load a signed module containing the algorithm to check
-	  the signature on that module.
-
-config MODULE_SIG_SHA1
-	bool "Sign modules with SHA-1"
-	select CRYPTO_SHA1
-
-config MODULE_SIG_SHA224
-	bool "Sign modules with SHA-224"
-	select CRYPTO_SHA256
-
-config MODULE_SIG_SHA256
-	bool "Sign modules with SHA-256"
-	select CRYPTO_SHA256
-
-config MODULE_SIG_SHA384
-	bool "Sign modules with SHA-384"
-	select CRYPTO_SHA512
-
-config MODULE_SIG_SHA512
-	bool "Sign modules with SHA-512"
-	select CRYPTO_SHA512
-
-endchoice
-
-config MODULE_SIG_HASH
-	string
-	depends on MODULE_SIG || IMA_APPRAISE_MODSIG
-	default "sha1" if MODULE_SIG_SHA1
-	default "sha224" if MODULE_SIG_SHA224
-	default "sha256" if MODULE_SIG_SHA256
-	default "sha384" if MODULE_SIG_SHA384
-	default "sha512" if MODULE_SIG_SHA512
-
-choice
-	prompt "Module compression mode"
-	help
-	  This option allows you to choose the algorithm which will be used to
-	  compress modules when 'make modules_install' is run. (or, you can
-	  choose to not compress modules at all.)
-
-	  External modules will also be compressed in the same way during the
-	  installation.
-
-	  For modules inside an initrd or initramfs, it's more efficient to
-	  compress the whole initrd or initramfs instead.
-
-	  This is fully compatible with signed modules.
-
-	  Please note that the tool used to load modules needs to support the
-	  corresponding algorithm. module-init-tools MAY support gzip, and kmod
-	  MAY support gzip, xz and zstd.
-
-	  Your build system needs to provide the appropriate compression tool
-	  to compress the modules.
-
-	  If in doubt, select 'None'.
-
-config MODULE_COMPRESS_NONE
-	bool "None"
-	help
-	  Do not compress modules. The installed modules are suffixed
-	  with .ko.
-
-config MODULE_COMPRESS_GZIP
-	bool "GZIP"
-	help
-	  Compress modules with GZIP. The installed modules are suffixed
-	  with .ko.gz.
-
-config MODULE_COMPRESS_XZ
-	bool "XZ"
-	help
-	  Compress modules with XZ. The installed modules are suffixed
-	  with .ko.xz.
-
-config MODULE_COMPRESS_ZSTD
-	bool "ZSTD"
-	help
-	  Compress modules with ZSTD. The installed modules are suffixed
-	  with .ko.zst.
-
-endchoice
-
-config MODULE_DECOMPRESS
-	bool "Support in-kernel module decompression"
-	depends on MODULE_COMPRESS_GZIP || MODULE_COMPRESS_XZ
-	select ZLIB_INFLATE if MODULE_COMPRESS_GZIP
-	select XZ_DEC if MODULE_COMPRESS_XZ
-	help
-
-	  Support for decompressing kernel modules by the kernel itself
-	  instead of relying on userspace to perform this task. Useful when
-	  load pinning security policy is enabled.
-
-	  If unsure, say N.
-
-config MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS
-	bool "Allow loading of modules with missing namespace imports"
-	help
-	  Symbols exported with EXPORT_SYMBOL_NS*() are considered exported in
-	  a namespace. A module that makes use of a symbol exported with such a
-	  namespace is required to import the namespace via MODULE_IMPORT_NS().
-	  There is no technical reason to enforce correct namespace imports,
-	  but it creates consistency between symbols defining namespaces and
-	  users importing namespaces they make use of. This option relaxes this
-	  requirement and lifts the enforcement when loading a module.
-
-	  If unsure, say N.
-
-config MODPROBE_PATH
-	string "Path to modprobe binary"
-	default "/sbin/modprobe"
-	help
-	  When kernel code requests a module, it does so by calling
-	  the "modprobe" userspace utility. This option allows you to
-	  set the path where that binary is found. This can be changed
-	  at runtime via the sysctl file
-	  /proc/sys/kernel/modprobe. Setting this to the empty string
-	  removes the kernel's ability to request modules (but
-	  userspace can still load modules explicitly).
-
-config TRIM_UNUSED_KSYMS
-	bool "Trim unused exported kernel symbols" if EXPERT
-	depends on !COMPILE_TEST
-	help
-	  The kernel and some modules make many symbols available for
-	  other modules to use via EXPORT_SYMBOL() and variants. Depending
-	  on the set of modules being selected in your kernel configuration,
-	  many of those exported symbols might never be used.
-
-	  This option allows for unused exported symbols to be dropped from
-	  the build. In turn, this provides the compiler more opportunities
-	  (especially when using LTO) for optimizing the code and reducing
-	  binary size.  This might have some security advantages as well.
-
-	  If unsure, or if you need to build out-of-tree modules, say N.
-
-config UNUSED_KSYMS_WHITELIST
-	string "Whitelist of symbols to keep in ksymtab"
-	depends on TRIM_UNUSED_KSYMS
-	help
-	  By default, all unused exported symbols will be un-exported from the
-	  build when TRIM_UNUSED_KSYMS is selected.
-
-	  UNUSED_KSYMS_WHITELIST allows to whitelist symbols that must be kept
-	  exported at all times, even in absence of in-tree users. The value to
-	  set here is the path to a text file containing the list of symbols,
-	  one per line. The path can be absolute, or relative to the kernel
-	  source tree.
-
-endif # MODULES
-
-config MODULES_TREE_LOOKUP
-	def_bool y
-	depends on PERF_EVENTS || TRACING || CFI_CLANG
-
 config INIT_ALL_POSSIBLE
 	bool
 	help
@@ -2224,6 +1927,7 @@ config INIT_ALL_POSSIBLE
 	  it was better to provide this option than to break all the archs
 	  and have several arch maintainers pursuing me down dark alleys.
 
+source "kernel/module/Kconfig"
 source "block/Kconfig"
 
 config PREEMPT_NOTIFIERS
diff --git a/kernel/module/Kconfig b/kernel/module/Kconfig
new file mode 100644
index 000000000000..5aff8a40c58e
--- /dev/null
+++ b/kernel/module/Kconfig
@@ -0,0 +1,296 @@
+config MODULE_SIG_FORMAT
+	def_bool n
+	select SYSTEM_DATA_VERIFICATION
+
+menuconfig MODULES
+	bool "Enable loadable module support"
+	modules
+	help
+	  Kernel modules are small pieces of compiled code which can
+	  be inserted in the running kernel, rather than being
+	  permanently built into the kernel.  You use the "modprobe"
+	  tool to add (and sometimes remove) them.  If you say Y here,
+	  many parts of the kernel can be built as modules (by
+	  answering M instead of Y where indicated): this is most
+	  useful for infrequently used options which are not required
+	  for booting.  For more information, see the man pages for
+	  modprobe, lsmod, modinfo, insmod and rmmod.
+
+	  If you say Y here, you will need to run "make
+	  modules_install" to put the modules under /lib/modules/
+	  where modprobe can find them (you may need to be root to do
+	  this).
+
+	  If unsure, say Y.
+
+if MODULES
+
+config MODULE_FORCE_LOAD
+	bool "Forced module loading"
+	default n
+	help
+	  Allow loading of modules without version information (ie. modprobe
+	  --force).  Forced module loading sets the 'F' (forced) taint flag and
+	  is usually a really bad idea.
+
+config MODULE_UNLOAD
+	bool "Module unloading"
+	help
+	  Without this option you will not be able to unload any
+	  modules (note that some modules may not be unloadable
+	  anyway), which makes your kernel smaller, faster
+	  and simpler.  If unsure, say Y.
+
+config MODULE_FORCE_UNLOAD
+	bool "Forced module unloading"
+	depends on MODULE_UNLOAD
+	help
+	  This option allows you to force a module to unload, even if the
+	  kernel believes it is unsafe: the kernel will remove the module
+	  without waiting for anyone to stop using it (using the -f option to
+	  rmmod).  This is mainly for kernel developers and desperate users.
+	  If unsure, say N.
+
+config MODULE_UNLOAD_TAINT_TRACKING
+	bool "Tainted module unload tracking"
+	depends on MODULE_UNLOAD
+	default n
+	help
+	  This option allows you to maintain a record of each unloaded
+	  module that tainted the kernel. In addition to displaying a
+	  list of linked (or loaded) modules e.g. on detection of a bad
+	  page (see bad_page()), the aforementioned details are also
+	  shown. If unsure, say N.
+
+config MODVERSIONS
+	bool "Module versioning support"
+	help
+	  Usually, you have to use modules compiled with your kernel.
+	  Saying Y here makes it sometimes possible to use modules
+	  compiled for different kernels, by adding enough information
+	  to the modules to (hopefully) spot any changes which would
+	  make them incompatible with the kernel you are running.  If
+	  unsure, say N.
+
+config ASM_MODVERSIONS
+	bool
+	default HAVE_ASM_MODVERSIONS && MODVERSIONS
+	help
+	  This enables module versioning for exported symbols also from
+	  assembly. This can be enabled only when the target architecture
+	  supports it.
+
+config MODULE_SRCVERSION_ALL
+	bool "Source checksum for all modules"
+	help
+	  Modules which contain a MODULE_VERSION get an extra "srcversion"
+	  field inserted into their modinfo section, which contains a
+    	  sum of the source files which made it.  This helps maintainers
+	  see exactly which source was used to build a module (since
+	  others sometimes change the module source without updating
+	  the version).  With this option, such a "srcversion" field
+	  will be created for all modules.  If unsure, say N.
+
+config MODULE_SIG
+	bool "Module signature verification"
+	select MODULE_SIG_FORMAT
+	help
+	  Check modules for valid signatures upon load: the signature
+	  is simply appended to the module. For more information see
+	  <file:Documentation/admin-guide/module-signing.rst>.
+
+	  Note that this option adds the OpenSSL development packages as a
+	  kernel build dependency so that the signing tool can use its crypto
+	  library.
+
+	  You should enable this option if you wish to use either
+	  CONFIG_SECURITY_LOCKDOWN_LSM or lockdown functionality imposed via
+	  another LSM - otherwise unsigned modules will be loadable regardless
+	  of the lockdown policy.
+
+	  !!!WARNING!!!  If you enable this option, you MUST make sure that the
+	  module DOES NOT get stripped after being signed.  This includes the
+	  debuginfo strip done by some packagers (such as rpmbuild) and
+	  inclusion into an initramfs that wants the module size reduced.
+
+config MODULE_SIG_FORCE
+	bool "Require modules to be validly signed"
+	depends on MODULE_SIG
+	help
+	  Reject unsigned modules or signed modules for which we don't have a
+	  key.  Without this, such modules will simply taint the kernel.
+
+config MODULE_SIG_ALL
+	bool "Automatically sign all modules"
+	default y
+	depends on MODULE_SIG || IMA_APPRAISE_MODSIG
+	help
+	  Sign all modules during make modules_install. Without this option,
+	  modules must be signed manually, using the scripts/sign-file tool.
+
+comment "Do not forget to sign required modules with scripts/sign-file"
+	depends on MODULE_SIG_FORCE && !MODULE_SIG_ALL
+
+choice
+	prompt "Which hash algorithm should modules be signed with?"
+	depends on MODULE_SIG || IMA_APPRAISE_MODSIG
+	help
+	  This determines which sort of hashing algorithm will be used during
+	  signature generation.  This algorithm _must_ be built into the kernel
+	  directly so that signature verification can take place.  It is not
+	  possible to load a signed module containing the algorithm to check
+	  the signature on that module.
+
+config MODULE_SIG_SHA1
+	bool "Sign modules with SHA-1"
+	select CRYPTO_SHA1
+
+config MODULE_SIG_SHA224
+	bool "Sign modules with SHA-224"
+	select CRYPTO_SHA256
+
+config MODULE_SIG_SHA256
+	bool "Sign modules with SHA-256"
+	select CRYPTO_SHA256
+
+config MODULE_SIG_SHA384
+	bool "Sign modules with SHA-384"
+	select CRYPTO_SHA512
+
+config MODULE_SIG_SHA512
+	bool "Sign modules with SHA-512"
+	select CRYPTO_SHA512
+
+endchoice
+
+config MODULE_SIG_HASH
+	string
+	depends on MODULE_SIG || IMA_APPRAISE_MODSIG
+	default "sha1" if MODULE_SIG_SHA1
+	default "sha224" if MODULE_SIG_SHA224
+	default "sha256" if MODULE_SIG_SHA256
+	default "sha384" if MODULE_SIG_SHA384
+	default "sha512" if MODULE_SIG_SHA512
+
+choice
+	prompt "Module compression mode"
+	help
+	  This option allows you to choose the algorithm which will be used to
+	  compress modules when 'make modules_install' is run. (or, you can
+	  choose to not compress modules at all.)
+
+	  External modules will also be compressed in the same way during the
+	  installation.
+
+	  For modules inside an initrd or initramfs, it's more efficient to
+	  compress the whole initrd or initramfs instead.
+
+	  This is fully compatible with signed modules.
+
+	  Please note that the tool used to load modules needs to support the
+	  corresponding algorithm. module-init-tools MAY support gzip, and kmod
+	  MAY support gzip, xz and zstd.
+
+	  Your build system needs to provide the appropriate compression tool
+	  to compress the modules.
+
+	  If in doubt, select 'None'.
+
+config MODULE_COMPRESS_NONE
+	bool "None"
+	help
+	  Do not compress modules. The installed modules are suffixed
+	  with .ko.
+
+config MODULE_COMPRESS_GZIP
+	bool "GZIP"
+	help
+	  Compress modules with GZIP. The installed modules are suffixed
+	  with .ko.gz.
+
+config MODULE_COMPRESS_XZ
+	bool "XZ"
+	help
+	  Compress modules with XZ. The installed modules are suffixed
+	  with .ko.xz.
+
+config MODULE_COMPRESS_ZSTD
+	bool "ZSTD"
+	help
+	  Compress modules with ZSTD. The installed modules are suffixed
+	  with .ko.zst.
+
+endchoice
+
+config MODULE_DECOMPRESS
+	bool "Support in-kernel module decompression"
+	depends on MODULE_COMPRESS_GZIP || MODULE_COMPRESS_XZ
+	select ZLIB_INFLATE if MODULE_COMPRESS_GZIP
+	select XZ_DEC if MODULE_COMPRESS_XZ
+	help
+
+	  Support for decompressing kernel modules by the kernel itself
+	  instead of relying on userspace to perform this task. Useful when
+	  load pinning security policy is enabled.
+
+	  If unsure, say N.
+
+config MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS
+	bool "Allow loading of modules with missing namespace imports"
+	help
+	  Symbols exported with EXPORT_SYMBOL_NS*() are considered exported in
+	  a namespace. A module that makes use of a symbol exported with such a
+	  namespace is required to import the namespace via MODULE_IMPORT_NS().
+	  There is no technical reason to enforce correct namespace imports,
+	  but it creates consistency between symbols defining namespaces and
+	  users importing namespaces they make use of. This option relaxes this
+	  requirement and lifts the enforcement when loading a module.
+
+	  If unsure, say N.
+
+config MODPROBE_PATH
+	string "Path to modprobe binary"
+	default "/sbin/modprobe"
+	help
+	  When kernel code requests a module, it does so by calling
+	  the "modprobe" userspace utility. This option allows you to
+	  set the path where that binary is found. This can be changed
+	  at runtime via the sysctl file
+	  /proc/sys/kernel/modprobe. Setting this to the empty string
+	  removes the kernel's ability to request modules (but
+	  userspace can still load modules explicitly).
+
+config TRIM_UNUSED_KSYMS
+	bool "Trim unused exported kernel symbols" if EXPERT
+	depends on !COMPILE_TEST
+	help
+	  The kernel and some modules make many symbols available for
+	  other modules to use via EXPORT_SYMBOL() and variants. Depending
+	  on the set of modules being selected in your kernel configuration,
+	  many of those exported symbols might never be used.
+
+	  This option allows for unused exported symbols to be dropped from
+	  the build. In turn, this provides the compiler more opportunities
+	  (especially when using LTO) for optimizing the code and reducing
+	  binary size.  This might have some security advantages as well.
+
+	  If unsure, or if you need to build out-of-tree modules, say N.
+
+config UNUSED_KSYMS_WHITELIST
+	string "Whitelist of symbols to keep in ksymtab"
+	depends on TRIM_UNUSED_KSYMS
+	help
+	  By default, all unused exported symbols will be un-exported from the
+	  build when TRIM_UNUSED_KSYMS is selected.
+
+	  UNUSED_KSYMS_WHITELIST allows to whitelist symbols that must be kept
+	  exported at all times, even in absence of in-tree users. The value to
+	  set here is the path to a text file containing the list of symbols,
+	  one per line. The path can be absolute, or relative to the kernel
+	  source tree.
+
+endif # MODULES
+
+config MODULES_TREE_LOOKUP
+	def_bool y
+	depends on PERF_EVENTS || TRACING || CFI_CLANG
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH] modules: move module symbols from init/Kconfig
  2022-07-11 16:20 [PATCH] modules: move module symbols from init/Kconfig Luis Chamberlain
@ 2022-07-11 18:33 ` Christophe Leroy
  2022-07-11 19:07   ` Luis Chamberlain
  0 siblings, 1 reply; 6+ messages in thread
From: Christophe Leroy @ 2022-07-11 18:33 UTC (permalink / raw)
  To: Luis Chamberlain, linux-modules, linux-kernel; +Cc: atomlin



Le 11/07/2022 à 18:20, Luis Chamberlain a écrit :
> This moves all the module symbols from init/Kconfig to its
> own dedicated file now that we have all of the module code in
> its own directory.
> 
> This does not introduce any functional changes.
> 
> Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>

It is similar to the patch I sent in February, isn't it ? 
(https://patchwork.kernel.org/project/linux-modules/patch/4042712961d42186c449734c253511ea7076c780.1645543105.git.christophe.leroy@csgroup.eu/)

> ---
>   init/Kconfig          | 298 +-----------------------------------------
>   kernel/module/Kconfig | 296 +++++++++++++++++++++++++++++++++++++++++
>   2 files changed, 297 insertions(+), 297 deletions(-)
>   create mode 100644 kernel/module/Kconfig
> 
> diff --git a/init/Kconfig b/init/Kconfig
> index c7900e8975f1..afb45347b775 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1918,303 +1918,6 @@ config BASE_SMALL
>   	default 0 if BASE_FULL
>   	default 1 if !BASE_FULL
>   
> -config MODULE_SIG_FORMAT
> -	def_bool n
> -	select SYSTEM_DATA_VERIFICATION
> -

MODULE_SIG_FORMAT is not used in kernel/module/Makefile but still in 
kernel/Makefile, that's the reason why in my patch I left it in init/Kconfig

Christophe

> -menuconfig MODULES
> -	bool "Enable loadable module support"
> -	modules
> -	help
> -	  Kernel modules are small pieces of compiled code which can
> -	  be inserted in the running kernel, rather than being
> -	  permanently built into the kernel.  You use the "modprobe"
> -	  tool to add (and sometimes remove) them.  If you say Y here,
> -	  many parts of the kernel can be built as modules (by
> -	  answering M instead of Y where indicated): this is most
> -	  useful for infrequently used options which are not required
> -	  for booting.  For more information, see the man pages for
> -	  modprobe, lsmod, modinfo, insmod and rmmod.
> -
> -	  If you say Y here, you will need to run "make
> -	  modules_install" to put the modules under /lib/modules/
> -	  where modprobe can find them (you may need to be root to do
> -	  this).
> -
> -	  If unsure, say Y.
> -
> -if MODULES
> -
> -config MODULE_FORCE_LOAD
> -	bool "Forced module loading"
> -	default n
> -	help
> -	  Allow loading of modules without version information (ie. modprobe
> -	  --force).  Forced module loading sets the 'F' (forced) taint flag and
> -	  is usually a really bad idea.
> -
> -config MODULE_UNLOAD
> -	bool "Module unloading"
> -	help
> -	  Without this option you will not be able to unload any
> -	  modules (note that some modules may not be unloadable
> -	  anyway), which makes your kernel smaller, faster
> -	  and simpler.  If unsure, say Y.
> -
> -config MODULE_FORCE_UNLOAD
> -	bool "Forced module unloading"
> -	depends on MODULE_UNLOAD
> -	help
> -	  This option allows you to force a module to unload, even if the
> -	  kernel believes it is unsafe: the kernel will remove the module
> -	  without waiting for anyone to stop using it (using the -f option to
> -	  rmmod).  This is mainly for kernel developers and desperate users.
> -	  If unsure, say N.
> -
> -config MODULE_UNLOAD_TAINT_TRACKING
> -	bool "Tainted module unload tracking"
> -	depends on MODULE_UNLOAD
> -	default n
> -	help
> -	  This option allows you to maintain a record of each unloaded
> -	  module that tainted the kernel. In addition to displaying a
> -	  list of linked (or loaded) modules e.g. on detection of a bad
> -	  page (see bad_page()), the aforementioned details are also
> -	  shown. If unsure, say N.
> -
> -config MODVERSIONS
> -	bool "Module versioning support"
> -	help
> -	  Usually, you have to use modules compiled with your kernel.
> -	  Saying Y here makes it sometimes possible to use modules
> -	  compiled for different kernels, by adding enough information
> -	  to the modules to (hopefully) spot any changes which would
> -	  make them incompatible with the kernel you are running.  If
> -	  unsure, say N.
> -
> -config ASM_MODVERSIONS
> -	bool
> -	default HAVE_ASM_MODVERSIONS && MODVERSIONS
> -	help
> -	  This enables module versioning for exported symbols also from
> -	  assembly. This can be enabled only when the target architecture
> -	  supports it.
> -
> -config MODULE_SRCVERSION_ALL
> -	bool "Source checksum for all modules"
> -	help
> -	  Modules which contain a MODULE_VERSION get an extra "srcversion"
> -	  field inserted into their modinfo section, which contains a
> -    	  sum of the source files which made it.  This helps maintainers
> -	  see exactly which source was used to build a module (since
> -	  others sometimes change the module source without updating
> -	  the version).  With this option, such a "srcversion" field
> -	  will be created for all modules.  If unsure, say N.
> -
> -config MODULE_SIG
> -	bool "Module signature verification"
> -	select MODULE_SIG_FORMAT
> -	help
> -	  Check modules for valid signatures upon load: the signature
> -	  is simply appended to the module. For more information see
> -	  <file:Documentation/admin-guide/module-signing.rst>.
> -
> -	  Note that this option adds the OpenSSL development packages as a
> -	  kernel build dependency so that the signing tool can use its crypto
> -	  library.
> -
> -	  You should enable this option if you wish to use either
> -	  CONFIG_SECURITY_LOCKDOWN_LSM or lockdown functionality imposed via
> -	  another LSM - otherwise unsigned modules will be loadable regardless
> -	  of the lockdown policy.
> -
> -	  !!!WARNING!!!  If you enable this option, you MUST make sure that the
> -	  module DOES NOT get stripped after being signed.  This includes the
> -	  debuginfo strip done by some packagers (such as rpmbuild) and
> -	  inclusion into an initramfs that wants the module size reduced.
> -
> -config MODULE_SIG_FORCE
> -	bool "Require modules to be validly signed"
> -	depends on MODULE_SIG
> -	help
> -	  Reject unsigned modules or signed modules for which we don't have a
> -	  key.  Without this, such modules will simply taint the kernel.
> -
> -config MODULE_SIG_ALL
> -	bool "Automatically sign all modules"
> -	default y
> -	depends on MODULE_SIG || IMA_APPRAISE_MODSIG
> -	help
> -	  Sign all modules during make modules_install. Without this option,
> -	  modules must be signed manually, using the scripts/sign-file tool.
> -
> -comment "Do not forget to sign required modules with scripts/sign-file"
> -	depends on MODULE_SIG_FORCE && !MODULE_SIG_ALL
> -
> -choice
> -	prompt "Which hash algorithm should modules be signed with?"
> -	depends on MODULE_SIG || IMA_APPRAISE_MODSIG
> -	help
> -	  This determines which sort of hashing algorithm will be used during
> -	  signature generation.  This algorithm _must_ be built into the kernel
> -	  directly so that signature verification can take place.  It is not
> -	  possible to load a signed module containing the algorithm to check
> -	  the signature on that module.
> -
> -config MODULE_SIG_SHA1
> -	bool "Sign modules with SHA-1"
> -	select CRYPTO_SHA1
> -
> -config MODULE_SIG_SHA224
> -	bool "Sign modules with SHA-224"
> -	select CRYPTO_SHA256
> -
> -config MODULE_SIG_SHA256
> -	bool "Sign modules with SHA-256"
> -	select CRYPTO_SHA256
> -
> -config MODULE_SIG_SHA384
> -	bool "Sign modules with SHA-384"
> -	select CRYPTO_SHA512
> -
> -config MODULE_SIG_SHA512
> -	bool "Sign modules with SHA-512"
> -	select CRYPTO_SHA512
> -
> -endchoice
> -
> -config MODULE_SIG_HASH
> -	string
> -	depends on MODULE_SIG || IMA_APPRAISE_MODSIG
> -	default "sha1" if MODULE_SIG_SHA1
> -	default "sha224" if MODULE_SIG_SHA224
> -	default "sha256" if MODULE_SIG_SHA256
> -	default "sha384" if MODULE_SIG_SHA384
> -	default "sha512" if MODULE_SIG_SHA512
> -
> -choice
> -	prompt "Module compression mode"
> -	help
> -	  This option allows you to choose the algorithm which will be used to
> -	  compress modules when 'make modules_install' is run. (or, you can
> -	  choose to not compress modules at all.)
> -
> -	  External modules will also be compressed in the same way during the
> -	  installation.
> -
> -	  For modules inside an initrd or initramfs, it's more efficient to
> -	  compress the whole initrd or initramfs instead.
> -
> -	  This is fully compatible with signed modules.
> -
> -	  Please note that the tool used to load modules needs to support the
> -	  corresponding algorithm. module-init-tools MAY support gzip, and kmod
> -	  MAY support gzip, xz and zstd.
> -
> -	  Your build system needs to provide the appropriate compression tool
> -	  to compress the modules.
> -
> -	  If in doubt, select 'None'.
> -
> -config MODULE_COMPRESS_NONE
> -	bool "None"
> -	help
> -	  Do not compress modules. The installed modules are suffixed
> -	  with .ko.
> -
> -config MODULE_COMPRESS_GZIP
> -	bool "GZIP"
> -	help
> -	  Compress modules with GZIP. The installed modules are suffixed
> -	  with .ko.gz.
> -
> -config MODULE_COMPRESS_XZ
> -	bool "XZ"
> -	help
> -	  Compress modules with XZ. The installed modules are suffixed
> -	  with .ko.xz.
> -
> -config MODULE_COMPRESS_ZSTD
> -	bool "ZSTD"
> -	help
> -	  Compress modules with ZSTD. The installed modules are suffixed
> -	  with .ko.zst.
> -
> -endchoice
> -
> -config MODULE_DECOMPRESS
> -	bool "Support in-kernel module decompression"
> -	depends on MODULE_COMPRESS_GZIP || MODULE_COMPRESS_XZ
> -	select ZLIB_INFLATE if MODULE_COMPRESS_GZIP
> -	select XZ_DEC if MODULE_COMPRESS_XZ
> -	help
> -
> -	  Support for decompressing kernel modules by the kernel itself
> -	  instead of relying on userspace to perform this task. Useful when
> -	  load pinning security policy is enabled.
> -
> -	  If unsure, say N.
> -
> -config MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS
> -	bool "Allow loading of modules with missing namespace imports"
> -	help
> -	  Symbols exported with EXPORT_SYMBOL_NS*() are considered exported in
> -	  a namespace. A module that makes use of a symbol exported with such a
> -	  namespace is required to import the namespace via MODULE_IMPORT_NS().
> -	  There is no technical reason to enforce correct namespace imports,
> -	  but it creates consistency between symbols defining namespaces and
> -	  users importing namespaces they make use of. This option relaxes this
> -	  requirement and lifts the enforcement when loading a module.
> -
> -	  If unsure, say N.
> -
> -config MODPROBE_PATH
> -	string "Path to modprobe binary"
> -	default "/sbin/modprobe"
> -	help
> -	  When kernel code requests a module, it does so by calling
> -	  the "modprobe" userspace utility. This option allows you to
> -	  set the path where that binary is found. This can be changed
> -	  at runtime via the sysctl file
> -	  /proc/sys/kernel/modprobe. Setting this to the empty string
> -	  removes the kernel's ability to request modules (but
> -	  userspace can still load modules explicitly).
> -
> -config TRIM_UNUSED_KSYMS
> -	bool "Trim unused exported kernel symbols" if EXPERT
> -	depends on !COMPILE_TEST
> -	help
> -	  The kernel and some modules make many symbols available for
> -	  other modules to use via EXPORT_SYMBOL() and variants. Depending
> -	  on the set of modules being selected in your kernel configuration,
> -	  many of those exported symbols might never be used.
> -
> -	  This option allows for unused exported symbols to be dropped from
> -	  the build. In turn, this provides the compiler more opportunities
> -	  (especially when using LTO) for optimizing the code and reducing
> -	  binary size.  This might have some security advantages as well.
> -
> -	  If unsure, or if you need to build out-of-tree modules, say N.
> -
> -config UNUSED_KSYMS_WHITELIST
> -	string "Whitelist of symbols to keep in ksymtab"
> -	depends on TRIM_UNUSED_KSYMS
> -	help
> -	  By default, all unused exported symbols will be un-exported from the
> -	  build when TRIM_UNUSED_KSYMS is selected.
> -
> -	  UNUSED_KSYMS_WHITELIST allows to whitelist symbols that must be kept
> -	  exported at all times, even in absence of in-tree users. The value to
> -	  set here is the path to a text file containing the list of symbols,
> -	  one per line. The path can be absolute, or relative to the kernel
> -	  source tree.
> -
> -endif # MODULES
> -
> -config MODULES_TREE_LOOKUP
> -	def_bool y
> -	depends on PERF_EVENTS || TRACING || CFI_CLANG
> -
>   config INIT_ALL_POSSIBLE
>   	bool
>   	help
> @@ -2224,6 +1927,7 @@ config INIT_ALL_POSSIBLE
>   	  it was better to provide this option than to break all the archs
>   	  and have several arch maintainers pursuing me down dark alleys.
>   
> +source "kernel/module/Kconfig"
>   source "block/Kconfig"
>   
>   config PREEMPT_NOTIFIERS
> diff --git a/kernel/module/Kconfig b/kernel/module/Kconfig
> new file mode 100644
> index 000000000000..5aff8a40c58e
> --- /dev/null
> +++ b/kernel/module/Kconfig
> @@ -0,0 +1,296 @@
> +config MODULE_SIG_FORMAT
> +	def_bool n
> +	select SYSTEM_DATA_VERIFICATION
> +
> +menuconfig MODULES
> +	bool "Enable loadable module support"
> +	modules
> +	help
> +	  Kernel modules are small pieces of compiled code which can
> +	  be inserted in the running kernel, rather than being
> +	  permanently built into the kernel.  You use the "modprobe"
> +	  tool to add (and sometimes remove) them.  If you say Y here,
> +	  many parts of the kernel can be built as modules (by
> +	  answering M instead of Y where indicated): this is most
> +	  useful for infrequently used options which are not required
> +	  for booting.  For more information, see the man pages for
> +	  modprobe, lsmod, modinfo, insmod and rmmod.
> +
> +	  If you say Y here, you will need to run "make
> +	  modules_install" to put the modules under /lib/modules/
> +	  where modprobe can find them (you may need to be root to do
> +	  this).
> +
> +	  If unsure, say Y.
> +
> +if MODULES
> +
> +config MODULE_FORCE_LOAD
> +	bool "Forced module loading"
> +	default n
> +	help
> +	  Allow loading of modules without version information (ie. modprobe
> +	  --force).  Forced module loading sets the 'F' (forced) taint flag and
> +	  is usually a really bad idea.
> +
> +config MODULE_UNLOAD
> +	bool "Module unloading"
> +	help
> +	  Without this option you will not be able to unload any
> +	  modules (note that some modules may not be unloadable
> +	  anyway), which makes your kernel smaller, faster
> +	  and simpler.  If unsure, say Y.
> +
> +config MODULE_FORCE_UNLOAD
> +	bool "Forced module unloading"
> +	depends on MODULE_UNLOAD
> +	help
> +	  This option allows you to force a module to unload, even if the
> +	  kernel believes it is unsafe: the kernel will remove the module
> +	  without waiting for anyone to stop using it (using the -f option to
> +	  rmmod).  This is mainly for kernel developers and desperate users.
> +	  If unsure, say N.
> +
> +config MODULE_UNLOAD_TAINT_TRACKING
> +	bool "Tainted module unload tracking"
> +	depends on MODULE_UNLOAD
> +	default n
> +	help
> +	  This option allows you to maintain a record of each unloaded
> +	  module that tainted the kernel. In addition to displaying a
> +	  list of linked (or loaded) modules e.g. on detection of a bad
> +	  page (see bad_page()), the aforementioned details are also
> +	  shown. If unsure, say N.
> +
> +config MODVERSIONS
> +	bool "Module versioning support"
> +	help
> +	  Usually, you have to use modules compiled with your kernel.
> +	  Saying Y here makes it sometimes possible to use modules
> +	  compiled for different kernels, by adding enough information
> +	  to the modules to (hopefully) spot any changes which would
> +	  make them incompatible with the kernel you are running.  If
> +	  unsure, say N.
> +
> +config ASM_MODVERSIONS
> +	bool
> +	default HAVE_ASM_MODVERSIONS && MODVERSIONS
> +	help
> +	  This enables module versioning for exported symbols also from
> +	  assembly. This can be enabled only when the target architecture
> +	  supports it.
> +
> +config MODULE_SRCVERSION_ALL
> +	bool "Source checksum for all modules"
> +	help
> +	  Modules which contain a MODULE_VERSION get an extra "srcversion"
> +	  field inserted into their modinfo section, which contains a
> +    	  sum of the source files which made it.  This helps maintainers
> +	  see exactly which source was used to build a module (since
> +	  others sometimes change the module source without updating
> +	  the version).  With this option, such a "srcversion" field
> +	  will be created for all modules.  If unsure, say N.
> +
> +config MODULE_SIG
> +	bool "Module signature verification"
> +	select MODULE_SIG_FORMAT
> +	help
> +	  Check modules for valid signatures upon load: the signature
> +	  is simply appended to the module. For more information see
> +	  <file:Documentation/admin-guide/module-signing.rst>.
> +
> +	  Note that this option adds the OpenSSL development packages as a
> +	  kernel build dependency so that the signing tool can use its crypto
> +	  library.
> +
> +	  You should enable this option if you wish to use either
> +	  CONFIG_SECURITY_LOCKDOWN_LSM or lockdown functionality imposed via
> +	  another LSM - otherwise unsigned modules will be loadable regardless
> +	  of the lockdown policy.
> +
> +	  !!!WARNING!!!  If you enable this option, you MUST make sure that the
> +	  module DOES NOT get stripped after being signed.  This includes the
> +	  debuginfo strip done by some packagers (such as rpmbuild) and
> +	  inclusion into an initramfs that wants the module size reduced.
> +
> +config MODULE_SIG_FORCE
> +	bool "Require modules to be validly signed"
> +	depends on MODULE_SIG
> +	help
> +	  Reject unsigned modules or signed modules for which we don't have a
> +	  key.  Without this, such modules will simply taint the kernel.
> +
> +config MODULE_SIG_ALL
> +	bool "Automatically sign all modules"
> +	default y
> +	depends on MODULE_SIG || IMA_APPRAISE_MODSIG
> +	help
> +	  Sign all modules during make modules_install. Without this option,
> +	  modules must be signed manually, using the scripts/sign-file tool.
> +
> +comment "Do not forget to sign required modules with scripts/sign-file"
> +	depends on MODULE_SIG_FORCE && !MODULE_SIG_ALL
> +
> +choice
> +	prompt "Which hash algorithm should modules be signed with?"
> +	depends on MODULE_SIG || IMA_APPRAISE_MODSIG
> +	help
> +	  This determines which sort of hashing algorithm will be used during
> +	  signature generation.  This algorithm _must_ be built into the kernel
> +	  directly so that signature verification can take place.  It is not
> +	  possible to load a signed module containing the algorithm to check
> +	  the signature on that module.
> +
> +config MODULE_SIG_SHA1
> +	bool "Sign modules with SHA-1"
> +	select CRYPTO_SHA1
> +
> +config MODULE_SIG_SHA224
> +	bool "Sign modules with SHA-224"
> +	select CRYPTO_SHA256
> +
> +config MODULE_SIG_SHA256
> +	bool "Sign modules with SHA-256"
> +	select CRYPTO_SHA256
> +
> +config MODULE_SIG_SHA384
> +	bool "Sign modules with SHA-384"
> +	select CRYPTO_SHA512
> +
> +config MODULE_SIG_SHA512
> +	bool "Sign modules with SHA-512"
> +	select CRYPTO_SHA512
> +
> +endchoice
> +
> +config MODULE_SIG_HASH
> +	string
> +	depends on MODULE_SIG || IMA_APPRAISE_MODSIG
> +	default "sha1" if MODULE_SIG_SHA1
> +	default "sha224" if MODULE_SIG_SHA224
> +	default "sha256" if MODULE_SIG_SHA256
> +	default "sha384" if MODULE_SIG_SHA384
> +	default "sha512" if MODULE_SIG_SHA512
> +
> +choice
> +	prompt "Module compression mode"
> +	help
> +	  This option allows you to choose the algorithm which will be used to
> +	  compress modules when 'make modules_install' is run. (or, you can
> +	  choose to not compress modules at all.)
> +
> +	  External modules will also be compressed in the same way during the
> +	  installation.
> +
> +	  For modules inside an initrd or initramfs, it's more efficient to
> +	  compress the whole initrd or initramfs instead.
> +
> +	  This is fully compatible with signed modules.
> +
> +	  Please note that the tool used to load modules needs to support the
> +	  corresponding algorithm. module-init-tools MAY support gzip, and kmod
> +	  MAY support gzip, xz and zstd.
> +
> +	  Your build system needs to provide the appropriate compression tool
> +	  to compress the modules.
> +
> +	  If in doubt, select 'None'.
> +
> +config MODULE_COMPRESS_NONE
> +	bool "None"
> +	help
> +	  Do not compress modules. The installed modules are suffixed
> +	  with .ko.
> +
> +config MODULE_COMPRESS_GZIP
> +	bool "GZIP"
> +	help
> +	  Compress modules with GZIP. The installed modules are suffixed
> +	  with .ko.gz.
> +
> +config MODULE_COMPRESS_XZ
> +	bool "XZ"
> +	help
> +	  Compress modules with XZ. The installed modules are suffixed
> +	  with .ko.xz.
> +
> +config MODULE_COMPRESS_ZSTD
> +	bool "ZSTD"
> +	help
> +	  Compress modules with ZSTD. The installed modules are suffixed
> +	  with .ko.zst.
> +
> +endchoice
> +
> +config MODULE_DECOMPRESS
> +	bool "Support in-kernel module decompression"
> +	depends on MODULE_COMPRESS_GZIP || MODULE_COMPRESS_XZ
> +	select ZLIB_INFLATE if MODULE_COMPRESS_GZIP
> +	select XZ_DEC if MODULE_COMPRESS_XZ
> +	help
> +
> +	  Support for decompressing kernel modules by the kernel itself
> +	  instead of relying on userspace to perform this task. Useful when
> +	  load pinning security policy is enabled.
> +
> +	  If unsure, say N.
> +
> +config MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS
> +	bool "Allow loading of modules with missing namespace imports"
> +	help
> +	  Symbols exported with EXPORT_SYMBOL_NS*() are considered exported in
> +	  a namespace. A module that makes use of a symbol exported with such a
> +	  namespace is required to import the namespace via MODULE_IMPORT_NS().
> +	  There is no technical reason to enforce correct namespace imports,
> +	  but it creates consistency between symbols defining namespaces and
> +	  users importing namespaces they make use of. This option relaxes this
> +	  requirement and lifts the enforcement when loading a module.
> +
> +	  If unsure, say N.
> +
> +config MODPROBE_PATH
> +	string "Path to modprobe binary"
> +	default "/sbin/modprobe"
> +	help
> +	  When kernel code requests a module, it does so by calling
> +	  the "modprobe" userspace utility. This option allows you to
> +	  set the path where that binary is found. This can be changed
> +	  at runtime via the sysctl file
> +	  /proc/sys/kernel/modprobe. Setting this to the empty string
> +	  removes the kernel's ability to request modules (but
> +	  userspace can still load modules explicitly).
> +
> +config TRIM_UNUSED_KSYMS
> +	bool "Trim unused exported kernel symbols" if EXPERT
> +	depends on !COMPILE_TEST
> +	help
> +	  The kernel and some modules make many symbols available for
> +	  other modules to use via EXPORT_SYMBOL() and variants. Depending
> +	  on the set of modules being selected in your kernel configuration,
> +	  many of those exported symbols might never be used.
> +
> +	  This option allows for unused exported symbols to be dropped from
> +	  the build. In turn, this provides the compiler more opportunities
> +	  (especially when using LTO) for optimizing the code and reducing
> +	  binary size.  This might have some security advantages as well.
> +
> +	  If unsure, or if you need to build out-of-tree modules, say N.
> +
> +config UNUSED_KSYMS_WHITELIST
> +	string "Whitelist of symbols to keep in ksymtab"
> +	depends on TRIM_UNUSED_KSYMS
> +	help
> +	  By default, all unused exported symbols will be un-exported from the
> +	  build when TRIM_UNUSED_KSYMS is selected.
> +
> +	  UNUSED_KSYMS_WHITELIST allows to whitelist symbols that must be kept
> +	  exported at all times, even in absence of in-tree users. The value to
> +	  set here is the path to a text file containing the list of symbols,
> +	  one per line. The path can be absolute, or relative to the kernel
> +	  source tree.
> +
> +endif # MODULES
> +
> +config MODULES_TREE_LOOKUP
> +	def_bool y
> +	depends on PERF_EVENTS || TRACING || CFI_CLANG

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] modules: move module symbols from init/Kconfig
  2022-07-11 18:33 ` Christophe Leroy
@ 2022-07-11 19:07   ` Luis Chamberlain
  2022-07-12  5:57     ` Christophe Leroy
  0 siblings, 1 reply; 6+ messages in thread
From: Luis Chamberlain @ 2022-07-11 19:07 UTC (permalink / raw)
  To: Christophe Leroy; +Cc: linux-modules, linux-kernel, atomlin

On Mon, Jul 11, 2022 at 06:33:08PM +0000, Christophe Leroy wrote:
> 
> 
> Le 11/07/2022 à 18:20, Luis Chamberlain a écrit :
> > This moves all the module symbols from init/Kconfig to its
> > own dedicated file now that we have all of the module code in
> > its own directory.
> > 
> > This does not introduce any functional changes.
> > 
> > Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
> 
> It is similar to the patch I sent in February, isn't it ? 
> (https://patchwork.kernel.org/project/linux-modules/patch/4042712961d42186c449734c253511ea7076c780.1645543105.git.christophe.leroy@csgroup.eu/)

Sorry, I had missed that. Can you send a new v2 based on today's
modules-next? And I'll just drop my patch?

  Luis

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] modules: move module symbols from init/Kconfig
  2022-07-11 19:07   ` Luis Chamberlain
@ 2022-07-12  5:57     ` Christophe Leroy
  2022-07-12 19:09       ` Luis Chamberlain
  0 siblings, 1 reply; 6+ messages in thread
From: Christophe Leroy @ 2022-07-12  5:57 UTC (permalink / raw)
  To: Luis Chamberlain; +Cc: linux-modules, linux-kernel, atomlin



Le 11/07/2022 à 21:07, Luis Chamberlain a écrit :
> On Mon, Jul 11, 2022 at 06:33:08PM +0000, Christophe Leroy wrote:
>>
>>
>> Le 11/07/2022 à 18:20, Luis Chamberlain a écrit :
>>> This moves all the module symbols from init/Kconfig to its
>>> own dedicated file now that we have all of the module code in
>>> its own directory.
>>>
>>> This does not introduce any functional changes.
>>>
>>> Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
>>
>> It is similar to the patch I sent in February, isn't it ?
>> (https://patchwork.kernel.org/project/linux-modules/patch/4042712961d42186c449734c253511ea7076c780.1645543105.git.christophe.leroy@csgroup.eu/)
> 
> Sorry, I had missed that. Can you send a new v2 based on today's
> modules-next? And I'll just drop my patch?
> 

I sent out v2 rebased on today's modules-next 
(c76654e22da1e0cb830bd0eb5832072fb76df358)

I see all my patches still have status 'new' in modules's patchwork 
(https://patchwork.kernel.org/project/linux-modules/list/?submitter=192363).

Don't you maintain it ?

Thanks
Christophe

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] modules: move module symbols from init/Kconfig
  2022-07-12  5:57     ` Christophe Leroy
@ 2022-07-12 19:09       ` Luis Chamberlain
  2022-07-13  7:12         ` Kalle Valo
  0 siblings, 1 reply; 6+ messages in thread
From: Luis Chamberlain @ 2022-07-12 19:09 UTC (permalink / raw)
  To: Christophe Leroy; +Cc: linux-modules, linux-kernel, atomlin

On Tue, Jul 12, 2022 at 05:57:35AM +0000, Christophe Leroy wrote:
> 
> 
> Le 11/07/2022 à 21:07, Luis Chamberlain a écrit :
> > On Mon, Jul 11, 2022 at 06:33:08PM +0000, Christophe Leroy wrote:
> >>
> >>
> >> Le 11/07/2022 à 18:20, Luis Chamberlain a écrit :
> >>> This moves all the module symbols from init/Kconfig to its
> >>> own dedicated file now that we have all of the module code in
> >>> its own directory.
> >>>
> >>> This does not introduce any functional changes.
> >>>
> >>> Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
> >>
> >> It is similar to the patch I sent in February, isn't it ?
> >> (https://patchwork.kernel.org/project/linux-modules/patch/4042712961d42186c449734c253511ea7076c780.1645543105.git.christophe.leroy@csgroup.eu/)
> > 
> > Sorry, I had missed that. Can you send a new v2 based on today's
> > modules-next? And I'll just drop my patch?
> > 
> 
> I sent out v2 rebased on today's modules-next 
> (c76654e22da1e0cb830bd0eb5832072fb76df358)
> 
> I see all my patches still have status 'new' in modules's patchwork 
> (https://patchwork.kernel.org/project/linux-modules/list/?submitter=192363).
> 
> Don't you maintain it ?

Yes but I never knew we used to have patchwork for modules, but glad we have
that now. Anyway all your patches are applied, is patchwork dumb to not
pick that up?

  Luis


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] modules: move module symbols from init/Kconfig
  2022-07-12 19:09       ` Luis Chamberlain
@ 2022-07-13  7:12         ` Kalle Valo
  0 siblings, 0 replies; 6+ messages in thread
From: Kalle Valo @ 2022-07-13  7:12 UTC (permalink / raw)
  To: Luis Chamberlain; +Cc: Christophe Leroy, linux-modules, linux-kernel, atomlin

Luis Chamberlain <mcgrof@kernel.org> writes:

> On Tue, Jul 12, 2022 at 05:57:35AM +0000, Christophe Leroy wrote:
>> 
>> 
>> Le 11/07/2022 à 21:07, Luis Chamberlain a écrit :
>> > On Mon, Jul 11, 2022 at 06:33:08PM +0000, Christophe Leroy wrote:
>> >>
>> >>
>> >> Le 11/07/2022 à 18:20, Luis Chamberlain a écrit :
>> >>> This moves all the module symbols from init/Kconfig to its
>> >>> own dedicated file now that we have all of the module code in
>> >>> its own directory.
>> >>>
>> >>> This does not introduce any functional changes.
>> >>>
>> >>> Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
>> >>
>> >> It is similar to the patch I sent in February, isn't it ?
>> >> (https://patchwork.kernel.org/project/linux-modules/patch/4042712961d42186c449734c253511ea7076c780.1645543105.git.christophe.leroy@csgroup.eu/)
>> > 
>> > Sorry, I had missed that. Can you send a new v2 based on today's
>> > modules-next? And I'll just drop my patch?
>> > 
>> 
>> I sent out v2 rebased on today's modules-next 
>> (c76654e22da1e0cb830bd0eb5832072fb76df358)
>> 
>> I see all my patches still have status 'new' in modules's patchwork 
>> (https://patchwork.kernel.org/project/linux-modules/list/?submitter=192363).
>> 
>> Don't you maintain it ?
>
> Yes but I never knew we used to have patchwork for modules, but glad we have
> that now. Anyway all your patches are applied, is patchwork dumb to not
> pick that up?

patchwork does not have that functionality built in, you need to enable
the bot separately:

https://korg.docs.kernel.org/patchwork/pwbot.html

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2022-07-13  7:13 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-11 16:20 [PATCH] modules: move module symbols from init/Kconfig Luis Chamberlain
2022-07-11 18:33 ` Christophe Leroy
2022-07-11 19:07   ` Luis Chamberlain
2022-07-12  5:57     ` Christophe Leroy
2022-07-12 19:09       ` Luis Chamberlain
2022-07-13  7:12         ` Kalle Valo

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).