All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gary Guo <gary@garyguo.net>
To: Zheng Yejian <zhengyejian@huaweicloud.com>
Cc: arnd@arndb.de, kees@kernel.org, mcgrof@kernel.org,
	masahiroy@kernel.org, ndesaulniers@google.com, ardb@kernel.org,
	jannh@google.com, song@kernel.org, willy@infradead.org,
	boqun.feng@gmail.com, gregkh@linuxfoundation.org,
	wedsonaf@google.com, linux-kernel@vger.kernel.org,
	yeweihua4@huawei.com
Subject: Re: [PATCH v2] kallsyms: Fix wrong "big" kernel symbol type read from procfs
Date: Fri, 11 Oct 2024 15:08:35 +0100	[thread overview]
Message-ID: <20241011150835.465dde00@eugeo> (raw)
In-Reply-To: <20241011143853.3022643-1-zhengyejian@huaweicloud.com>

On Fri, 11 Oct 2024 22:38:53 +0800
Zheng Yejian <zhengyejian@huaweicloud.com> wrote:

> Currently when the length of a symbol is longer than 0x7f characters,
> its type shown in /proc/kallsyms can be incorrect.
> 
> I found this issue when reading the code, but it can be reproduced by
> following steps:
> 
>   1. Define a function which symbol length is 130 characters:
> 
>     #define X13(x) x##x##x##x##x##x##x##x##x##x##x##x##x
>     static noinline void X13(x123456789)(void)
>     {
>         printk("hello world\n");
>     }
> 
>   2. The type in vmlinux is 't':
> 
>     $ nm vmlinux | grep x123456
>     ffffffff816290f0 t x123456789x123456789x123456789x12[...]
> 
>   3. Then boot the kernel, the type shown in /proc/kallsyms becomes 'g'
>      instead of the expected 't':
> 
>     # cat /proc/kallsyms | grep x123456
>     ffffffff816290f0 g x123456789x123456789x123456789x12[...]
> 
> The root cause is that, after commit 73bbb94466fd ("kallsyms: support
> "big" kernel symbols"), ULEB128 was used to encode symbol name length.
> That is, for "big" kernel symbols of which name length is longer than
> 0x7f characters, the length info is encoded into 2 bytes.
> 
> kallsyms_get_symbol_type() expects to read the first char of the
> symbol name which indicates the symbol type. However, due to the
> "big" symbol case not being handled, the symbol type read from
> /proc/kallsyms may be wrong, so handle it properly.
> 
> Cc: stable@vger.kernel.org
> Fixes: 73bbb94466fd ("kallsyms: support "big" kernel symbols")
> Signed-off-by: Zheng Yejian <zhengyejian@huaweicloud.com>

Acked-by: Gary Guo <gary@garyguo.net>

> ---
> 
> v1 -> v2:
> - Add reproduction info into commit message to make it clearer;
> - Add cc: stable line;
> 
> v1: https://lore.kernel.org/all/20240830062935.1187613-1-zhengyejian@huaweicloud.com/
> 
>  kernel/kallsyms.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
> index a9a0ca605d4a..9e4bf061bb83 100644
> --- a/kernel/kallsyms.c
> +++ b/kernel/kallsyms.c
> @@ -103,8 +103,11 @@ static char kallsyms_get_symbol_type(unsigned int off)
>  {
>  	/*
>  	 * Get just the first code, look it up in the token table,
> -	 * and return the first char from this token.
> +	 * and return the first char from this token. If MSB of length
> +	 * is 1, it is a "big" symbol, so needs an additional byte.
>  	 */
> +	if (kallsyms_names[off] & 0x80)
> +		off++;
>  	return kallsyms_token_table[kallsyms_token_index[kallsyms_names[off + 1]]];
>  }
>  


  reply	other threads:[~2024-10-11 14:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-11 14:38 [PATCH v2] kallsyms: Fix wrong "big" kernel symbol type read from procfs Zheng Yejian
2024-10-11 14:08 ` Gary Guo [this message]
2024-10-11 22:01 ` Matthew Wilcox
2024-10-12  1:36   ` Zheng Yejian
2024-10-12  1:47   ` Gary Guo
2024-10-12  2:09     ` Zheng Yejian
2025-11-11 21:13 ` Miguel Ojeda
2025-11-16 22:30 ` Miguel Ojeda
2025-11-24 16:54   ` Miguel Ojeda

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20241011150835.465dde00@eugeo \
    --to=gary@garyguo.net \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=boqun.feng@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jannh@google.com \
    --cc=kees@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=song@kernel.org \
    --cc=wedsonaf@google.com \
    --cc=willy@infradead.org \
    --cc=yeweihua4@huawei.com \
    --cc=zhengyejian@huaweicloud.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.