Re: [PATCH] kallsyms: remove unused arch_get_kallsym() helper

From: Luis Chamberlain
Date: Thu May 25 2023 - 23:24:30 EST


On Thu, May 25, 2023 at 06:45:35PM -0700, Song Liu wrote:
> + Alan Maguire
>
> On Wed, May 24, 2023 at 12:24 AM Luis Chamberlain <mcgrof@xxxxxxxxxx> wrote:
> >
> > On Wed, May 24, 2023 at 08:25:13AM +0200, Arnd Bergmann wrote:
> > > On Wed, May 24, 2023, at 07:07, Luis Chamberlain wrote:
> > > > On Wed, May 17, 2023 at 03:18:07PM +0200, Arnd Bergmann wrote:
> > > >> From: Arnd Bergmann <arnd@xxxxxxxx>
> > > >>
> > > >> The arch_get_kallsym() function was introduced so that x86 could override
> > > >> it, but that override was removed in bf904d2762ee ("x86/pti/64: Remove
> > > >> the SYSCALL64 entry trampoline"), so now this does nothing except causing
> > > >> a warning about a missing prototype:
> > > >>
> > > >> kernel/kallsyms.c:662:12: error: no previous prototype for 'arch_get_kallsym' [-Werror=missing-prototypes]
> > > >> 662 | int __weak arch_get_kallsym(unsigned int symnum, unsigned long *value,
> > > >>
> > > >> Restore the old behavior before d83212d5dd67 ("kallsyms, x86: Export
> > > >> addresses of PTI entry trampolines") to simplify the code and avoid
> > > >> the warning.
> > > >>
> > > >> Signed-off-by: Arnd Bergmann <arnd@xxxxxxxx>
> > > >
> > > > Shouldn't this go through x86 as this sort of fixesss commit
> > > > bf904d2762ee ("x86/pti/64: Remove the SYSCALL64 entry trampoline")?
> > >
> > > That works for me as well, as long as someone picks it up. It's
> > > not really x86 any more though since that commit is five years
> > > old and removed the last reference from the x86 code.
> >
> > Fair enough.
> >
> > > I sent it to you since you are the one that merged most of
> > > the kallsyms patches through the module tree, but I guess
> > > you are not actually maintaining that file (not blaming you,
> > > I'd also try to stay away from kallsyms).
> > >
> > > I can resend it to Andrew for the -mm tree.
> >
> > OK, I just took the patch in, it's on the train, better get on before
> > it gets lost.
>
> This change broke compilation of BPF selftests in modules-next
> branch:
>
> progs/bpf_iter_ksym.c:62:13: error: no member named 'pos_arch_end' in
> 'struct kallsym_iter'
> if (!iter->pos_arch_end || iter->pos_arch_end > iter->pos)
> ~~~~ ^
> progs/bpf_iter_ksym.c:62:35: error: no member named 'pos_arch_end' in
> 'struct kallsym_iter'
> if (!iter->pos_arch_end || iter->pos_arch_end > iter->pos)
> ~~~~ ^
>
> I haven't looked into the proper fix for it yet.

A quick attempt:

Arnd, can you verify?

diff --git a/tools/testing/selftests/bpf/progs/bpf_iter_ksym.c b/tools/testing/selftests/bpf/progs/bpf_iter_ksym.c
index 5ddcc46fd886..521267818f4d 100644
--- a/tools/testing/selftests/bpf/progs/bpf_iter_ksym.c
+++ b/tools/testing/selftests/bpf/progs/bpf_iter_ksym.c
@@ -59,9 +59,7 @@ int dump_ksym(struct bpf_iter__ksym *ctx)
} else {
BPF_SEQ_PRINTF(seq, "0x%llx %c %s ", value, type, iter->name);
}
- if (!iter->pos_arch_end || iter->pos_arch_end > iter->pos)
- BPF_SEQ_PRINTF(seq, "CORE ");
- else if (!iter->pos_mod_end || iter->pos_mod_end > iter->pos)
+ if (!iter->pos_mod_end || iter->pos_mod_end > iter->pos)
BPF_SEQ_PRINTF(seq, "MOD ");
else if (!iter->pos_ftrace_mod_end || iter->pos_ftrace_mod_end > iter->pos)
BPF_SEQ_PRINTF(seq, "FTRACE_MOD ");