From: Steven Rostedt <rostedt@xxxxxxxxxxx> 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 <nick.alcock@xxxxxxxxxx> wrote: > >> The kallmodsyms patch series was originally posted in Nov 2019, and the thread >> (https://lore.kernel.org/linux-kbuild/20191114223036.9359-1-eugene.loh@xxxxxxxxxx/t/#u) >> shows review comments, questions, and feedback from interested parties. >> Most recent posting: <https://lore.kernel.org/linux-modules/20221109134132.9052-1-nick.alcock@xxxxxxxxxx/T/#t>. >> >> 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@xxxxxxxxx Thanks, Olek
