[lkml]   [2021]   [Jul]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 01/17] kallsyms: support big kernel symbols (2-byte lengths)
On Sun, Jul 04, 2021 at 11:20:07PM +0100, Gary Guo wrote:
> This is big endian.

Fundamentally, it doesn't matter whether it's encoded as top-7 +
bottom-8 or bottom-7 + top-8. It could just as well be:

if (len >= 128) {
len -= 128;
len += *data * 256;

It doesn't matter whether it's compatible with some other encoding.
This encoding has one producer and one consumer. As long as they agree,
it's fine. If you want to make an argument about extensibiity, then
I'm going to suggest that wanting a symbol name more than 32kB in size
is a sign you've done something else very, very wrong.

At that point, you should probably switch to comparing hashes of the
symbol instead of the symbol. Indeed, I think we're already there at
300 byte symbols; we should probably SipHash the full, unmangled symbol
[1]. At 33k symbols in the current kernel, the risk of a collision of
a 64-bit value is negligible, and almost every kernel symbol is longer
than 7 bytes (thankfully).

[1] ie SipHash("void unlock_page(struct page *)")

 \ /
  Last update: 2021-07-05 00:43    [W:0.073 / U:1.268 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site