From: Steven Rostedt <rostedt@goodmis.org>
Date: Mon, 8 May 2023 18:06:53 -0400
This topic came up at LSFMM, presented by Jiri.
I'm Cc'ing this email to the BPF mailing list.
-- Steve
On Mon, 5 Dec 2022 16:31:44 +0000
Nick Alcock [off-list ref] wrote:
quoted
The kallmodsyms patch series was originally posted in Nov 2019, and the thread
(https://lore.kernel.org/linux-kbuild/20191114223036.9359-1-eugene.loh@oracle.com/t/#u (local))
shows review comments, questions, and feedback from interested parties.
Most recent posting: <https://lore.kernel.org/linux-modules/20221109134132.9052-1-nick.alcock@oracle.com/T/#t (local)>.
All review comments have been satisfied, as far as I know: in particular
Yamada's note about translation units that are shared between built-in
modules is satisfied with a better representation which is also much, much
smaller, and we are no longer using modules_thick.builtin but Luis's new
modules.builtin.objs.
A kernel tree containing this series alone:
https://github.com/oracle/dtrace-linux-kernel kallmodsyms/6.1-rc4-modules-next
The whole point of symbols is that their names are unique: you can look up a
symbol and get back a unique address, and vice versa. Alas, because
/proc/kallsyms (rightly) reports all symbols, even hidden ones, it does not
really satisfy this requirement. Large numbers of symbols are duplicated
many times (just search for __list_del_entry!), and while usually these are
just out-of-lined things defined in header files and thus all have the same
implementation, it does make it needlessly hard to figure out which one is
which in stack dumps, when tracing, and such things. Some configuration
options make things much worse: my test make allyesconfig runs introduced
thousands of text symbols named _sub_I_65535_1, one per compiler-generated
object file, and it was fairly easy to make them appear in ftrace output.
FYI for devs: I posted RFC of kallsyms with file paths almost a year
ago[0], but it went unnoticed =\
`file name + function name` is not a unique pair: in one of FG-KASLR
discussions, someone even wrote simple script, which showed around 40
collisions in the kernel. My approach was to include file path starting
at the kernel root folder, i.e. `net/core/dev.o:register_netdev`.
I'm not sure why no comments happened back then tho. Maybe you could
take a look, I'm pretty busy with other projects, but if you find
anything useful there in the RFC, I could join to a little bit.
[0]
https://lore.kernel.org/all/20220818115306.1109642-1-alexandr.lobakin@intel.com (local)
Thanks,
Olek