* [PATCH v6 5/9] pinctrl: meson: Fix typo in device table macro
From: Alexey Gladkov @ 2025-08-14 13:07 UTC (permalink / raw)
To: Nathan Chancellor, Nicolas Schier, Masahiro Yamada, Petr Pavlu,
Luis Chamberlain, Sami Tolvanen, Daniel Gomez
Cc: linux-kernel, linux-modules, linux-kbuild, Alexey Gladkov,
Xianwei Zhao, Linus Walleij, Neil Armstrong, Kevin Hilman,
linux-amlogic, linux-gpio, kernel test robot
In-Reply-To: <cover.1755170493.git.legion@kernel.org>
The typo when using the MODULE_DEVICE_TABLE macro was not noticeable
because the macro was defined only if the module was built as a separate
module.
Cc: Xianwei Zhao <xianwei.zhao@amlogic.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Neil Armstrong <neil.armstrong@linaro.org>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: linux-amlogic@lists.infradead.org
Cc: linux-gpio@vger.kernel.org
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202507220009.8HKbNP16-lkp@intel.com/
Signed-off-by: Alexey Gladkov <legion@kernel.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
---
drivers/pinctrl/meson/pinctrl-amlogic-a4.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/meson/pinctrl-amlogic-a4.c b/drivers/pinctrl/meson/pinctrl-amlogic-a4.c
index e34e984c2b38..6132710aff68 100644
--- a/drivers/pinctrl/meson/pinctrl-amlogic-a4.c
+++ b/drivers/pinctrl/meson/pinctrl-amlogic-a4.c
@@ -1093,7 +1093,7 @@ static const struct of_device_id aml_pctl_of_match[] = {
{ .compatible = "amlogic,pinctrl-s6", .data = &s6_priv_data, },
{ /* sentinel */ }
};
-MODULE_DEVICE_TABLE(of, aml_pctl_dt_match);
+MODULE_DEVICE_TABLE(of, aml_pctl_of_match);
static struct platform_driver aml_pctl_driver = {
.driver = {
--
2.50.1
^ permalink raw reply related
* [PATCH v6 4/9] scsi: Always define blogic_pci_tbl structure
From: Alexey Gladkov @ 2025-08-14 13:07 UTC (permalink / raw)
To: Nathan Chancellor, Nicolas Schier, Masahiro Yamada, Petr Pavlu,
Luis Chamberlain, Sami Tolvanen, Daniel Gomez
Cc: linux-kernel, linux-modules, linux-kbuild, Alexey Gladkov,
Khalid Aziz, Martin K. Petersen, linux-scsi, James Bottomley,
Arnd Bergmann, Damien Le Moal
In-Reply-To: <cover.1755170493.git.legion@kernel.org>
The blogic_pci_tbl structure is used by the MODULE_DEVICE_TABLE macro.
There is no longer a need to protect it with the MODULE condition, since
this no longer causes the compiler to warn about an unused variable.
To avoid warnings when -Wunused-const-variable option is used, mark it
as __maybe_unused for such configuration.
Cc: Khalid Aziz <khalid@gonehiking.org>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: linux-scsi@vger.kernel.org
Suggested-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Alexey Gladkov <legion@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
---
drivers/scsi/BusLogic.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/scsi/BusLogic.c b/drivers/scsi/BusLogic.c
index 1f100270cd38..82597bd96525 100644
--- a/drivers/scsi/BusLogic.c
+++ b/drivers/scsi/BusLogic.c
@@ -3715,7 +3715,6 @@ static void __exit blogic_exit(void)
__setup("BusLogic=", blogic_setup);
-#ifdef MODULE
/*static const struct pci_device_id blogic_pci_tbl[] = {
{ PCI_VENDOR_ID_BUSLOGIC, PCI_DEVICE_ID_BUSLOGIC_MULTIMASTER,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
@@ -3725,13 +3724,12 @@ __setup("BusLogic=", blogic_setup);
PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
{ }
};*/
-static const struct pci_device_id blogic_pci_tbl[] = {
+static const struct pci_device_id blogic_pci_tbl[] __maybe_unused = {
{PCI_DEVICE(PCI_VENDOR_ID_BUSLOGIC, PCI_DEVICE_ID_BUSLOGIC_MULTIMASTER)},
{PCI_DEVICE(PCI_VENDOR_ID_BUSLOGIC, PCI_DEVICE_ID_BUSLOGIC_MULTIMASTER_NC)},
{PCI_DEVICE(PCI_VENDOR_ID_BUSLOGIC, PCI_DEVICE_ID_BUSLOGIC_FLASHPOINT)},
{0, },
};
-#endif
MODULE_DEVICE_TABLE(pci, blogic_pci_tbl);
module_init(blogic_init);
--
2.50.1
^ permalink raw reply related
* [PATCH v6 3/9] kbuild: extract modules.builtin.modinfo from vmlinux.unstripped
From: Alexey Gladkov @ 2025-08-14 13:07 UTC (permalink / raw)
To: Nathan Chancellor, Nicolas Schier, Masahiro Yamada, Petr Pavlu,
Luis Chamberlain, Sami Tolvanen, Daniel Gomez
Cc: linux-kernel, linux-modules, linux-kbuild, Alexey Gladkov
In-Reply-To: <cover.1755170493.git.legion@kernel.org>
From: Masahiro Yamada <masahiroy@kernel.org>
Currently, we assume all the data for modules.builtin.modinfo are
available in vmlinux.o.
This makes it impossible for modpost, which is invoked after vmlinux.o,
to add additional module info.
This commit moves the modules.builtin.modinfo rule after modpost.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Alexey Gladkov <legion@kernel.org>
---
scripts/Makefile.vmlinux | 26 ++++++++++++++++++++++++++
scripts/Makefile.vmlinux_o | 26 +-------------------------
2 files changed, 27 insertions(+), 25 deletions(-)
diff --git a/scripts/Makefile.vmlinux b/scripts/Makefile.vmlinux
index e2ceeb9e168d..fdab5aa90215 100644
--- a/scripts/Makefile.vmlinux
+++ b/scripts/Makefile.vmlinux
@@ -96,6 +96,32 @@ targets += vmlinux
vmlinux: vmlinux.unstripped FORCE
$(call if_changed,strip_relocs)
+# modules.builtin.modinfo
+# ---------------------------------------------------------------------------
+
+OBJCOPYFLAGS_modules.builtin.modinfo := -j .modinfo -O binary
+
+targets += modules.builtin.modinfo
+modules.builtin.modinfo: vmlinux.unstripped FORCE
+ $(call if_changed,objcopy)
+
+# modules.builtin
+# ---------------------------------------------------------------------------
+
+__default: modules.builtin
+
+# The second line aids cases where multiple modules share the same object.
+
+quiet_cmd_modules_builtin = GEN $@
+ cmd_modules_builtin = \
+ tr '\0' '\n' < $< | \
+ sed -n 's/^[[:alnum:]:_]*\.file=//p' | \
+ tr ' ' '\n' | uniq | sed -e 's:^:kernel/:' -e 's/$$/.ko/' > $@
+
+targets += modules.builtin
+modules.builtin: modules.builtin.modinfo FORCE
+ $(call if_changed,modules_builtin)
+
# modules.builtin.ranges
# ---------------------------------------------------------------------------
ifdef CONFIG_BUILTIN_MODULE_RANGES
diff --git a/scripts/Makefile.vmlinux_o b/scripts/Makefile.vmlinux_o
index b024ffb3e201..23c8751285d7 100644
--- a/scripts/Makefile.vmlinux_o
+++ b/scripts/Makefile.vmlinux_o
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
PHONY := __default
-__default: vmlinux.o modules.builtin.modinfo modules.builtin
+__default: vmlinux.o
include include/config/auto.conf
include $(srctree)/scripts/Kbuild.include
@@ -73,30 +73,6 @@ vmlinux.o: $(initcalls-lds) vmlinux.a $(KBUILD_VMLINUX_LIBS) FORCE
targets += vmlinux.o
-# modules.builtin.modinfo
-# ---------------------------------------------------------------------------
-
-OBJCOPYFLAGS_modules.builtin.modinfo := -j .modinfo -O binary
-
-targets += modules.builtin.modinfo
-modules.builtin.modinfo: vmlinux.o FORCE
- $(call if_changed,objcopy)
-
-# modules.builtin
-# ---------------------------------------------------------------------------
-
-# The second line aids cases where multiple modules share the same object.
-
-quiet_cmd_modules_builtin = GEN $@
- cmd_modules_builtin = \
- tr '\0' '\n' < $< | \
- sed -n 's/^[[:alnum:]:_]*\.file=//p' | \
- tr ' ' '\n' | uniq | sed -e 's:^:kernel/:' -e 's/$$/.ko/' > $@
-
-targets += modules.builtin
-modules.builtin: modules.builtin.modinfo FORCE
- $(call if_changed,modules_builtin)
-
# Add FORCE to the prerequisites of a target to force it to be always rebuilt.
# ---------------------------------------------------------------------------
--
2.50.1
^ permalink raw reply related
* [PATCH v6 2/9] kbuild: keep .modinfo section in vmlinux.unstripped
From: Alexey Gladkov @ 2025-08-14 13:07 UTC (permalink / raw)
To: Nathan Chancellor, Nicolas Schier, Masahiro Yamada, Petr Pavlu,
Luis Chamberlain, Sami Tolvanen, Daniel Gomez
Cc: linux-kernel, linux-modules, linux-kbuild
In-Reply-To: <cover.1755170493.git.legion@kernel.org>
From: Masahiro Yamada <masahiroy@kernel.org>
Keep the .modinfo section during linking, but strip it from the final
vmlinux.
Adjust scripts/mksysmap to exclude modinfo symbols from kallsyms.
This change will allow the next commit to extract the .modinfo section
from the vmlinux.unstripped intermediate.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
---
include/asm-generic/vmlinux.lds.h | 2 +-
scripts/Makefile.vmlinux | 2 +-
scripts/mksysmap | 3 +++
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index ae2d2359b79e..cfa63860dfd4 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -831,6 +831,7 @@ defined(CONFIG_AUTOFDO_CLANG) || defined(CONFIG_PROPELLER_CLANG)
/* Required sections not related to debugging. */
#define ELF_DETAILS \
+ .modinfo : { *(.modinfo) } \
.comment 0 : { *(.comment) } \
.symtab 0 : { *(.symtab) } \
.strtab 0 : { *(.strtab) } \
@@ -1044,7 +1045,6 @@ defined(CONFIG_AUTOFDO_CLANG) || defined(CONFIG_PROPELLER_CLANG)
*(.discard.*) \
*(.export_symbol) \
*(.no_trim_symbol) \
- *(.modinfo) \
/* ld.bfd warns about .gnu.version* even when not emitted */ \
*(.gnu.version*) \
diff --git a/scripts/Makefile.vmlinux b/scripts/Makefile.vmlinux
index 4f2d4c3fb737..e2ceeb9e168d 100644
--- a/scripts/Makefile.vmlinux
+++ b/scripts/Makefile.vmlinux
@@ -86,7 +86,7 @@ endif
# vmlinux
# ---------------------------------------------------------------------------
-remove-section-y :=
+remove-section-y := .modinfo
remove-section-$(CONFIG_ARCH_VMLINUX_NEEDS_RELOCS) += '.rel*'
quiet_cmd_strip_relocs = OBJCOPY $@
diff --git a/scripts/mksysmap b/scripts/mksysmap
index 3accbdb269ac..a607a0059d11 100755
--- a/scripts/mksysmap
+++ b/scripts/mksysmap
@@ -79,6 +79,9 @@
/ _SDA_BASE_$/d
/ _SDA2_BASE_$/d
+# MODULE_INFO()
+/ __UNIQUE_ID_modinfo[0-9]*$/d
+
# ---------------------------------------------------------------------------
# Ignored patterns
# (symbols that contain the pattern are ignored)
--
2.50.1
^ permalink raw reply related
* [PATCH v6 1/9] kbuild: always create intermediate vmlinux.unstripped
From: Alexey Gladkov @ 2025-08-14 13:07 UTC (permalink / raw)
To: Nathan Chancellor, Nicolas Schier, Masahiro Yamada, Petr Pavlu,
Luis Chamberlain, Sami Tolvanen, Daniel Gomez
Cc: linux-kernel, linux-modules, linux-kbuild
In-Reply-To: <cover.1755170493.git.legion@kernel.org>
From: Masahiro Yamada <masahiroy@kernel.org>
Generate the intermediate vmlinux.unstripped regardless of
CONFIG_ARCH_VMLINUX_NEEDS_RELOCS.
If CONFIG_ARCH_VMLINUX_NEEDS_RELOCS is unset, vmlinux.unstripped and
vmlinux are identiacal.
This simplifies the build rule, and allows to strip more sections
by adding them to remove-section-y.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
---
scripts/Makefile.vmlinux | 45 ++++++++++++++++++++--------------------
1 file changed, 22 insertions(+), 23 deletions(-)
diff --git a/scripts/Makefile.vmlinux b/scripts/Makefile.vmlinux
index b64862dc6f08..4f2d4c3fb737 100644
--- a/scripts/Makefile.vmlinux
+++ b/scripts/Makefile.vmlinux
@@ -9,20 +9,6 @@ include $(srctree)/scripts/Makefile.lib
targets :=
-ifdef CONFIG_ARCH_VMLINUX_NEEDS_RELOCS
-vmlinux-final := vmlinux.unstripped
-
-quiet_cmd_strip_relocs = RSTRIP $@
- cmd_strip_relocs = $(OBJCOPY) --remove-section='.rel*' --remove-section=!'.rel*.dyn' $< $@
-
-vmlinux: $(vmlinux-final) FORCE
- $(call if_changed,strip_relocs)
-
-targets += vmlinux
-else
-vmlinux-final := vmlinux
-endif
-
%.o: %.c FORCE
$(call if_changed_rule,cc_o_c)
@@ -61,19 +47,19 @@ targets += .builtin-dtbs-list
ifdef CONFIG_GENERIC_BUILTIN_DTB
targets += .builtin-dtbs.S .builtin-dtbs.o
-$(vmlinux-final): .builtin-dtbs.o
+vmlinux.unstripped: .builtin-dtbs.o
endif
-# vmlinux
+# vmlinux.unstripped
# ---------------------------------------------------------------------------
ifdef CONFIG_MODULES
targets += .vmlinux.export.o
-$(vmlinux-final): .vmlinux.export.o
+vmlinux.unstripped: .vmlinux.export.o
endif
ifdef CONFIG_ARCH_WANTS_PRE_LINK_VMLINUX
-$(vmlinux-final): arch/$(SRCARCH)/tools/vmlinux.arch.o
+vmlinux.unstripped: arch/$(SRCARCH)/tools/vmlinux.arch.o
arch/$(SRCARCH)/tools/vmlinux.arch.o: vmlinux.o FORCE
$(Q)$(MAKE) $(build)=arch/$(SRCARCH)/tools $@
@@ -86,17 +72,30 @@ cmd_link_vmlinux = \
$< "$(LD)" "$(KBUILD_LDFLAGS)" "$(LDFLAGS_vmlinux)" "$@"; \
$(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
-targets += $(vmlinux-final)
-$(vmlinux-final): scripts/link-vmlinux.sh vmlinux.o $(KBUILD_LDS) FORCE
+targets += vmlinux.unstripped
+vmlinux.unstripped: scripts/link-vmlinux.sh vmlinux.o $(KBUILD_LDS) FORCE
+$(call if_changed_dep,link_vmlinux)
ifdef CONFIG_DEBUG_INFO_BTF
-$(vmlinux-final): $(RESOLVE_BTFIDS)
+vmlinux.unstripped: $(RESOLVE_BTFIDS)
endif
ifdef CONFIG_BUILDTIME_TABLE_SORT
-$(vmlinux-final): scripts/sorttable
+vmlinux.unstripped: scripts/sorttable
endif
+# vmlinux
+# ---------------------------------------------------------------------------
+
+remove-section-y :=
+remove-section-$(CONFIG_ARCH_VMLINUX_NEEDS_RELOCS) += '.rel*'
+
+quiet_cmd_strip_relocs = OBJCOPY $@
+ cmd_strip_relocs = $(OBJCOPY) $(addprefix --remove-section=,$(remove-section-y)) $< $@
+
+targets += vmlinux
+vmlinux: vmlinux.unstripped FORCE
+ $(call if_changed,strip_relocs)
+
# modules.builtin.ranges
# ---------------------------------------------------------------------------
ifdef CONFIG_BUILTIN_MODULE_RANGES
@@ -110,7 +109,7 @@ modules.builtin.ranges: $(srctree)/scripts/generate_builtin_ranges.awk \
modules.builtin vmlinux.map vmlinux.o.map FORCE
$(call if_changed,modules_builtin_ranges)
-vmlinux.map: $(vmlinux-final)
+vmlinux.map: vmlinux.unstripped
@:
endif
--
2.50.1
^ permalink raw reply related
* [PATCH v6 0/9] Add generated modalias to modules.builtin.modinfo
From: Alexey Gladkov @ 2025-08-14 13:07 UTC (permalink / raw)
To: Nathan Chancellor, Nicolas Schier, Masahiro Yamada, Petr Pavlu,
Luis Chamberlain, Sami Tolvanen, Daniel Gomez
Cc: linux-kernel, linux-modules, linux-kbuild, Alexey Gladkov
The modules.builtin.modinfo file is used by userspace (kmod to be specific) to
get information about builtin modules. Among other information about the module,
information about module aliases is stored. This is very important to determine
that a particular modalias will be handled by a module that is inside the
kernel.
There are several mechanisms for creating modalias for modules:
The first is to explicitly specify the MODULE_ALIAS of the macro. In this case,
the aliases go into the '.modinfo' section of the module if it is compiled
separately or into vmlinux.o if it is builtin into the kernel.
The second is the use of MODULE_DEVICE_TABLE followed by the use of the
modpost utility. In this case, vmlinux.o no longer has this information and
does not get it into modules.builtin.modinfo.
For example:
$ modinfo pci:v00008086d0000A36Dsv00001043sd00008694bc0Csc03i30
modinfo: ERROR: Module pci:v00008086d0000A36Dsv00001043sd00008694bc0Csc03i30 not found.
$ modinfo xhci_pci
name: xhci_pci
filename: (builtin)
license: GPL
file: drivers/usb/host/xhci-pci
description: xHCI PCI Host Controller Driver
The builtin module is missing alias "pci:v*d*sv*sd*bc0Csc03i30*" which will be
generated by modpost if the module is built separately.
To fix this it is necessary to add the generated by modpost modalias to
modules.builtin.modinfo. Fortunately modpost already generates .vmlinux.export.c
for exported symbols. It is possible to add `.modinfo` for builtin modules and
modify the build system so that `.modinfo` section is extracted from the
intermediate vmlinux after modpost is executed.
---
Notes:
- v6:
* Rebase to v6.17-rc1-16-g8742b2d8935f to pick up the fixes made by Masahiro Yamada.
* Fix an issue on i386 configs caused by the use of string_32.h.
* v5: https://lore.kernel.org/all/cover.1753354215.git.legion@kernel.org/
- v5:
* Rebase to v6.16-rc6-281-gf4a40a4282f4 to pick up the fixes made by Masahiro Yamada.
* Attempt to fix linker warning on s390.
* Fix typo in pinctrl/meson found by the kernel test robot.
* v4: https://lore.kernel.org/all/cover.1750511018.git.legion@kernel.org/
- v4:
* Rework the patchset based on top of Masahiro Yamada's patches.
* Add removal of unnecessary __mod_device_table__* symbols to avoid symbol
table growth in vmlinux.
* rust code takes into account changes in __mod_device_table__*.
* v3: https://lore.kernel.org/all/cover.1748335606.git.legion@kernel.org/
- v3:
* Add `Reviewed-by` tag to patches from Petr Pavlu.
* Rebase to v6.15.
* v2: https://lore.kernel.org/all/20250509164237.2886508-1-legion@kernel.org/
- v2:
* Drop patch for mfd because it was already applied and is in linux-next.
* The generation of aliases for builtin modules has been redone as
suggested by Masahiro Yamada.
* Rebase to v6.15-rc5-136-g9c69f8884904
* v1: https://lore.kernel.org/all/cover.1745591072.git.legion@kernel.org/
Alexey Gladkov (6):
scsi: Always define blogic_pci_tbl structure
pinctrl: meson: Fix typo in device table macro
modpost: Add modname to mod_device_table alias
modpost: Create modalias for builtin modules
kbuild: vmlinux.unstripped should always depend on .vmlinux.export.o
s390: vmlinux.lds.S: Reorder sections
Masahiro Yamada (3):
kbuild: always create intermediate vmlinux.unstripped
kbuild: keep .modinfo section in vmlinux.unstripped
kbuild: extract modules.builtin.modinfo from vmlinux.unstripped
arch/s390/kernel/vmlinux.lds.S | 10 +--
drivers/pinctrl/meson/pinctrl-amlogic-a4.c | 2 +-
drivers/scsi/BusLogic.c | 4 +-
include/asm-generic/vmlinux.lds.h | 2 +-
include/linux/module.h | 18 +++--
rust/kernel/device_id.rs | 8 +--
scripts/Makefile.vmlinux | 77 ++++++++++++++--------
scripts/Makefile.vmlinux_o | 26 +-------
scripts/link-vmlinux.sh | 5 +-
scripts/mksysmap | 6 ++
scripts/mod/file2alias.c | 34 ++++++++--
scripts/mod/modpost.c | 15 +++++
scripts/mod/modpost.h | 2 +
13 files changed, 130 insertions(+), 79 deletions(-)
--
2.50.1
^ permalink raw reply
* Re: [PATCH v2] params: Replace deprecated strcpy() with strscpy() and memcpy()
From: Petr Pavlu @ 2025-08-13 14:14 UTC (permalink / raw)
To: Thorsten Blum
Cc: Thomas Weißschuh, Shyam Saini, Luis Chamberlain,
Dmitry Antipov, linux-kernel, linux-modules, Daniel Gomez
In-Reply-To: <20250813132200.184064-2-thorsten.blum@linux.dev>
On 8/13/25 3:21 PM, Thorsten Blum wrote:
> strcpy() is deprecated; use strscpy() and memcpy() instead.
>
> In param_set_copystring(), we can safely use memcpy() because we already
> know the length of the source string 'val' and that it is guaranteed to
> be NUL-terminated within the first 'kps->maxlen' bytes.
>
> Link: https://github.com/KSPP/linux/issues/88
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
> Changes in v2:
> - Use memcpy() in param_set_copystring() as suggested by Petr Pavlu
> - Link to v1: https://lore.kernel.org/lkml/20250810214456.2236-1-thorsten.blum@linux.dev/
> ---
> kernel/params.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/params.c b/kernel/params.c
> index b92d64161b75..b96cfd693c99 100644
> --- a/kernel/params.c
> +++ b/kernel/params.c
> @@ -513,13 +513,14 @@ EXPORT_SYMBOL(param_array_ops);
> int param_set_copystring(const char *val, const struct kernel_param *kp)
> {
> const struct kparam_string *kps = kp->str;
> + const size_t len = strnlen(val, kps->maxlen);
>
> - if (strnlen(val, kps->maxlen) == kps->maxlen) {
> + if (len == kps->maxlen) {
> pr_err("%s: string doesn't fit in %u chars.\n",
> kp->name, kps->maxlen-1);
> return -ENOSPC;
> }
> - strcpy(kps->string, val);
> + memcpy(kps->string, val, len + 1);
> return 0;
> }
> EXPORT_SYMBOL(param_set_copystring);
> @@ -841,7 +842,7 @@ static void __init param_sysfs_builtin(void)
> dot = strchr(kp->name, '.');
> if (!dot) {
> /* This happens for core_param() */
> - strcpy(modname, "kernel");
> + strscpy(modname, "kernel");
> name_len = 0;
> } else {
> name_len = dot - kp->name + 1;
Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>
--
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH] params: Replace deprecated strcpy() with strscpy()
From: Thorsten Blum @ 2025-08-13 12:15 UTC (permalink / raw)
To: Petr Pavlu
Cc: Thomas Weißschuh, Shyam Saini, Luis Chamberlain,
Dmitry Antipov, linux-kernel, linux-modules
In-Reply-To: <f0a77c72-8fad-4fc5-9198-2a9c7c97a489@suse.com>
On 13. Aug 2025, at 13:42, Petr Pavlu wrote:
> On 8/13/25 11:33 AM, Thorsten Blum wrote:
>> On 13. Aug 2025, at 10:59, Petr Pavlu wrote:
>>> Since the code already calculated the length of val and that it fits
>>> into kps->string, is there any advantage (or disadvantage) to using
>>> strscpy() over memcpy()?
>>
>> strscpy() guarantees that the destination buffer 'kps->string' is always
>> NUL-terminated, even if the source 'val' is not. memcpy() just copies
>> the bytes as they are.
>>
>> If it were guaranteed that 'val' is always NUL-terminated, memcpy()
>> would be fine too, but since param_set_copystring() is exported, we
>> probably can't make that assumption.
>
> The function param_set_copystring() checks using
> 'strnlen(val, kps->maxlen) == kps->maxlen' if val contains NUL in the
> first kps->maxlen bytes. It can use memcpy() instead of strscpy() to
> avoid repeating this work.
I see, and yes
memcpy(kps->string, val, len + 1);
would then be slightly more efficient because strscpy() would just
recompute the length before calling memcpy() internally.
I'll submit a v2.
Thanks,
Thorsten
^ permalink raw reply
* Re: [PATCH] params: Replace deprecated strcpy() with strscpy()
From: Petr Pavlu @ 2025-08-13 11:42 UTC (permalink / raw)
To: Thorsten Blum
Cc: Thomas Weißschuh, Shyam Saini, Luis Chamberlain,
Dmitry Antipov, linux-kernel, linux-modules
In-Reply-To: <F640B308-C8C4-439B-8217-98FFC10BB76B@linux.dev>
On 8/13/25 11:33 AM, Thorsten Blum wrote:
> Hi Petr,
>
> On 13. Aug 2025, at 10:59, Petr Pavlu wrote:
>> Since the code already calculated the length of val and that it fits
>> into kps->string, is there any advantage (or disadvantage) to using
>> strscpy() over memcpy()?
>
> strscpy() guarantees that the destination buffer 'kps->string' is always
> NUL-terminated, even if the source 'val' is not. memcpy() just copies
> the bytes as they are.
>
> If it were guaranteed that 'val' is always NUL-terminated, memcpy()
> would be fine too, but since param_set_copystring() is exported, we
> probably can't make that assumption.
The function param_set_copystring() checks using
'strnlen(val, kps->maxlen) == kps->maxlen' if val contains NUL in the
first kps->maxlen bytes. It can use memcpy() instead of strscpy() to
avoid repeating this work.
-- Petr
^ permalink raw reply
* Re: [PATCH] params: Replace deprecated strcpy() with strscpy()
From: Thorsten Blum @ 2025-08-13 9:33 UTC (permalink / raw)
To: Petr Pavlu
Cc: Thomas Weißschuh, Shyam Saini, Luis Chamberlain,
Dmitry Antipov, linux-kernel, linux-modules
In-Reply-To: <5d334a1f-0dbd-4e25-bbc5-b01aca369385@suse.com>
Hi Petr,
On 13. Aug 2025, at 10:59, Petr Pavlu wrote:
> Since the code already calculated the length of val and that it fits
> into kps->string, is there any advantage (or disadvantage) to using
> strscpy() over memcpy()?
strscpy() guarantees that the destination buffer 'kps->string' is always
NUL-terminated, even if the source 'val' is not. memcpy() just copies
the bytes as they are.
If it were guaranteed that 'val' is always NUL-terminated, memcpy()
would be fine too, but since param_set_copystring() is exported, we
probably can't make that assumption.
> I think this can go through the modules tree. I've CC'd the mailing
> list.
Thanks,
Thorsten
^ permalink raw reply
* Re: [PATCH] params: Replace deprecated strcpy() with strscpy()
From: Petr Pavlu @ 2025-08-13 8:59 UTC (permalink / raw)
To: Thorsten Blum
Cc: Thomas Weißschuh, Shyam Saini, Luis Chamberlain,
Dmitry Antipov, linux-kernel, linux-modules
In-Reply-To: <20250810214456.2236-1-thorsten.blum@linux.dev>
On 8/10/25 11:44 PM, Thorsten Blum wrote:
> strcpy() is deprecated; use strscpy() instead.
>
> Link: https://github.com/KSPP/linux/issues/88
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
> kernel/params.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/params.c b/kernel/params.c
> index b92d64161b75..88765f2d5d56 100644
> --- a/kernel/params.c
> +++ b/kernel/params.c
> @@ -513,13 +513,14 @@ EXPORT_SYMBOL(param_array_ops);
> int param_set_copystring(const char *val, const struct kernel_param *kp)
> {
> const struct kparam_string *kps = kp->str;
> + const size_t len = strnlen(val, kps->maxlen);
>
> - if (strnlen(val, kps->maxlen) == kps->maxlen) {
> + if (len == kps->maxlen) {
> pr_err("%s: string doesn't fit in %u chars.\n",
> kp->name, kps->maxlen-1);
> return -ENOSPC;
> }
> - strcpy(kps->string, val);
> + strscpy(kps->string, val, len + 1);
> return 0;
> }
Since the code already calculated the length of val and that it fits
into kps->string, is there any advantage (or disadvantage) to using
strscpy() over memcpy()?
> EXPORT_SYMBOL(param_set_copystring);
> @@ -841,7 +842,7 @@ static void __init param_sysfs_builtin(void)
> dot = strchr(kp->name, '.');
> if (!dot) {
> /* This happens for core_param() */
> - strcpy(modname, "kernel");
> + strscpy(modname, "kernel");
> name_len = 0;
> } else {
> name_len = dot - kp->name + 1;
I think this can go through the modules tree. I've CC'd the mailing
list.
--
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH v4] module: Rename EXPORT_SYMBOL_GPL_FOR_MODULES to EXPORT_SYMBOL_FOR_MODULES
From: Daniel Gomez @ 2025-08-12 7:54 UTC (permalink / raw)
To: Christian Brauner, Vlastimil Babka
Cc: Christoph Hellwig, Peter Zijlstra, David Hildenbrand,
Shivank Garg, Greg Kroah-Hartman, Jiri Slaby (SUSE),
Stephen Rothwell, linux-doc, linux-kernel, linux-modules,
linux-kbuild, linux-fsdevel, Nicolas Schier, Daniel Gomez,
Linus Torvalds, Matthias Maennich, Jonathan Corbet,
Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Nathan Chancellor,
Alexander Viro, Jan Kara
In-Reply-To: <20250811-wachen-formel-29492e81ee59@brauner>
On 11/08/2025 07.18, Christian Brauner wrote:
> On Fri, 08 Aug 2025 15:28:47 +0200, Vlastimil Babka wrote:
>> Christoph suggested that the explicit _GPL_ can be dropped from the
>> module namespace export macro, as it's intended for in-tree modules
>> only. It would be possible to restrict it technically, but it was
>> pointed out [2] that some cases of using an out-of-tree build of an
>> in-tree module with the same name are legitimate. But in that case those
>> also have to be GPL anyway so it's unnecessary to spell it out in the
>> macro name.
>>
>> [...]
>
> Ok, so last I remember we said that this is going upstream rather sooner
> than later before we keep piling on users. If that's still the case I'll
> take it via vfs.fixes unless I hear objections.
This used to go through Masahiro's kbuild tree. However, since he is not
available anymore [1] I think it makes sense that this goes through the modules
tree. The only reason we waited until rc1 was released was because of Greg's
advise [2]. Let me know if that makes sense to you and if so, I'll merge this
ASAP.
Link: https://lore.kernel.org/all/CAK7LNAQW8b_HEQhWBzaQSPy=qDmKkqz6URtpJ+BYG8eq-sWRwA@mail.gmail.com/ [1]
Link: https://lore.kernel.org/all/2025072219-dollhouse-margarita-de67@gregkh/ [2]
^ permalink raw reply
* Re: [PATCH v4] module: Rename EXPORT_SYMBOL_GPL_FOR_MODULES to EXPORT_SYMBOL_FOR_MODULES
From: Christian Brauner @ 2025-08-11 14:18 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Christian Brauner, Christoph Hellwig, Peter Zijlstra,
David Hildenbrand, Shivank Garg, Greg Kroah-Hartman,
Jiri Slaby (SUSE), Stephen Rothwell, linux-doc, linux-kernel,
linux-modules, linux-kbuild, linux-fsdevel, Nicolas Schier,
Daniel Gomez, Linus Torvalds, Matthias Maennich, Jonathan Corbet,
Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Nathan Chancellor,
Alexander Viro, Jan Kara
In-Reply-To: <20250808-export_modules-v4-1-426945bcc5e1@suse.cz>
On Fri, 08 Aug 2025 15:28:47 +0200, Vlastimil Babka wrote:
> Christoph suggested that the explicit _GPL_ can be dropped from the
> module namespace export macro, as it's intended for in-tree modules
> only. It would be possible to restrict it technically, but it was
> pointed out [2] that some cases of using an out-of-tree build of an
> in-tree module with the same name are legitimate. But in that case those
> also have to be GPL anyway so it's unnecessary to spell it out in the
> macro name.
>
> [...]
Ok, so last I remember we said that this is going upstream rather sooner
than later before we keep piling on users. If that's still the case I'll
take it via vfs.fixes unless I hear objections.
---
Applied to the vfs.fixes branch of the vfs/vfs.git tree.
Patches in the vfs.fixes branch should appear in linux-next soon.
Please report any outstanding bugs that were missed during review in a
new review to the original patch series allowing us to drop it.
It's encouraged to provide Acked-bys and Reviewed-bys even though the
patch has now been applied. If possible patch trailers will be updated.
Note that commit hashes shown below are subject to change due to rebase,
trailer updates or similar. If in doubt, please check the listed branch.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
branch: vfs.fixes
[1/1] module: Rename EXPORT_SYMBOL_GPL_FOR_MODULES to EXPORT_SYMBOL_FOR_MODULES
https://git.kernel.org/vfs/vfs/c/6d3c3ca4c77e
^ permalink raw reply
* [PATCH AUTOSEL 6.16-6.1] module: Prevent silent truncation of module name in delete_module(2)
From: Sasha Levin @ 2025-08-08 15:30 UTC (permalink / raw)
To: patches, stable
Cc: Petr Pavlu, Daniel Gomez, Sasha Levin, mcgrof, da.gomez,
linux-modules, linux-kernel
In-Reply-To: <20250808153054.1250675-1-sashal@kernel.org>
From: Petr Pavlu <petr.pavlu@suse.com>
[ Upstream commit a6323bd4e611567913e23df5b58f2d4e4da06789 ]
Passing a module name longer than MODULE_NAME_LEN to the delete_module
syscall results in its silent truncation. This really isn't much of
a problem in practice, but it could theoretically lead to the removal of an
incorrect module. It is more sensible to return ENAMETOOLONG or ENOENT in
such a case.
Update the syscall to return ENOENT, as documented in the delete_module(2)
man page to mean "No module by that name exists." This is appropriate
because a module with a name longer than MODULE_NAME_LEN cannot be loaded
in the first place.
Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
Reviewed-by: Daniel Gomez <da.gomez@samsung.com>
Link: https://lore.kernel.org/r/20250630143535.267745-2-petr.pavlu@suse.com
Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Based on my analysis, here's my assessment:
**Backport Status: YES**
This commit should be backported to stable kernel trees for the
following reasons:
1. **Security Fix for Silent Truncation**: The commit fixes a security-
relevant issue where module names longer than MODULE_NAME_LEN (56
bytes on 64-bit systems) are silently truncated in the
delete_module() syscall. This could theoretically lead to
unintentionally removing the wrong module if two modules share the
same truncated prefix.
2. **Minimal and Contained Change**: The fix is very small and localized
- it only modifies the delete_module syscall implementation in
kernel/module/main.c. The changes are:
- Changes from `strncpy_from_user(name, name_user,
MODULE_NAME_LEN-1)` to `strncpy_from_user(name, name_user,
MODULE_NAME_LEN)`
- Adds proper length checking: `if (len == 0 || len ==
MODULE_NAME_LEN) return -ENOENT;`
- Returns the correct error code (ENOENT) for oversized names
3. **Follows Stable Tree Rules**:
- Fixes a bug that could affect users (incorrect module removal)
- Very low risk of regression - the change only affects error
handling for invalid input
- No new features or architectural changes
- Improves consistency with documented behavior (delete_module(2) man
page)
4. **Prevents Inconsistent Behavior**: The commit message correctly
points out that modules with names longer than MODULE_NAME_LEN cannot
be loaded in the first place, so returning ENOENT for such names in
delete_module makes the behavior consistent across module operations.
5. **Clear Bug Fix**: The old code would accept a 57+ character module
name, truncate it to 56 characters, and potentially remove a
different module. The new code properly rejects such names with
ENOENT, preventing this dangerous silent truncation.
The change is defensive programming that prevents a potential security
issue without introducing any backward compatibility concerns, making it
an ideal candidate for stable backporting.
kernel/module/main.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/kernel/module/main.c b/kernel/module/main.c
index c2c08007029d..cbd637627eb4 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -751,14 +751,16 @@ SYSCALL_DEFINE2(delete_module, const char __user *, name_user,
struct module *mod;
char name[MODULE_NAME_LEN];
char buf[MODULE_FLAGS_BUF_SIZE];
- int ret, forced = 0;
+ int ret, len, forced = 0;
if (!capable(CAP_SYS_MODULE) || modules_disabled)
return -EPERM;
- if (strncpy_from_user(name, name_user, MODULE_NAME_LEN-1) < 0)
- return -EFAULT;
- name[MODULE_NAME_LEN-1] = '\0';
+ len = strncpy_from_user(name, name_user, MODULE_NAME_LEN);
+ if (len == 0 || len == MODULE_NAME_LEN)
+ return -ENOENT;
+ if (len < 0)
+ return len;
audit_log_kern_module(name);
--
2.39.5
^ permalink raw reply related
* Re: [PATCH v4] module: Rename EXPORT_SYMBOL_GPL_FOR_MODULES to EXPORT_SYMBOL_FOR_MODULES
From: David Hildenbrand @ 2025-08-08 14:17 UTC (permalink / raw)
To: Vlastimil Babka, Daniel Gomez, Linus Torvalds, Matthias Maennich,
Jonathan Corbet, Luis Chamberlain, Petr Pavlu, Sami Tolvanen,
Nathan Chancellor, Nicolas Schier, Alexander Viro,
Christian Brauner, Jan Kara
Cc: Christoph Hellwig, Peter Zijlstra, Shivank Garg,
Greg Kroah-Hartman, Jiri Slaby (SUSE), Stephen Rothwell,
linux-doc, linux-kernel, linux-modules, linux-kbuild,
linux-fsdevel
In-Reply-To: <20250808-export_modules-v4-1-426945bcc5e1@suse.cz>
On 08.08.25 15:28, Vlastimil Babka wrote:
> Christoph suggested that the explicit _GPL_ can be dropped from the
> module namespace export macro, as it's intended for in-tree modules
> only. It would be possible to restrict it technically, but it was
> pointed out [2] that some cases of using an out-of-tree build of an
> in-tree module with the same name are legitimate.
I'm wondering if we could revisit that idea later, and have a config
option that enables that. The use cases so far were mostly around
testing IIRC, where people already run their own debug kernel or sth.
like that.
--
Cheers,
David / dhildenb
^ permalink raw reply
* [PATCH v4] module: Rename EXPORT_SYMBOL_GPL_FOR_MODULES to EXPORT_SYMBOL_FOR_MODULES
From: Vlastimil Babka @ 2025-08-08 13:28 UTC (permalink / raw)
To: Daniel Gomez, Linus Torvalds, Matthias Maennich, Jonathan Corbet,
Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Nathan Chancellor,
Nicolas Schier, Alexander Viro, Christian Brauner, Jan Kara
Cc: Christoph Hellwig, Peter Zijlstra, David Hildenbrand,
Shivank Garg, Greg Kroah-Hartman, Jiri Slaby (SUSE),
Stephen Rothwell, linux-doc, linux-kernel, linux-modules,
linux-kbuild, linux-fsdevel, Vlastimil Babka, Nicolas Schier
Christoph suggested that the explicit _GPL_ can be dropped from the
module namespace export macro, as it's intended for in-tree modules
only. It would be possible to restrict it technically, but it was
pointed out [2] that some cases of using an out-of-tree build of an
in-tree module with the same name are legitimate. But in that case those
also have to be GPL anyway so it's unnecessary to spell it out in the
macro name.
Link: https://lore.kernel.org/all/aFleJN_fE-RbSoFD@infradead.org/ [1]
Link: https://lore.kernel.org/all/CAK7LNATRkZHwJGpojCnvdiaoDnP%2BaeUXgdey5sb_8muzdWTMkA@mail.gmail.com/ [2]
Suggested-by: Christoph Hellwig <hch@infradead.org>
Reviewed-by: Shivank Garg <shivankg@amd.com>
Acked-by: David Hildenbrand <david@redhat.com>
Acked-by: Nicolas Schier <n.schier@avm.de>
Reviewed-by: Daniel Gomez <da.gomez@samsung.com>
Reviewed-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
---
In v3, Greg suggested [0] applying after 6.17-rc1. At this moment I can
see all new users of EXPORT_SYMBOL_GPL_FOR_MODULES() pending for 6.17
were merged already and nothing more is in next-20250808. Thus this
rebased version renames all usages. If we merge this before rc1 then
people basing their branches with more new usages (AFAIK KVM might be)
on rc1 will be covered. If this is merged after rc1, they will have to
rebase, as Greg said. I guess it's up to Linus and Daniel.
Christian asked [1] for EXPORT_SYMBOL_FOR_MODULES() without the _GPL_
part to avoid controversy converting selected existing EXPORT_SYMBOL().
Christoph argued [2] that the _FOR_MODULES() export is intended for
in-tree modules and thus GPL is implied anyway and can be simply dropped
from the export macro name. Peter agreed [3] about the intention for
in-tree modules only, although nothing currently enforces it.
It seemed straightforward to add this enforcement, so v1 did that. But
there were concerns of breaking the (apparently legitimate) usecases of
loading an updated/development out of tree built version of an in-tree
module.
So leave out the enforcement part and just drop the _GPL_ from the
export macro name and so we're left with EXPORT_SYMBOL_FOR_MODULES()
only. Any in-tree module used in an out-of-tree way will have to be GPL
anyway by definition.
[0] https://lore.kernel.org/all/2025072219-dollhouse-margarita-de67@gregkh/
[1] https://lore.kernel.org/all/20250623-warmwasser-giftig-ff656fce89ad@brauner/
[2] https://lore.kernel.org/all/aFleJN_fE-RbSoFD@infradead.org/
[3] https://lore.kernel.org/all/20250623142836.GT1613200@noisy.programming.kicks-ass.net/
---
Changes in v4:
- rebase to current mainline, rename new usages in drivers/tty/serial/8250/8250_rsa.c
- Link to v3: https://patch.msgid.link/20250715-export_modules-v3-1-11fffc67dff7@suse.cz
Changes in v3:
- Clarified the macro documentation about in-tree intention and GPL
implications, per Daniel.
- Applied tags.
- Link to v2: https://patch.msgid.link/20250711-export_modules-v2-1-b59b6fad413a@suse.cz
Changes in v2:
- drop the patch to restrict module namespace export for in-tree modules
- fix a pre-existing documentation typo (Nicolas Schier)
- Link to v1: https://patch.msgid.link/20250708-export_modules-v1-0-fbf7a282d23f@suse.cz
---
Documentation/core-api/symbol-namespaces.rst | 11 ++++++-----
drivers/tty/serial/8250/8250_rsa.c | 8 ++++----
fs/anon_inodes.c | 2 +-
include/linux/export.h | 2 +-
4 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/Documentation/core-api/symbol-namespaces.rst b/Documentation/core-api/symbol-namespaces.rst
index 32fc73dc5529e8844c2ce2580987155bcd13cd09..034898e81ba201097330ab9875429e7d3fa30c0f 100644
--- a/Documentation/core-api/symbol-namespaces.rst
+++ b/Documentation/core-api/symbol-namespaces.rst
@@ -76,20 +76,21 @@ A second option to define the default namespace is directly in the compilation
within the corresponding compilation unit before the #include for
<linux/export.h>. Typically it's placed before the first #include statement.
-Using the EXPORT_SYMBOL_GPL_FOR_MODULES() macro
------------------------------------------------
+Using the EXPORT_SYMBOL_FOR_MODULES() macro
+-------------------------------------------
Symbols exported using this macro are put into a module namespace. This
-namespace cannot be imported.
+namespace cannot be imported. These exports are GPL-only as they are only
+intended for in-tree modules.
The macro takes a comma separated list of module names, allowing only those
modules to access this symbol. Simple tail-globs are supported.
For example::
- EXPORT_SYMBOL_GPL_FOR_MODULES(preempt_notifier_inc, "kvm,kvm-*")
+ EXPORT_SYMBOL_FOR_MODULES(preempt_notifier_inc, "kvm,kvm-*")
-will limit usage of this symbol to modules whoes name matches the given
+will limit usage of this symbol to modules whose name matches the given
patterns.
How to use Symbols exported in Namespaces
diff --git a/drivers/tty/serial/8250/8250_rsa.c b/drivers/tty/serial/8250/8250_rsa.c
index d34093cc03ad9407f7117dda49554625c14e019a..12a65b79583c03e73bd8f3439b8b541c027f242f 100644
--- a/drivers/tty/serial/8250/8250_rsa.c
+++ b/drivers/tty/serial/8250/8250_rsa.c
@@ -147,7 +147,7 @@ void rsa_enable(struct uart_8250_port *up)
if (up->port.uartclk == SERIAL_RSA_BAUD_BASE * 16)
serial_out(up, UART_RSA_FRR, 0);
}
-EXPORT_SYMBOL_GPL_FOR_MODULES(rsa_enable, "8250_base");
+EXPORT_SYMBOL_FOR_MODULES(rsa_enable, "8250_base");
/*
* Attempts to turn off the RSA FIFO and resets the RSA board back to 115kbps compat mode. It is
@@ -179,7 +179,7 @@ void rsa_disable(struct uart_8250_port *up)
up->port.uartclk = SERIAL_RSA_BAUD_BASE_LO * 16;
uart_port_unlock_irq(&up->port);
}
-EXPORT_SYMBOL_GPL_FOR_MODULES(rsa_disable, "8250_base");
+EXPORT_SYMBOL_FOR_MODULES(rsa_disable, "8250_base");
void rsa_autoconfig(struct uart_8250_port *up)
{
@@ -192,7 +192,7 @@ void rsa_autoconfig(struct uart_8250_port *up)
if (__rsa_enable(up))
up->port.type = PORT_RSA;
}
-EXPORT_SYMBOL_GPL_FOR_MODULES(rsa_autoconfig, "8250_base");
+EXPORT_SYMBOL_FOR_MODULES(rsa_autoconfig, "8250_base");
void rsa_reset(struct uart_8250_port *up)
{
@@ -201,7 +201,7 @@ void rsa_reset(struct uart_8250_port *up)
serial_out(up, UART_RSA_FRR, 0);
}
-EXPORT_SYMBOL_GPL_FOR_MODULES(rsa_reset, "8250_base");
+EXPORT_SYMBOL_FOR_MODULES(rsa_reset, "8250_base");
#ifdef CONFIG_SERIAL_8250_DEPRECATED_OPTIONS
#ifndef MODULE
diff --git a/fs/anon_inodes.c b/fs/anon_inodes.c
index 1d847a939f29a41356af3f12e5f61372ec2fb550..180a458fc4f74249d674ec3c6e01277df1d9e743 100644
--- a/fs/anon_inodes.c
+++ b/fs/anon_inodes.c
@@ -129,7 +129,7 @@ struct inode *anon_inode_make_secure_inode(struct super_block *sb, const char *n
}
return inode;
}
-EXPORT_SYMBOL_GPL_FOR_MODULES(anon_inode_make_secure_inode, "kvm");
+EXPORT_SYMBOL_FOR_MODULES(anon_inode_make_secure_inode, "kvm");
static struct file *__anon_inode_getfile(const char *name,
const struct file_operations *fops,
diff --git a/include/linux/export.h b/include/linux/export.h
index f35d03b4113b19798036d2993d67eb932ad8ce6f..a686fd0ba406509da5f397e3a415d05c5a051c0d 100644
--- a/include/linux/export.h
+++ b/include/linux/export.h
@@ -91,6 +91,6 @@
#define EXPORT_SYMBOL_NS(sym, ns) __EXPORT_SYMBOL(sym, "", ns)
#define EXPORT_SYMBOL_NS_GPL(sym, ns) __EXPORT_SYMBOL(sym, "GPL", ns)
-#define EXPORT_SYMBOL_GPL_FOR_MODULES(sym, mods) __EXPORT_SYMBOL(sym, "GPL", "module:" mods)
+#define EXPORT_SYMBOL_FOR_MODULES(sym, mods) __EXPORT_SYMBOL(sym, "GPL", "module:" mods)
#endif /* _LINUX_EXPORT_H */
---
base-commit: 37816488247ddddbc3de113c78c83572274b1e2e
change-id: 20250708-export_modules-12908fa41006
Best regards,
--
Vlastimil Babka <vbabka@suse.cz>
^ permalink raw reply related
* Re: [GIT PULL] Modules changes for v6.17-rc1
From: pr-tracker-bot @ 2025-08-03 22:32 UTC (permalink / raw)
To: Daniel Gomez
Cc: Linus Torvalds, Luis Chamberlain, Petr Pavlu, Sami Tolvanen,
Daniel Gomez, linux-modules, Thomas Weißschuh, David Gow,
Steven Rostedt, linux-kernel
In-Reply-To: <20250803131809.4890-1-da.gomez@kernel.org>
The pull request you sent on Sun, 3 Aug 2025 15:18:07 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/modules/linux.git/ tags/modules-6.17-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8877fcb70fd7ae0a4d5ac73d250dc255f7ff5a2c
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT PULL] Modules changes for v6.17-rc1
From: Linus Torvalds @ 2025-08-03 21:38 UTC (permalink / raw)
To: Daniel Gomez
Cc: Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Daniel Gomez,
linux-modules, Thomas Weißschuh, David Gow, Steven Rostedt,
linux-kernel
In-Reply-To: <20250803131809.4890-1-da.gomez@kernel.org>
On Sun, 3 Aug 2025 at 06:18, Daniel Gomez <da.gomez@kernel.org> wrote:
>
> Note that this had a conflict with sysctl changes [1] but should be fixed now as I
> rebased on top.
Christ people.
Read the documentation and *years* of me sending out emails about what
maintainers should do. Conflicts are *not* a reason to rebase.
See
Documentation/maintainer/rebasing-and-merging.rst
and read it. Read it twice. Then read it again until you really *UNDERSTAND* it.
I deal with conflicts all the time, and that was a particularly
_trivial_ one. I'd *much* rather see a conflict and know that "yeah,
we had people working in the same area this time around" than have it
hidden by a rebase that also invalidates all the testing it got
pre-rebase.
And yes, that "invalidates all the testing" is not just some
theoretical thing. We've literally had situations where tested code
became "oops, now it doesn't work because we rebased it on top of a
tree that had different assumptions".
Is that common? No. But it's just one - of many - reasons not to
rebase, and "it had a conflict" is *NOT* a big enough reason to then
think that rebasing is better.
So "it has a conflict" is real information about the development
process, and shouldn't be hidden.
Yes, there are conflicts that are *so* painful that rebasing things is
worth it. This was not it.
And this rebase was particularly bad. You did *everything* wrong. Not
only was there not a good reason for it, you picked a starting point
that is KNOWN BUGGY AND BOOTS TO A BLACK SCREEN ON MY MACHINE. So now
your new work is basically built on top of something known broken, and
as a result, all *your* commits are known broken too, even if that
breakage isn't due to those commits themselves.
So your rebased state is all built on a base of sand, instead of
something good and stable. And if somebody ends up having to bisect
this because of something it introduces (or even just happens to
bisect into this area for some *unrelated* reason), you picking that
random - and bad - base means that now that bisection is potentially
much more painful than it needed to be.
And yes, this is also talked about in the documentation:
"If you must reparent a repository, do not pick some random kernel commit
as the new base. The kernel is often in a relatively unstable state
between release points; basing development on one of those points
increases the chances of running into surprising bugs. When a patch
series must move to a new base, pick a stable point (such as one of
the -rc releases) to move to"
I've pulled this, because I'm flying out tomorrow, and it otherwise
looks fairly simple and straightforward.
But dammit. DO NOT MINDLESSLY REBASE YOUR TREES!
Linus
^ permalink raw reply
* [GIT PULL] Modules changes for v6.17-rc1
From: Daniel Gomez @ 2025-08-03 13:18 UTC (permalink / raw)
To: Linus Torvalds, Luis Chamberlain, Petr Pavlu, Sami Tolvanen,
Daniel Gomez, linux-modules
Cc: Thomas Weißschuh, David Gow, Steven Rostedt, linux-kernel
The following changes since commit 260f6f4fda93c8485c8037865c941b42b9cba5d2:
Merge tag 'drm-next-2025-07-30' of https://gitlab.freedesktop.org/drm/kernel (2025-07-30 19:26:49 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/modules/linux.git/ tags/modules-6.17-rc1
for you to fetch changes up to 40a826bd6c82ae45cfd3a19cd2a60a10f56b74c0:
module: Rename MAX_PARAM_PREFIX_LEN to __MODULE_NAME_LEN (2025-07-31 13:57:47 +0200)
----------------------------------------------------------------
This is a small set of changes for modules, primarily to extend module users
to use the module data structures in combination with the already no-op stub
module functions, even when support for modules is disabled in the kernel
configuration. This change follows the kernel's coding style for conditional
compilation and allows kunit code to drop all CONFIG_MODULES ifdefs, which is
also part of the changes. This should allow others part of the kernel to do the
same cleanup.
Note that this had a conflict with sysctl changes [1] but should be fixed now as I
rebased on top.
The remaining changes include a fix for module name length handling which could
potentially lead to the removal of an incorrect module, and various cleanups.
The module name fix and related cleanup has been in linux-next since Thursday
(July 31) while the rest of the changes for a bit more than 3 weeks.
Note that this currently has conflicts in next with kbuild's tree [2].
Link: https://lore.kernel.org/all/20250714175916.774e6d79@canb.auug.org.au/ [1]
Link: https://lore.kernel.org/all/20250801132941.6815d93d@canb.auug.org.au/ [2]
----------------------------------------------------------------
Petr Pavlu (5):
module: Prevent silent truncation of module name in delete_module(2)
module: Remove unnecessary +1 from last_unloaded_module::name size
module: Restore the moduleparam prefix length check
tracing: Replace MAX_PARAM_PREFIX_LEN with MODULE_NAME_LEN
module: Rename MAX_PARAM_PREFIX_LEN to __MODULE_NAME_LEN
Thomas Weißschuh (3):
module: move 'struct module_use' to internal.h
module: make structure definitions always visible
kunit: test: Drop CONFIG_MODULE ifdeffery
include/linux/module.h | 29 +++++++++++------------------
include/linux/moduleparam.h | 15 +++++++++------
kernel/module/internal.h | 7 +++++++
kernel/module/main.c | 12 +++++++-----
kernel/trace/trace.c | 2 +-
lib/kunit/test.c | 8 --------
6 files changed, 35 insertions(+), 38 deletions(-)
^ permalink raw reply
* Re: [PATCH 0/5] module: Fix minor problems related to MODULE_NAME_LEN
From: Daniel Gomez @ 2025-07-31 12:03 UTC (permalink / raw)
To: Luis Chamberlain, Sami Tolvanen, Petr Pavlu; +Cc: linux-modules, linux-kernel
In-Reply-To: <20250630143535.267745-1-petr.pavlu@suse.com>
On Mon, 30 Jun 2025 16:32:31 +0200, Petr Pavlu wrote:
> Fix a few minor problems related to MODULE_NAME_LEN and
> MAX_PARAM_PREFIX_LEN, and clean up their usage.
>
> Petr Pavlu (5):
> module: Prevent silent truncation of module name in delete_module(2)
> module: Remove unnecessary +1 from last_unloaded_module::name size
> module: Restore the moduleparam prefix length check
> tracing: Replace MAX_PARAM_PREFIX_LEN with MODULE_NAME_LEN
> module: Rename MAX_PARAM_PREFIX_LEN to __MODULE_NAME_LEN
>
> [...]
Applied, thanks!
[1/5] module: Prevent silent truncation of module name in delete_module(2)
commit: a6323bd4e611567913e23df5b58f2d4e4da06789
[2/5] module: Remove unnecessary +1 from last_unloaded_module::name size
commit: 6c171b2ccfe677ca97fc5334f853807959f26589
[3/5] module: Restore the moduleparam prefix length check
commit: bdc877ba6b7ff1b6d2ebeff11e63da4a50a54854
[4/5] tracing: Replace MAX_PARAM_PREFIX_LEN with MODULE_NAME_LEN
commit: a7c54b2b41dd1f6ec780e7fbfb13f70c64c9731d
[5/5] module: Rename MAX_PARAM_PREFIX_LEN to __MODULE_NAME_LEN
commit: 40a826bd6c82ae45cfd3a19cd2a60a10f56b74c0
Best regards,
--
Daniel Gomez <da.gomez@samsung.com>
^ permalink raw reply
* Re: [PATCH v5 03/10] kbuild: keep .modinfo section in vmlinux.unstripped
From: Masahiro Yamada @ 2025-07-29 13:54 UTC (permalink / raw)
To: Alexander Gordeev
Cc: Alexey Gladkov, Petr Pavlu, Luis Chamberlain, Sami Tolvanen,
Daniel Gomez, Nathan Chancellor, Nicolas Schier, linux-kernel,
linux-modules, linux-kbuild
In-Reply-To: <20250728135753.432695A72-agordeev@linux.ibm.com>
On Mon, Jul 28, 2025 at 10:58 PM Alexander Gordeev
<agordeev@linux.ibm.com> wrote:
>
> On Thu, Jul 24, 2025 at 03:49:40PM +0200, Alexey Gladkov wrote:
>
> Hi Alexey, Masahiro,
>
> > From: Masahiro Yamada <masahiroy@kernel.org>
> >
> > Keep the .modinfo section during linking, but strip it from the final
> > vmlinux.
> >
> > Adjust scripts/mksysmap to exclude modinfo symbols from kallsyms.
> >
> > This change will allow the next commit to extract the .modinfo section
> > from the vmlinux.unstripped intermediate.
> >
> > Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> > ---
> > include/asm-generic/vmlinux.lds.h | 2 +-
> > scripts/Makefile.vmlinux | 2 +-
> > scripts/mksysmap | 3 +++
> > 3 files changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> > index fa5f19b8d53a..1791665006f9 100644
> > --- a/include/asm-generic/vmlinux.lds.h
> > +++ b/include/asm-generic/vmlinux.lds.h
> > @@ -831,6 +831,7 @@ defined(CONFIG_AUTOFDO_CLANG) || defined(CONFIG_PROPELLER_CLANG)
> >
> > /* Required sections not related to debugging. */
> > #define ELF_DETAILS \
> > + .modinfo : { *(.modinfo) } \
>
> FWIW, to me .modinfo logically does not quite belong to ELF_DETAILS,
> since it is not about ELF.
>
> I would guess, that you want to make a minimal code impact to the
> linker scripts, but with that you turn .modinfo the only section
> among ones that do not make it to the final image:
>
> STABS_DEBUG
> DWARF_DEBUG
> ELF_DETAILS
>
> That immediately breaks s390, but also is a call for trouble in
> the future, as far as I am concerned.
>
> Would it makes sense to introduce e.g MODINFO instead?
I am open to MODINFO addition, if Alexey is happy about
modifying linker scripts for all arches.
Yeah, it is tedious, though...
>
> > .comment 0 : { *(.comment) } \
> > .symtab 0 : { *(.symtab) } \
> > .strtab 0 : { *(.strtab) } \
> > @@ -1044,7 +1045,6 @@ defined(CONFIG_AUTOFDO_CLANG) || defined(CONFIG_PROPELLER_CLANG)
> > *(.discard.*) \
> > *(.export_symbol) \
> > *(.no_trim_symbol) \
> > - *(.modinfo) \
> > /* ld.bfd warns about .gnu.version* even when not emitted */ \
> > *(.gnu.version*) \
>
> Thanks!
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH v5 10/10] s390: vmlinux.lds.S: Reorder sections
From: Masahiro Yamada @ 2025-07-29 12:46 UTC (permalink / raw)
To: Alexey Gladkov
Cc: Heiko Carstens, Petr Pavlu, Luis Chamberlain, Sami Tolvanen,
Daniel Gomez, Nathan Chancellor, Nicolas Schier, linux-kernel,
linux-modules, linux-kbuild, Vasily Gorbik, Alexander Gordeev,
linux-s390, kernel test robot
In-Reply-To: <aIeUq0qYXoNIePwd@example.org>
On Tue, Jul 29, 2025 at 12:18 AM Alexey Gladkov <legion@kernel.org> wrote:
>
> On Mon, Jul 28, 2025 at 04:01:09PM +0200, Heiko Carstens wrote:
> > On Sat, Jul 26, 2025 at 07:59:16PM +0900, Masahiro Yamada wrote:
> > > On Thu, Jul 24, 2025 at 10:50 PM Alexey Gladkov <legion@kernel.org> wrote:
> > > >
> > > > Reorder the sections to be placed in the default segment. The
> > > > .vmlinux.info use :NONE to override the default segment and tell the
> > > > linker to not put the section in any segment at all.
> > > >
> > > > >> s390x-linux-ld: .tmp_vmlinux1: warning: allocated section `.modinfo' not in segment
> > > > >> s390x-linux-ld: .tmp_vmlinux2: warning: allocated section `.modinfo' not in segment
> > > > >> s390x-linux-ld: vmlinux.unstripped: warning: allocated section `.modinfo' not in segment
> > >
> > > Thank you for root-causing!
I applied this series with patch re-ordering.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH v5 10/10] s390: vmlinux.lds.S: Reorder sections
From: Alexey Gladkov @ 2025-07-28 15:18 UTC (permalink / raw)
To: Heiko Carstens
Cc: Masahiro Yamada, Petr Pavlu, Luis Chamberlain, Sami Tolvanen,
Daniel Gomez, Nathan Chancellor, Nicolas Schier, linux-kernel,
linux-modules, linux-kbuild, Vasily Gorbik, Alexander Gordeev,
linux-s390, kernel test robot
In-Reply-To: <20250728140109.7289Ae1-hca@linux.ibm.com>
On Mon, Jul 28, 2025 at 04:01:09PM +0200, Heiko Carstens wrote:
> On Sat, Jul 26, 2025 at 07:59:16PM +0900, Masahiro Yamada wrote:
> > On Thu, Jul 24, 2025 at 10:50 PM Alexey Gladkov <legion@kernel.org> wrote:
> > >
> > > Reorder the sections to be placed in the default segment. The
> > > .vmlinux.info use :NONE to override the default segment and tell the
> > > linker to not put the section in any segment at all.
> > >
> > > >> s390x-linux-ld: .tmp_vmlinux1: warning: allocated section `.modinfo' not in segment
> > > >> s390x-linux-ld: .tmp_vmlinux2: warning: allocated section `.modinfo' not in segment
> > > >> s390x-linux-ld: vmlinux.unstripped: warning: allocated section `.modinfo' not in segment
> >
> > Thank you for root-causing!
> >
> > > Cc: Heiko Carstens <hca@linux.ibm.com>
> > > Cc: Vasily Gorbik <gor@linux.ibm.com>
> > > Cc: Alexander Gordeev <agordeev@linux.ibm.com>
> > > Cc: linux-s390@vger.kernel.org
> >
> > Hi s390 maintainers,
> > I need this patch for kbuild tree.
> > Ack is appreciated.
>
> Acked-by: Heiko Carstens <hca@linux.ibm.com>
>
> But can you reorder the series so this patch comes before any of the
> patches which introduces the above warnings, please?
Sure. I will put it first to avoid warnings.
--
Rgrds, legion
^ permalink raw reply
* Re: [PATCH v5 03/10] kbuild: keep .modinfo section in vmlinux.unstripped
From: Alexey Gladkov @ 2025-07-28 15:15 UTC (permalink / raw)
To: Alexander Gordeev
Cc: Masahiro Yamada, Petr Pavlu, Luis Chamberlain, Sami Tolvanen,
Daniel Gomez, Nathan Chancellor, Nicolas Schier, linux-kernel,
linux-modules, linux-kbuild
In-Reply-To: <20250728135753.432695A72-agordeev@linux.ibm.com>
On Mon, Jul 28, 2025 at 03:57:53PM +0200, Alexander Gordeev wrote:
> On Thu, Jul 24, 2025 at 03:49:40PM +0200, Alexey Gladkov wrote:
>
> Hi Alexey, Masahiro,
>
> > From: Masahiro Yamada <masahiroy@kernel.org>
> >
> > Keep the .modinfo section during linking, but strip it from the final
> > vmlinux.
> >
> > Adjust scripts/mksysmap to exclude modinfo symbols from kallsyms.
> >
> > This change will allow the next commit to extract the .modinfo section
> > from the vmlinux.unstripped intermediate.
> >
> > Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> > ---
> > include/asm-generic/vmlinux.lds.h | 2 +-
> > scripts/Makefile.vmlinux | 2 +-
> > scripts/mksysmap | 3 +++
> > 3 files changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> > index fa5f19b8d53a..1791665006f9 100644
> > --- a/include/asm-generic/vmlinux.lds.h
> > +++ b/include/asm-generic/vmlinux.lds.h
> > @@ -831,6 +831,7 @@ defined(CONFIG_AUTOFDO_CLANG) || defined(CONFIG_PROPELLER_CLANG)
> >
> > /* Required sections not related to debugging. */
> > #define ELF_DETAILS \
> > + .modinfo : { *(.modinfo) } \
>
> FWIW, to me .modinfo logically does not quite belong to ELF_DETAILS,
> since it is not about ELF.
The macro name ELF_DETAILS is rather unfortunate. The description says
that these sections are not related to debugging.
> I would guess, that you want to make a minimal code impact to the
> linker scripts, but with that you turn .modinfo the only section
> among ones that do not make it to the final image:
>
> STABS_DEBUG
> DWARF_DEBUG
> ELF_DETAILS
>
> That immediately breaks s390, but also is a call for trouble in
> the future, as far as I am concerned.
>
> Would it makes sense to introduce e.g MODINFO instead?
This will require patching all architectures to add MODINFO. This will
have a significant code impact. To avoid this, .modinfo was added to
ELF_DETAILS.
> > .comment 0 : { *(.comment) } \
> > .symtab 0 : { *(.symtab) } \
> > .strtab 0 : { *(.strtab) } \
> > @@ -1044,7 +1045,6 @@ defined(CONFIG_AUTOFDO_CLANG) || defined(CONFIG_PROPELLER_CLANG)
> > *(.discard.*) \
> > *(.export_symbol) \
> > *(.no_trim_symbol) \
> > - *(.modinfo) \
> > /* ld.bfd warns about .gnu.version* even when not emitted */ \
> > *(.gnu.version*) \
>
> Thanks!
>
--
Rgrds, legion
^ permalink raw reply
* Re: [PATCH 4/5] tracing: Replace MAX_PARAM_PREFIX_LEN with MODULE_NAME_LEN
From: Steven Rostedt @ 2025-07-28 14:34 UTC (permalink / raw)
To: Daniel Gomez
Cc: Petr Pavlu, Luis Chamberlain, Sami Tolvanen, Daniel Gomez,
Masami Hiramatsu, linux-modules, linux-kernel
In-Reply-To: <e9caf91d-3a4b-4140-a3bc-0c2b53c0a220@kernel.org>
On Mon, 28 Jul 2025 08:48:01 +0200
Daniel Gomez <da.gomez@kernel.org> wrote:
> On 30/06/2025 16.32, Petr Pavlu wrote:
> > Use the MODULE_NAME_LEN definition in module_exists() to obtain the maximum
> > size of a module name, instead of using MAX_PARAM_PREFIX_LEN. The values
> > are the same but MODULE_NAME_LEN is more appropriate in this context.
> > MAX_PARAM_PREFIX_LEN was added in commit 730b69d22525 ("module: check
> > kernel param length at compile time, not runtime") only to break a circular
> > dependency between module.h and moduleparam.h, and should mostly be limited
> > to use in moduleparam.h.
> >
> > Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
> > Cc: Steven Rostedt <rostedt@goodmis.org>
> > Cc: Masami Hiramatsu <mhiramat@kernel.org>
>
> Steven, Masami,
>
> I'm planning to merge these series into modules-next. I think and Ack/Review
> would be great from you. Otherwise, let me know if you'd rather take this patch
> through tracing instead (in case it looks good from your side).
Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org>
>
> > ---
> >
> > As a side note, I suspect the function module_exists() would be better
> > replaced with !!find_module() + RCU locking, but that is a separate issue.
Yeah, that is probably something that should be done too.
Thanks,
-- Steve
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox