[PATCH v3 0/3] Filter out local and mapping symbols during module load

[PATCH v3 0/3] Filter out local and mapping symbols during module load

[Tiezhu Yang]

This series prevents compiler generated local and mapping symbols
from leaking into /proc/kallsyms for loaded modules. This ensures
tracing tools like bpftrace can resolve accurate kernel stacks on
architectures like LoongArch.

Based on the v2 discussion, the changes are now refactored into a
clean three-patch series to eliminate code duplication and clarify
naming.

Tiezhu Yang (3):
  module/kallsyms: Rename is_mapping_symbol() to
    is_local_mapping_symbol()
  module/kallsyms: Refactor current symbol filtering into
    is_kept_symbol()
  module/kallsyms: Filter out local and mapping symbols during module
    load

 include/linux/module_symbol.h |  4 +--
 kernel/module/kallsyms.c      | 59 ++++++++++++++++++-----------------
 scripts/faddr2line            |  2 +-
 scripts/mod/modpost.h         |  2 +-
 4 files changed, 35 insertions(+), 32 deletions(-)

-- 
2.42.0

[PATCH v3 1/3] module/kallsyms: Rename is_mapping_symbol() to is_local_mapping_symbol()

[Tiezhu Yang]

The helper function is_mapping_symbol() historically checks for both
local labels prefixed with ".L" or "L0" and mapping symbols prefixed
with "$".

Rename it to is_local_mapping_symbol() to better reflect this actual
behavior and scope, preventing conceptual confusion.

No functional change.

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
---
 include/linux/module_symbol.h | 4 ++--
 kernel/module/kallsyms.c      | 2 +-
 scripts/faddr2line            | 2 +-
 scripts/mod/modpost.h         | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/linux/module_symbol.h b/include/linux/module_symbol.h
index 574609aced99..ca76ed5cb489 100644
--- a/include/linux/module_symbol.h
+++ b/include/linux/module_symbol.h
@@ -7,8 +7,8 @@ enum ksym_flags {
 	KSYM_FLAG_GPL_ONLY	= 1 << 0,
 };
 
-/* This ignores the intensely annoying "mapping symbols" found in ELF files. */
-static inline bool is_mapping_symbol(const char *str)
+/* This ignores the intensely annoying "local or mapping symbols" found in ELF files. */
+static inline bool is_local_mapping_symbol(const char *str)
 {
 	if (str[0] == '.' && str[1] == 'L')
 		return true;
diff --git a/kernel/module/kallsyms.c b/kernel/module/kallsyms.c
index f23126d804b2..a595f8cd29b2 100644
--- a/kernel/module/kallsyms.c
+++ b/kernel/module/kallsyms.c
@@ -294,7 +294,7 @@ static const char *find_kallsyms_symbol(struct module *mod,
 		 * and inserted at a whim.
 		 */
 		if (*kallsyms_symbol_name(kallsyms, i) == '\0' ||
-		    is_mapping_symbol(kallsyms_symbol_name(kallsyms, i)))
+		    is_local_mapping_symbol(kallsyms_symbol_name(kallsyms, i)))
 			continue;
 
 		if (thisval <= addr && thisval > bestval) {
diff --git a/scripts/faddr2line b/scripts/faddr2line
index 622875396bcf..bda4ea20e39e 100755
--- a/scripts/faddr2line
+++ b/scripts/faddr2line
@@ -243,7 +243,7 @@ __faddr2line() {
 			local cur_sym_elf_size=${fields[2]}
 			local cur_sym_name=${fields[7]:-}
 
-			# is_mapping_symbol(cur_sym_name)
+			# is_local_mapping_symbol(cur_sym_name)
 			if [[ ${cur_sym_name} =~ ^(\.L|L0|\$) ]]; then
 				continue
 			fi
diff --git a/scripts/mod/modpost.h b/scripts/mod/modpost.h
index 2aecb8f25c87..4173fff2788a 100644
--- a/scripts/mod/modpost.h
+++ b/scripts/mod/modpost.h
@@ -198,7 +198,7 @@ static inline bool is_valid_name(struct elf_info *elf, Elf_Sym *sym)
 
 	if (!name || !strlen(name))
 		return false;
-	return !is_mapping_symbol(name);
+	return !is_local_mapping_symbol(name);
 }
 
 /* symsearch.c */
-- 
2.42.0

[PATCH v3 2/3] module/kallsyms: Refactor current symbol filtering into is_kept_symbol()

[Tiezhu Yang]

Currently, the loops in layout_symtab() and add_kallsyms() duplicate the
exact same checks (i == 0 || is_livepatch_module() || is_core_symbol())
to determine whether a symbol should be preserved in the module's core
symbol table.

Rename is_core_symbol() to is_kept_symbol() and move the entire checking
logic inside it, including the special handlers for the first symbol and
livepatch modules.

No functional change.

Suggested-by: Petr Pavlu <petr.pavlu@suse.com>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
---
 kernel/module/kallsyms.c | 54 ++++++++++++++++++++--------------------
 1 file changed, 27 insertions(+), 27 deletions(-)

diff --git a/kernel/module/kallsyms.c b/kernel/module/kallsyms.c
index a595f8cd29b2..ff8d904afe56 100644
--- a/kernel/module/kallsyms.c
+++ b/kernel/module/kallsyms.c
@@ -75,23 +75,26 @@ static char elf_type(const Elf_Sym *sym, const struct load_info *info)
 	return '?';
 }
 
-static bool is_core_symbol(const Elf_Sym *src, const Elf_Shdr *sechdrs,
-			   unsigned int shnum, unsigned int pcpundx)
+static bool is_kept_symbol(struct module *mod, const struct load_info *info,
+			   unsigned int symnum, const Elf_Sym *src)
 {
 	const Elf_Shdr *sec;
 	enum mod_mem_type type;
 
+	if (symnum == 0 || is_livepatch_module(mod))
+		return true;
+
 	if (src->st_shndx == SHN_UNDEF ||
-	    src->st_shndx >= shnum ||
+	    src->st_shndx >= info->hdr->e_shnum ||
 	    !src->st_name)
 		return false;
 
 #ifdef CONFIG_KALLSYMS_ALL
-	if (src->st_shndx == pcpundx)
+	if (src->st_shndx == info->index.pcpu)
 		return true;
 #endif
 
-	sec = sechdrs + src->st_shndx;
+	sec = info->sechdrs + src->st_shndx;
 	type = sec->sh_entsize >> SH_ENTSIZE_TYPE_SHIFT;
 	if (!(sec->sh_flags & SHF_ALLOC)
 #ifndef CONFIG_KALLSYMS_ALL
@@ -130,12 +133,11 @@ void layout_symtab(struct module *mod, struct load_info *info)
 
 	/* Compute total space required for the core symbols' strtab. */
 	for (ndst = i = 0; i < nsrc; i++) {
-		if (i == 0 || is_livepatch_module(mod) ||
-		    is_core_symbol(src + i, info->sechdrs, info->hdr->e_shnum,
-				   info->index.pcpu)) {
-			strtab_size += strlen(&info->strtab[src[i].st_name]) + 1;
-			ndst++;
-		}
+		if (!is_kept_symbol(mod, info, i, src + i))
+			continue;
+
+		strtab_size += strlen(&info->strtab[src[i].st_name]) + 1;
+		ndst++;
 	}
 
 	/* Append room for core symbols at end of core part. */
@@ -197,23 +199,21 @@ void add_kallsyms(struct module *mod, const struct load_info *info)
 	strtab_size = info->core_typeoffs - info->stroffs;
 	src = kallsyms->symtab;
 	for (ndst = i = 0; i < kallsyms->num_symtab; i++) {
+		ssize_t ret;
+
 		kallsyms->typetab[i] = elf_type(src + i, info);
-		if (i == 0 || is_livepatch_module(mod) ||
-		    is_core_symbol(src + i, info->sechdrs, info->hdr->e_shnum,
-				   info->index.pcpu)) {
-			ssize_t ret;
-
-			mod->core_kallsyms.typetab[ndst] =
-				kallsyms->typetab[i];
-			dst[ndst] = src[i];
-			dst[ndst++].st_name = s - mod->core_kallsyms.strtab;
-			ret = strscpy(s, &kallsyms->strtab[src[i].st_name],
-				      strtab_size);
-			if (ret < 0)
-				break;
-			s += ret + 1;
-			strtab_size -= ret + 1;
-		}
+
+		if (!is_kept_symbol(mod, info, i, src + i))
+			continue;
+
+		mod->core_kallsyms.typetab[ndst] = kallsyms->typetab[i];
+		dst[ndst] = src[i];
+		dst[ndst++].st_name = s - mod->core_kallsyms.strtab;
+		ret = strscpy(s, &kallsyms->strtab[src[i].st_name], strtab_size);
+		if (ret < 0)
+			break;
+		s += ret + 1;
+		strtab_size -= ret + 1;
 	}
 
 	/* Set up to point into init section. */
-- 
2.42.0

[PATCH v3 3/3] module/kallsyms: Filter out local and mapping symbols during module load

[Tiezhu Yang]

The compiler toolchains generate local and mapping symbols on certain
architectures like LoongArch for optimizations and relocations.

While the symbols are already filtered out during runtime lookups via
find_kallsyms_symbol(), they still leak into /proc/kallsyms for loaded
modules because layout_symtab() and add_kallsyms() do not filter them
during load time.

Consequently, tracing tools like bpftrace (which do not perform internal
filtering, unlike perf) resolve identical addresses into confusing local
labels instead of actual clear C function names.

Fix this by integrating the is_local_mapping_symbol() check directly into
the newly introduced is_kept_symbol() helper. This ensures these unneeded
symbols are stripped during module load time, keeping /proc/kallsyms clean
and resulting in accurate call stacks.

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
---
 kernel/module/kallsyms.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/module/kallsyms.c b/kernel/module/kallsyms.c
index ff8d904afe56..cc2a68956e43 100644
--- a/kernel/module/kallsyms.c
+++ b/kernel/module/kallsyms.c
@@ -89,6 +89,9 @@ static bool is_kept_symbol(struct module *mod, const struct load_info *info,
 	    !src->st_name)
 		return false;
 
+	if (is_local_mapping_symbol(&info->strtab[src->st_name]))
+		return false;
+
 #ifdef CONFIG_KALLSYMS_ALL
 	if (src->st_shndx == info->index.pcpu)
 		return true;
-- 
2.42.0

Re: [PATCH v3 2/3] module/kallsyms: Refactor current symbol filtering into is_kept_symbol()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] An attacker can use ELF relocations targeting the `.symtab` section to bypass early validation checks. This leads to heap buffer overflows, out-of-bounds reads, and information leaks during module loading.
--

--- Patch [2]: [PATCH v3 2/3] module/kallsyms: Refactor current symbol filtering into is_kept_symbol() ---
commit a466dcd66d6b608624bbdcca606a5281e2967615
Author: Tiezhu Yang <yangtiezhu@loongson.cn>

module/kallsyms: Refactor current symbol filtering into is_kept_symbol()

Currently, the loops in layout_symtab() and add_kallsyms() duplicate the
exact same checks to determine whether a symbol should be preserved in
the module's core symbol table. This commit renames is_core_symbol() to
is_kept_symbol() and consolidates the checking logic.

> diff --git a/kernel/module/kallsyms.c b/kernel/module/kallsyms.c
> index 8955cd42f20bc..efc73f66defd5 100644
> --- a/kernel/module/kallsyms.c
> +++ b/kernel/module/kallsyms.c

[ ... ]

> @@ -197,23 +199,21 @@ void add_kallsyms(struct module *mod, const struct load_info *info)
>  	strtab_size = info->core_typeoffs - info->stroffs;
>  	src = kallsyms->symtab;
>  	for (ndst = i = 0; i < kallsyms->num_symtab; i++) {
> +		ssize_t ret;
> +
>  		kallsyms->typetab[i] = elf_type(src + i, info);
> -		if (i == 0 || is_livepatch_module(mod) ||
> -		    is_core_symbol(src + i, info->sechdrs, info->hdr->e_shnum,
> -				   info->index.pcpu)) {
> -			ssize_t ret;
> -
> -			mod->core_kallsyms.typetab[ndst] =
> -				kallsyms->typetab[i];
> -			dst[ndst] = src[i];
> -			dst[ndst++].st_name = s - mod->core_kallsyms.strtab;
> -			ret = strscpy(s, &kallsyms->strtab[src[i].st_name],
> -				      strtab_size);
> -			if (ret < 0)
> -				break;
> -			s += ret + 1;
> -			strtab_size -= ret + 1;
> -		}
> +
> +		if (!is_kept_symbol(mod, info, i, src + i))
> +			continue;
> +
> +		mod->core_kallsyms.typetab[ndst] = kallsyms->typetab[i];
> +		dst[ndst] = src[i];
> +		dst[ndst++].st_name = s - mod->core_kallsyms.strtab;
> +		ret = strscpy(s, &kallsyms->strtab[src[i].st_name], strtab_size);

[Severity: High]
This isn't a bug introduced by this patch, but could an attacker use ELF
relocations targeting the .symtab section to bypass early validation checks
and trigger a heap buffer overflow or out-of-bounds read here?

During module loading, layout_symtab() adds the SHF_ALLOC flag to the
.symtab section and computes memory requirements based on the unmodified
symbols:

kernel/module/kallsyms.c:layout_symtab() {
    ...
    symsect->sh_flags |= SHF_ALLOC;
    ...
}

Later, apply_relocations() processes relocation sections. Because .symtab
now has the SHF_ALLOC flag, relocations targeting .symtab are applied,
modifying the symbol table in memory after bounds checks have completed:

kernel/module/main.c:apply_relocations() {
    ...
    if (!(info->sechdrs[infosec].sh_flags & SHF_ALLOC) &&
        (!infosec || infosec != info->index.pcpu))
        continue;
    ...
}

Finally, add_kallsyms() reads this modified symbol table without
re-validating it. If an attacker modifies st_name via relocations, it
bypasses the earlier elf_validity_cache_strtab() bounds check, causing
strscpy() to read out-of-bounds memory. Modifying st_shndx bypasses the
ndst calculation, causing out-of-bounds writes on mod->core_kallsyms.symtab
and typetab arrays.

> +		if (ret < 0)
> +			break;
> +		s += ret + 1;
> +		strtab_size -= ret + 1;
>  	}
>  
>  	/* Set up to point into init section. */

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260812032807.15034-1-yangtiezhu@loongson.cn?part=2

Re: [PATCH v3 3/3] module/kallsyms: Filter out local and mapping symbols during module load

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Relocations can modify `.symtab` and `.strtab` between `layout_symtab()` and `add_kallsyms()`, leading to a heap buffer overflow, out-of-bounds read, and security control bypass.
--

--- Patch [3]: [PATCH v3 3/3] module/kallsyms: Filter out local and mapping symbols during module load ---
commit b99e0a63da9d8d5ffb4bf7cbd78e368abde75865
Author: Tiezhu Yang <yangtiezhu@loongson.cn>

module/kallsyms: Filter out local and mapping symbols during module load

The compiler toolchains generate local and mapping symbols on certain
architectures like LoongArch for optimizations and relocations. This
commit filters them out during module load time using the newly
introduced is_kept_symbol() helper to keep /proc/kallsyms clean.

> diff --git a/kernel/module/kallsyms.c b/kernel/module/kallsyms.c
> index efc73f66defd5..77e05b5ca1f2c 100644
> --- a/kernel/module/kallsyms.c
> +++ b/kernel/module/kallsyms.c
> @@ -89,6 +89,9 @@ static bool is_kept_symbol(struct module *mod, const struct load_info *info,
>  	    !src->st_name)
>  		return false;
>  
> +	if (is_local_mapping_symbol(&info->strtab[src->st_name]))
> +		return false;
> +

[Severity: High]
This is a pre-existing issue, but does this new check introduce an
out-of-bounds read if a malformed module modifies st_name?

In layout_symtab(), .symtab and .strtab are marked with SHF_ALLOC:

kernel/module/kallsyms.c:layout_symtab() {
    ...
    symsect->sh_flags |= SHF_ALLOC;
    strsect->sh_flags |= SHF_ALLOC;
    ...
}

Later, apply_relocations() applies relocations to sections with
SHF_ALLOC, which can mutate the symbol and string tables in module memory:

kernel/module/main.c:apply_relocations() {
    ...
    if (!(info->sechdrs[infosec].sh_flags & SHF_ALLOC) &&
        (!infosec || infosec != info->index.pcpu))
        continue;
    ...
}

When add_kallsyms() re-evaluates the mutated symbol table, it calls
is_kept_symbol(), which uses the mutated src->st_name without bounds
checking against the unmodified info->strtab.

Could this read out of bounds if st_name is maliciously inflated?

Also, since a previously rejected symbol might now be kept after mutation,
could this overflow the mod->core_kallsyms.symtab array since the number
of kept symbols might now exceed the pre-calculated allocation?

>  #ifdef CONFIG_KALLSYMS_ALL
>  	if (src->st_shndx == info->index.pcpu)
>  		return true;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260812032807.15034-1-yangtiezhu@loongson.cn?part=3

Re: [PATCH v3 3/3] module/kallsyms: Filter out local and mapping symbols during module load

[Tiezhu Yang]

On 2026/8/12 上午11:44, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
...

> [Severity: High]
> This is a pre-existing issue

Thanks for the reports of patch 2 and patch 3.

As noted in the descriptions, these are pre-existing issues,
they are completely independent of this series.

IMO, a dedicated security patch series should handle this
historical vulnerability in the future.

Thanks,
Tiezhu

Re: [PATCH v3 0/3] Filter out local and mapping symbols during module load

[Huacai Chen]

Reviewed-by: Huacai Chen <chenhuacai@loongson.cn>

But I still don't think renaming is_core_symbol() to is_kept_symbol()
is necessary.

Huacai

On Wed, Aug 12, 2026 at 11:28 AM Tiezhu Yang <yangtiezhu@loongson.cn> wrote:
>
> This series prevents compiler generated local and mapping symbols
> from leaking into /proc/kallsyms for loaded modules. This ensures
> tracing tools like bpftrace can resolve accurate kernel stacks on
> architectures like LoongArch.
>
> Based on the v2 discussion, the changes are now refactored into a
> clean three-patch series to eliminate code duplication and clarify
> naming.
>
> Tiezhu Yang (3):
>   module/kallsyms: Rename is_mapping_symbol() to
>     is_local_mapping_symbol()
>   module/kallsyms: Refactor current symbol filtering into
>     is_kept_symbol()
>   module/kallsyms: Filter out local and mapping symbols during module
>     load
>
>  include/linux/module_symbol.h |  4 +--
>  kernel/module/kallsyms.c      | 59 ++++++++++++++++++-----------------
>  scripts/faddr2line            |  2 +-
>  scripts/mod/modpost.h         |  2 +-
>  4 files changed, 35 insertions(+), 32 deletions(-)
>
> --
> 2.42.0
>
>

Re: [PATCH v3 0/3] Filter out local and mapping symbols during module load

[Huacai Chen]

On Wed, Aug 12, 2026 at 11:17 PM Huacai Chen <chenhuacai@kernel.org> wrote:
>
> Reviewed-by: Huacai Chen <chenhuacai@loongson.cn>
>
> But I still don't think renaming is_core_symbol() to is_kept_symbol()
> is necessary.
And this series needs to backport to stable branches, no renaming can
reduce the difficulty.

Huacai

>
> Huacai
>
> On Wed, Aug 12, 2026 at 11:28 AM Tiezhu Yang <yangtiezhu@loongson.cn> wrote:
> >
> > This series prevents compiler generated local and mapping symbols
> > from leaking into /proc/kallsyms for loaded modules. This ensures
> > tracing tools like bpftrace can resolve accurate kernel stacks on
> > architectures like LoongArch.
> >
> > Based on the v2 discussion, the changes are now refactored into a
> > clean three-patch series to eliminate code duplication and clarify
> > naming.
> >
> > Tiezhu Yang (3):
> >   module/kallsyms: Rename is_mapping_symbol() to
> >     is_local_mapping_symbol()
> >   module/kallsyms: Refactor current symbol filtering into
> >     is_kept_symbol()
> >   module/kallsyms: Filter out local and mapping symbols during module
> >     load
> >
> >  include/linux/module_symbol.h |  4 +--
> >  kernel/module/kallsyms.c      | 59 ++++++++++++++++++-----------------
> >  scripts/faddr2line            |  2 +-
> >  scripts/mod/modpost.h         |  2 +-
> >  4 files changed, 35 insertions(+), 32 deletions(-)
> >
> > --
> > 2.42.0
> >
> >

Re: [PATCH v3 1/3] module/kallsyms: Rename is_mapping_symbol() to is_local_mapping_symbol()

[Petr Pavlu]

On 8/12/26 5:28 AM, Tiezhu Yang wrote:
> The helper function is_mapping_symbol() historically checks for both
> local labels prefixed with ".L" or "L0" and mapping symbols prefixed
> with "$".
> 
> Rename it to is_local_mapping_symbol() to better reflect this actual
> behavior and scope, preventing conceptual confusion.
> 
> No functional change.
> 
> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
> ---
>  include/linux/module_symbol.h | 4 ++--
>  kernel/module/kallsyms.c      | 2 +-
>  scripts/faddr2line            | 2 +-
>  scripts/mod/modpost.h         | 2 +-
>  4 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/include/linux/module_symbol.h b/include/linux/module_symbol.h
> index 574609aced99..ca76ed5cb489 100644
> --- a/include/linux/module_symbol.h
> +++ b/include/linux/module_symbol.h
> @@ -7,8 +7,8 @@ enum ksym_flags {
>  	KSYM_FLAG_GPL_ONLY	= 1 << 0,
>  };
>  
> -/* This ignores the intensely annoying "mapping symbols" found in ELF files. */
> -static inline bool is_mapping_symbol(const char *str)
> +/* This ignores the intensely annoying "local or mapping symbols" found in ELF files. */
> +static inline bool is_local_mapping_symbol(const char *str)

I think the updated comment and the function name are confusing. They
read as if they are about local symbols in general (STB_LOCAL), but they
should refer only to local label symbols (.L<xyz>, ...). The function
would need to be called is_local_label_or_mapping_symbol() but that is
too long.

If you do want to rename this function, one option is to be consistent
with perf, which implements the same filter and calls it
is_ignored_kernel_symbol().

The comment could also be clearer, for example:

/*
 * Ignore local labels (.L*, L0*) and mapping symbols ($*). These symbols are
 * not useful for the kernel, for example, they should not appear in kallsyms.
 */

>  {
>  	if (str[0] == '.' && str[1] == 'L')
>  		return true;
> diff --git a/kernel/module/kallsyms.c b/kernel/module/kallsyms.c
> index f23126d804b2..a595f8cd29b2 100644
> --- a/kernel/module/kallsyms.c
> +++ b/kernel/module/kallsyms.c
> @@ -294,7 +294,7 @@ static const char *find_kallsyms_symbol(struct module *mod,
>  		 * and inserted at a whim.
>  		 */
>  		if (*kallsyms_symbol_name(kallsyms, i) == '\0' ||
> -		    is_mapping_symbol(kallsyms_symbol_name(kallsyms, i)))
> +		    is_local_mapping_symbol(kallsyms_symbol_name(kallsyms, i)))
>  			continue;
>  
>  		if (thisval <= addr && thisval > bestval) {
> diff --git a/scripts/faddr2line b/scripts/faddr2line
> index 622875396bcf..bda4ea20e39e 100755
> --- a/scripts/faddr2line
> +++ b/scripts/faddr2line
> @@ -243,7 +243,7 @@ __faddr2line() {
>  			local cur_sym_elf_size=${fields[2]}
>  			local cur_sym_name=${fields[7]:-}
>  
> -			# is_mapping_symbol(cur_sym_name)
> +			# is_local_mapping_symbol(cur_sym_name)
>  			if [[ ${cur_sym_name} =~ ^(\.L|L0|\$) ]]; then
>  				continue
>  			fi
> diff --git a/scripts/mod/modpost.h b/scripts/mod/modpost.h
> index 2aecb8f25c87..4173fff2788a 100644
> --- a/scripts/mod/modpost.h
> +++ b/scripts/mod/modpost.h
> @@ -198,7 +198,7 @@ static inline bool is_valid_name(struct elf_info *elf, Elf_Sym *sym)
>  
>  	if (!name || !strlen(name))
>  		return false;
> -	return !is_mapping_symbol(name);
> +	return !is_local_mapping_symbol(name);
>  }
>  
>  /* symsearch.c */

Another comment-only reference to is_mapping_symbol() that should be
updated is in tools/perf/util/symbol.h.

-- 
Thanks,
Petr

Re: [PATCH v3 2/3] module/kallsyms: Refactor current symbol filtering into is_kept_symbol()

[Petr Pavlu]

On 8/12/26 5:28 AM, Tiezhu Yang wrote:
> Currently, the loops in layout_symtab() and add_kallsyms() duplicate the
> exact same checks (i == 0 || is_livepatch_module() || is_core_symbol())
> to determine whether a symbol should be preserved in the module's core
> symbol table.
> 
> Rename is_core_symbol() to is_kept_symbol() and move the entire checking
> logic inside it, including the special handlers for the first symbol and
> livepatch modules.
> 
> No functional change.
> 
> Suggested-by: Petr Pavlu <petr.pavlu@suse.com>
> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

Looks ok to me. I'm also fine also keeping the current name,
is_core_symbol(), as Huacai mentions in his review [1]. I previously
suggested is_kept_symbol() [2], since the is_livepatch_module() check
is moved into this function. However, is_core_symbol() is still ok, as
it is consistent with where the symbols are assigned, in
module::core_kallsyms.

The important part is to avoid duplicating the checks that determine
whether a symbol should be kept in layout_symtab() and add_kallsyms().

Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>

[1] https://lore.kernel.org/linux-modules/CAAhV-H5w8VVW_L6cRes-syjEvhbWmevSKWrZWPFapRkuemmjaw@mail.gmail.com/
[2] https://lore.kernel.org/linux-modules/39a48465-22b6-4b18-9f7e-ce258513181b@suse.com/

-- 
Thanks,
Petr

Re: [PATCH v3 3/3] module/kallsyms: Filter out local and mapping symbols during module load

[Petr Pavlu]

On 8/12/26 5:28 AM, Tiezhu Yang wrote:
> The compiler toolchains generate local and mapping symbols on certain
> architectures like LoongArch for optimizations and relocations.

Nit: "local" -> "local label".

> 
> While the symbols are already filtered out during runtime lookups via
> find_kallsyms_symbol(), they still leak into /proc/kallsyms for loaded
> modules because layout_symtab() and add_kallsyms() do not filter them
> during load time.
> 
> Consequently, tracing tools like bpftrace (which do not perform internal
> filtering, unlike perf) resolve identical addresses into confusing local
> labels instead of actual clear C function names.
> 
> Fix this by integrating the is_local_mapping_symbol() check directly into
> the newly introduced is_kept_symbol() helper. This ensures these unneeded
> symbols are stripped during module load time, keeping /proc/kallsyms clean
> and resulting in accurate call stacks.
> 
> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>

-- 
Thanks,
Petr

Re: [PATCH v3 1/3] module/kallsyms: Rename is_mapping_symbol() to is_local_mapping_symbol()

[Tiezhu Yang]

On 2026/8/18 下午7:56, Petr Pavlu wrote:
> On 8/12/26 5:28 AM, Tiezhu Yang wrote:
>> The helper function is_mapping_symbol() historically checks for both
>> local labels prefixed with ".L" or "L0" and mapping symbols prefixed
>> with "$".

...

> I think the updated comment and the function name are confusing. They
> read as if they are about local symbols in general (STB_LOCAL), but they
> should refer only to local label symbols (.L<xyz>, ...). The function
> would need to be called is_local_label_or_mapping_symbol() but that is
> too long.
> 
> If you do want to rename this function, one option is to be consistent
> with perf, which implements the same filter and calls it
> is_ignored_kernel_symbol().
> 
> The comment could also be clearer, for example:
> 
> /*
>   * Ignore local labels (.L*, L0*) and mapping symbols ($*). These symbols are
>   * not useful for the kernel, for example, they should not appear in kallsyms.
>   */

OK, it looks better, will do it in v4.

>>   {
>>   	if (str[0] == '.' && str[1] == 'L')
>>   		return true;

...

> Another comment-only reference to is_mapping_symbol() that should be
> updated is in tools/perf/util/symbol.h.

There may be conflicts between modules-next and perf-tools-next:

https://git.kernel.org/pub/scm/linux/kernel/git/modules/linux.git/log/tools/perf/util/symbol.h?h=modules-next
https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/log/tools/perf/util/symbol.h?h=perf-tools-next

So one way is to not modify tools/perf/util/symbol.h if based
on modules-next at this time, the other way is to rebase the
code and then send the series after the merge window.

Please let me know what is the proper way.

Thanks,
Tiezhu

Re: [PATCH v3 2/3] module/kallsyms: Refactor current symbol filtering into is_kept_symbol()

[Tiezhu Yang]

On 2026/8/18 下午7:58, Petr Pavlu wrote:
> On 8/12/26 5:28 AM, Tiezhu Yang wrote:
>> Currently, the loops in layout_symtab() and add_kallsyms() duplicate the
>> exact same checks (i == 0 || is_livepatch_module() || is_core_symbol())
>> to determine whether a symbol should be preserved in the module's core
>> symbol table.
>>
>> Rename is_core_symbol() to is_kept_symbol() and move the entire checking
>> logic inside it, including the special handlers for the first symbol and
>> livepatch modules.
>>
>> No functional change.
>>
>> Suggested-by: Petr Pavlu <petr.pavlu@suse.com>
>> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
> 
> Looks ok to me. I'm also fine also keeping the current name,
> is_core_symbol(), as Huacai mentions in his review [1]. I previously
> suggested is_kept_symbol() [2], since the is_livepatch_module() check
> is moved into this function. However, is_core_symbol() is still ok, as
> it is consistent with where the symbols are assigned, in
> module::core_kallsyms.

OK, let me use is_core_symbol() in v4.

> The important part is to avoid duplicating the checks that determine
> whether a symbol should be kept in layout_symtab() and add_kallsyms().
> 
> Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>

Thanks,
Tiezhu

Re: [PATCH v3 3/3] module/kallsyms: Filter out local and mapping symbols during module load

[Tiezhu Yang]

On 2026/8/18 下午7:59, Petr Pavlu wrote:
> On 8/12/26 5:28 AM, Tiezhu Yang wrote:
>> The compiler toolchains generate local and mapping symbols on certain
>> architectures like LoongArch for optimizations and relocations.
> 
> Nit: "local" -> "local label".

OK, will update the patch subject and commit message in v4.

>>
>> While the symbols are already filtered out during runtime lookups via
>> find_kallsyms_symbol(), they still leak into /proc/kallsyms for loaded
>> modules because layout_symtab() and add_kallsyms() do not filter them
>> during load time.
>>
>> Consequently, tracing tools like bpftrace (which do not perform internal
>> filtering, unlike perf) resolve identical addresses into confusing local
>> labels instead of actual clear C function names.
>>
>> Fix this by integrating the is_local_mapping_symbol() check directly into
>> the newly introduced is_kept_symbol() helper. This ensures these unneeded
>> symbols are stripped during module load time, keeping /proc/kallsyms clean
>> and resulting in accurate call stacks.
>>
>> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
> 
> Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>

Thanks,
Tiezhu

Re: [PATCH v3 1/3] module/kallsyms: Rename is_mapping_symbol() to is_local_mapping_symbol()

[Petr Pavlu]

On 8/18/26 3:04 PM, Tiezhu Yang wrote:
> On 2026/8/18 下午7:56, Petr Pavlu wrote:
>> Another comment-only reference to is_mapping_symbol() that should be
>> updated is in tools/perf/util/symbol.h.
> 
> There may be conflicts between modules-next and perf-tools-next:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/modules/linux.git/log/tools/perf/util/symbol.h?h=modules-next
> https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/log/tools/perf/util/symbol.h?h=perf-tools-next
> 
> So one way is to not modify tools/perf/util/symbol.h if based
> on modules-next at this time, the other way is to rebase the
> code and then send the series after the merge window.
> 
> Please let me know what is the proper way.

I don't immediately see that updating the comment in
tools/perf/util/symbol.h would cause a conflict with either modules-next
or perf-tools-next.

I think you can even base the series on mainline. It applies cleanly
to v7.2. If there happens to be a conflict, it should be minor and I can
deal with it.

Importantly, please Cc the maintainers of the updated non-module files
(scripts/faddr2line, scripts/mod/modpost.h, tools/perf/util/symbol.h) in
the next version of this patch so they are aware of the change.

-- 
Thanks,
Petr