[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Z4D7Qx6pQEZ/bHDa@linux.ibm.com>
Date: Fri, 10 Jan 2025 16:19:39 +0530
From: Saket Kumar Bhaskar <skb99@...ux.ibm.com>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: bpf@...r.kernel.org, linux-kselftest@...r.kernel.org,
linux-kernel@...r.kernel.org, ast@...nel.org, hbathini@...ux.ibm.com,
andrii@...nel.org, daniel@...earbox.net, martin.lau@...ux.dev,
eddyz87@...il.com, song@...nel.org, yonghong.song@...ux.dev,
john.fastabend@...il.com, kpsingh@...nel.org, sdf@...ichev.me,
haoluo@...gle.com, jolsa@...nel.org, shuah@...nel.org, mykolal@...com
Subject: Re: [PATCH 2/3] libbpf: Remove powerpc prefix from syscall function
names
On Thu, Nov 21, 2024 at 04:00:13PM -0800, Andrii Nakryiko wrote:
> On Wed, Nov 20, 2024 at 6:52 AM Saket Kumar Bhaskar <skb99@...ux.ibm.com> wrote:
> >
> > On Fri, Nov 08, 2024 at 10:43:54AM -0800, Andrii Nakryiko wrote:
> > > On Sun, Nov 3, 2024 at 9:00 PM Saket Kumar Bhaskar <skb99@...ux.ibm.com> wrote:
> > > >
> > > > Since commit 94746890202cf ("powerpc: Don't add __powerpc_ prefix to
> > > > syscall entry points") drops _powerpc prefix to syscall entry points,
> > > > even though powerpc now supports syscall wrapper, so /proc/kallsyms
> > > > have symbols for syscall entry without powerpc prefix(sys_*).
> > > >
> > > > For this reason, arch specific prefix for syscall functions in powerpc
> > > > is dropped.
> > > >
> > > > Signed-off-by: Saket Kumar Bhaskar <skb99@...ux.ibm.com>
> > > > ---
> > > > tools/lib/bpf/libbpf.c | 12 +++++++++---
> > > > 1 file changed, 9 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> > > > index 219facd0e66e..3a370fa37d8a 100644
> > > > --- a/tools/lib/bpf/libbpf.c
> > > > +++ b/tools/lib/bpf/libbpf.c
> > > > @@ -11110,9 +11110,7 @@ static const char *arch_specific_syscall_pfx(void)
> > > > #elif defined(__riscv)
> > > > return "riscv";
> > > > #elif defined(__powerpc__)
> > > > - return "powerpc";
> > > > -#elif defined(__powerpc64__)
> > > > - return "powerpc64";
> > > > + return "";
> > > > #else
> > > > return NULL;
> > > > #endif
> > > > @@ -11127,7 +11125,11 @@ int probe_kern_syscall_wrapper(int token_fd)
> > > > if (!ksys_pfx)
> > > > return 0;
> > > >
> > > > +#if defined(__powerpc__)
> > > > + snprintf(syscall_name, sizeof(syscall_name), "sys_bpf");
> > > > +#else
> > > > snprintf(syscall_name, sizeof(syscall_name), "__%s_sys_bpf", ksys_pfx);
> > > > +#endif
> > >
> > > The problem is that on older versions of kernel it will have this
> > > prefix, while on newer ones it won't. So to not break anything on old
> > > kernels, we'd need to do feature detection and pick whether to use
> > > prefix or not, right?
> > >
> > > So it seems like this change needs a bit more work.
> > >
> > > pw-bot: cr
> > >
> > Hi Andrii,
> >
> > IMO since both the patches 7e92e01b7245(powerpc: Provide syscall wrapper)
> > and 94746890202cf(powerpc: Don't add __powerpc_ prefix to syscall entry points)
> > went into the same kernel version v6.1-rc1, there won't me much kernel
> > versions that has only one of these patches.
> >
> > Also, to test more I tried this patch with ARCH_HAS_SYSCALL_WRAPPER disabled,
> > and it the test passed in this case too.
> >
>
> Keep in mind that libbpf is supposed to work across many kernel
> versions. So as long as there are powerpc (old) kernels that do use
> arch-specific prefix, we need to detect them and supply prefix when
> attaching ksyscall programs.
>
Hi Andrii,
Sorry about the delayed response, I have started looking at this after
a vacation.
There are unlikely to be any old kernels that use arch-specific prefix
as syscall wrapper support was added to powerpc in v6.1 and
commit 94746890202cf that dropped the prefix also went into the same
kernel release (v6.1-rc1). So, is it worth it support both sys_bpf and
__powerpc_sys_bpf cases?
But yes, there can be a kernel without syscall wrapper but having the
sys_bpf symbol. So, how about identifying syscall wrapper enablement
with __se_sys_bpf instead:
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 66173ddb5a2d..ff69a30cfe9b 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -11163,11 +11163,15 @@ int probe_kern_syscall_wrapper(int token_fd)
char syscall_name[64];
const char *ksys_pfx;
+#if defined(__powerpc__)
+ snprintf(syscall_name, sizeof(syscall_name), "__se_sys_bpf", ksys_pfx);
+#else
ksys_pfx = arch_specific_syscall_pfx();
if (!ksys_pfx)
return 0;
snprintf(syscall_name, sizeof(syscall_name), "__%s_sys_bpf", ksys_pfx);
+#endif
if (determine_kprobe_perf_type() >= 0) {
int pfd;
@@ -11176,16 +11180,28 @@ int probe_kern_syscall_wrapper(int token_fd)
if (pfd >= 0)
close(pfd);
+#if defined(__powerpc__)
return pfd >= 0 ? 1 : 0;
+#else
+ return pfd >= 0 ? 1 : 0;
+#endif
} else { /* legacy mode */
char probe_name[128];
gen_kprobe_legacy_event_name(probe_name, sizeof(probe_name), syscall_name, 0);
if (add_kprobe_event_legacy(probe_name, false, syscall_name, 0) < 0)
+#if defined(__powerpc__)
+ return 1;
+#else
return 0;
+#endif
(void)remove_kprobe_event_legacy(probe_name, false);
+#if defined(__powerpc__)
+ return 0;
+#else
return 1;
+#endif
}
}
Actually, all architectures could use this '__se_' prefix instead of
arch specific prefix to identify if syscall wrapper is enabled.
Separate way to handle powerpc case may not be needed. Will
wait for your inputs to send v2.
Thanks,
Saket
> > Thanks,
> > Saket
> > > >
> > > > if (determine_kprobe_perf_type() >= 0) {
> > > > int pfd;
> > > > @@ -11272,8 +11274,12 @@ struct bpf_link *bpf_program__attach_ksyscall(const struct bpf_program *prog,
> > > > * compiler does not know that we have an explicit conditional
> > > > * as well.
> > > > */
> > > > +#if defined(__powerpc__)
> > > > + snprintf(func_name, sizeof(func_name), "sys_%s", syscall_name);
> > > > +#else
> > > > snprintf(func_name, sizeof(func_name), "__%s_sys_%s",
> > > > arch_specific_syscall_pfx() ? : "", syscall_name);
> > > > +#endif
> > > > } else {
> > > > snprintf(func_name, sizeof(func_name), "__se_sys_%s", syscall_name);
> > > > }
> > > > --
> > > > 2.43.5
> > > >
Powered by blists - more mailing lists