Re: [PATCH v2] kallsyms: Fix wrong "big" kernel symbol type read from procfs

[Zheng Yejian]

On 2024/10/12 09:47, Gary Guo wrote:
> On Fri, 11 Oct 2024 23:01:12 +0100
> Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote:
>
> > On Fri, Oct 11, 2024 at 10:38:53PM +0800, Zheng Yejian wrote:
> > > 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.
> >
> > Technically, at least two.  If we ever have a symbol larger than
> > 16kB, we'll use three bytes.
>
> Let's not worry about things that would not happen.
>
> scripts/kallsyms.c have a check to ensure that symbol names don't get
> longer than 0x3FFF.

Yes, so currently in kallsyms_expand_symbol() and get_symbol_offset(), the
symbol length are also assumed to be encoded into one byte or two bytes.
If considering the "longer than 0x3FFF" case, those two functions may should
also be changed.

> Best,
> Gary
>
> > > +++ 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++;
> >
> > So this "if" should be a "while" for maximum future proofing against the
> > day that we have a 16kB function ...

--
Thanks,
Zheng Yejian