Parts of asm/ptrace.h went into UAPI with commit 96433f6ee490
("UAPI: (Scripted) Disintegrate arch/alpha/include/asm") back in 2012.
At first glance it looked correct, as many other architectures expose
'struct pt_regs' for ptrace(2) PTRACE_GETREGS/PTRACE_SETREGS requests
and bpf(2) BPF_PROG_TYPE_KPROBE/BPF_PROG_TYPE_PERF_EVENT program
types.
On Alpha, however, these requests have never been implemented;
'struct pt_regs' describes internal kernel stack frame which has
nothing to do with userspace. Same applies to 'struct switch_stack',
as PTRACE_GETFPREG/PTRACE_SETFPREG are not implemented either.
Move this stuff back into internal asm, where we can ajust it
without causing a lot of confusion about possible UAPI breakage.
Cc: stable@vger.kernel.org
Fixes: 96433f6ee490 ("UAPI: (Scripted) Disintegrate arch/alpha/include/asm")
Signed-off-by: Ivan Kokshaysky <ink@unseen.parts>
---
arch/alpha/include/asm/ptrace.h | 62 +++++++++++++++++++++++++-
arch/alpha/include/uapi/asm/ptrace.h | 65 ++--------------------------
2 files changed, 64 insertions(+), 63 deletions(-)
diff --git a/arch/alpha/include/asm/ptrace.h b/arch/alpha/include/asm/ptrace.h
index 3557ce64ed21..693d4c5b4dc7 100644
--- a/arch/alpha/include/asm/ptrace.h
+++ b/arch/alpha/include/asm/ptrace.h
@@ -2,8 +2,68 @@
#ifndef _ASMAXP_PTRACE_H
#define _ASMAXP_PTRACE_H
-#include <uapi/asm/ptrace.h>
+/*
+ * This struct defines the way the registers are stored on the
+ * kernel stack during a system call or other kernel entry
+ *
+ * NOTE! I want to minimize the overhead of system calls, so this
+ * struct has as little information as possible. It does not have
+ *
+ * - floating point regs: the kernel doesn't change those
+ * - r9-15: saved by the C compiler
+ *
+ * This makes "fork()" and "exec()" a bit more complex, but should
+ * give us low system call latency.
+ */
+struct pt_regs {
+ unsigned long r0;
+ unsigned long r1;
+ unsigned long r2;
+ unsigned long r3;
+ unsigned long r4;
+ unsigned long r5;
+ unsigned long r6;
+ unsigned long r7;
+ unsigned long r8;
+ unsigned long r19;
+ unsigned long r20;
+ unsigned long r21;
+ unsigned long r22;
+ unsigned long r23;
+ unsigned long r24;
+ unsigned long r25;
+ unsigned long r26;
+ unsigned long r27;
+ unsigned long r28;
+ unsigned long hae;
+/* JRP - These are the values provided to a0-a2 by PALcode */
+ unsigned long trap_a0;
+ unsigned long trap_a1;
+ unsigned long trap_a2;
+/* These are saved by PAL-code: */
+ unsigned long ps;
+ unsigned long pc;
+ unsigned long gp;
+ unsigned long r16;
+ unsigned long r17;
+ unsigned long r18;
+};
+
+/*
+ * This is the extended stack used by signal handlers and the context
+ * switcher: it's pushed after the normal "struct pt_regs".
+ */
+struct switch_stack {
+ unsigned long r9;
+ unsigned long r10;
+ unsigned long r11;
+ unsigned long r12;
+ unsigned long r13;
+ unsigned long r14;
+ unsigned long r15;
+ unsigned long r26;
+};
#define arch_has_single_step() (1)
#define user_mode(regs) (((regs)->ps & 8) != 0)
diff --git a/arch/alpha/include/uapi/asm/ptrace.h b/arch/alpha/include/uapi/asm/ptrace.h
index 5ca45934fcbb..ad55dc283d8d 100644
--- a/arch/alpha/include/uapi/asm/ptrace.h
+++ b/arch/alpha/include/uapi/asm/ptrace.h
@@ -2,72 +2,13 @@
#ifndef _UAPI_ASMAXP_PTRACE_H
#define _UAPI_ASMAXP_PTRACE_H
-
/*
- * This struct defines the way the registers are stored on the
- * kernel stack during a system call or other kernel entry
- *
- * NOTE! I want to minimize the overhead of system calls, so this
- * struct has as little information as possible. It does not have
- *
- * - floating point regs: the kernel doesn't change those
- * - r9-15: saved by the C compiler
+ * We don't HAVE_REGS_AND_STACK_ACCESS_API.
*
- * This makes "fork()" and "exec()" a bit more complex, but should
- * give us low system call latency.
+ * Provide empty pt_regs structure for libbpf and the likes
+ * to avoid breaking the compilation.
*/
-
struct pt_regs {
- unsigned long r0;
- unsigned long r1;
- unsigned long r2;
- unsigned long r3;
- unsigned long r4;
- unsigned long r5;
- unsigned long r6;
- unsigned long r7;
- unsigned long r8;
- unsigned long r19;
- unsigned long r20;
- unsigned long r21;
- unsigned long r22;
- unsigned long r23;
- unsigned long r24;
- unsigned long r25;
- unsigned long r26;
- unsigned long r27;
- unsigned long r28;
- unsigned long hae;
-/* JRP - These are the values provided to a0-a2 by PALcode */
- unsigned long trap_a0;
- unsigned long trap_a1;
- unsigned long trap_a2;
-/* These are saved by PAL-code: */
- unsigned long ps;
- unsigned long pc;
- unsigned long gp;
- unsigned long r16;
- unsigned long r17;
- unsigned long r18;
};
-/*
- * This is the extended stack used by signal handlers and the context
- * switcher: it's pushed after the normal "struct pt_regs".
- */
-struct switch_stack {
- unsigned long r9;
- unsigned long r10;
- unsigned long r11;
- unsigned long r12;
- unsigned long r13;
- unsigned long r14;
- unsigned long r15;
- unsigned long r26;
-#ifndef __KERNEL__
- unsigned long fp[32]; /* fp[31] is fpcr */
-#endif
-};
-
-
#endif /* _UAPI_ASMAXP_PTRACE_H */
--
2.39.5Hi Ivan,
On Fri, 2025-01-31 at 11:41 +0100, Ivan Kokshaysky wrote:
> Parts of asm/ptrace.h went into UAPI with commit 96433f6ee490
> ("UAPI: (Scripted) Disintegrate arch/alpha/include/asm") back in 2012.
> At first glance it looked correct, as many other architectures expose
> 'struct pt_regs' for ptrace(2) PTRACE_GETREGS/PTRACE_SETREGS requests
> and bpf(2) BPF_PROG_TYPE_KPROBE/BPF_PROG_TYPE_PERF_EVENT program
> types.
>
> On Alpha, however, these requests have never been implemented;
> 'struct pt_regs' describes internal kernel stack frame which has
> nothing to do with userspace. Same applies to 'struct switch_stack',
> as PTRACE_GETFPREG/PTRACE_SETFPREG are not implemented either.
>
> Move this stuff back into internal asm, where we can ajust it
Typo: ajust => adjust
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On Fri, 31 Jan 2025, Ivan Kokshaysky wrote:
> Parts of asm/ptrace.h went into UAPI with commit 96433f6ee490
> ("UAPI: (Scripted) Disintegrate arch/alpha/include/asm") back in 2012.
> At first glance it looked correct, as many other architectures expose
> 'struct pt_regs' for ptrace(2) PTRACE_GETREGS/PTRACE_SETREGS requests
> and bpf(2) BPF_PROG_TYPE_KPROBE/BPF_PROG_TYPE_PERF_EVENT program
> types.
>
> On Alpha, however, these requests have never been implemented;
> 'struct pt_regs' describes internal kernel stack frame which has
> nothing to do with userspace. Same applies to 'struct switch_stack',
> as PTRACE_GETFPREG/PTRACE_SETFPREG are not implemented either.
I note that we, unusually, neither save nor even have room for statics in
`struct pt_regs', so this structure by itself is unsuitable to pass the
register file around with tracing calls and the like. So it seems to me
there's no point in exporting `struct pt_regs' in any way to the userland.
What do you think about providing arch/alpha/include/asm/bpf_perf_event.h
instead with either a dummy definition of `bpf_user_pt_regs_t', or perhaps
one typedef'd to `struct sigcontext' (as it seems to provide all that's
needed), and then reverting to v1 of arch/alpha/include/uapi/asm/ptrace.h
(and then just copying the contents of arch/alpha/include/asm/ftrace.h
over rather than leaving all the useless CPP stuff in) so that we don't
have useless `struct pt_regs' exported at all?
> Move this stuff back into internal asm, where we can ajust it
s/ajust/adjust/ (NB scripts/checkpatch.pl does complain about it).
Maciej
On Sun, Feb 02, 2025 at 05:39:52PM +0000, Maciej W. Rozycki wrote: > What do you think about providing arch/alpha/include/asm/bpf_perf_event.h > instead with either a dummy definition of `bpf_user_pt_regs_t', or perhaps > one typedef'd to `struct sigcontext' (as it seems to provide all that's > needed), and then reverting to v1 of arch/alpha/include/uapi/asm/ptrace.h > (and then just copying the contents of arch/alpha/include/asm/ftrace.h > over rather than leaving all the useless CPP stuff in) so that we don't > have useless `struct pt_regs' exported at all? Probably that's the right thing to do. However, it implies adding #elif defined(__alpha__) #include "../../arch/alpha/include/uapi/asm/bpf_perf_event.h" in tools/include/uapi/asm/bpf_perf_event.h. I'm afraid that will result in too many loosely related changes for this patch series. I'm starting to think that the best way for the time being is to keep uapi/asm/ptrace.h and apply the fix there (i.e. revert to v0 patch posted on linux-alpha). And mention the pt_regs vs uapi issue in the commit message, of course, to deal with it later. Your opinion? Ivan.
On Mon, 3 Feb 2025, Ivan Kokshaysky wrote: > > What do you think about providing arch/alpha/include/asm/bpf_perf_event.h > > instead with either a dummy definition of `bpf_user_pt_regs_t', or perhaps > > one typedef'd to `struct sigcontext' (as it seems to provide all that's > > needed), and then reverting to v1 of arch/alpha/include/uapi/asm/ptrace.h > > (and then just copying the contents of arch/alpha/include/asm/ftrace.h > > over rather than leaving all the useless CPP stuff in) so that we don't > > have useless `struct pt_regs' exported at all? > > Probably that's the right thing to do. However, it implies adding > > #elif defined(__alpha__) > #include "../../arch/alpha/include/uapi/asm/bpf_perf_event.h" > > in tools/include/uapi/asm/bpf_perf_event.h. I'm afraid that will > result in too many loosely related changes for this patch series. This seems to be the way, but... > I'm starting to think that the best way for the time being is to keep > uapi/asm/ptrace.h and apply the fix there (i.e. revert to v0 patch > posted on linux-alpha). And mention the pt_regs vs uapi issue in the > commit message, of course, to deal with it later. Your opinion? ... I agree. I find this a pragmatic path of least resistance approach, which will keep backports to the minimum and prevent Greg from getting rightfully grumpy about it. We need to get things straight here and BPF is the least of a problem. Let's go for this minimal variant then. This will also buy us time to think what the structure format will be right for `bpf_user_pt_regs_t' and whether `struct sigcontext' is indeed the best fit. Perhaps we'll want to define an entirely new structure and use it also for regset support, which I suppose would be good having, as it simplifies handling in debug software. I'm not sure offhand though, which I suppose is a good sign to defer this stuff to a later change. NB GCC verification has completed successfully with no regressions (but no progressions either; there've been a couple of changes both ways with intermittent failures, mostly in Fortran and Go, but none related to this patch series), and glibc verification is still running; by the look of the progress current ETC is sadly Fri-Sat only. The previous glibc run completed in ~25h, but this time the testsuite includes recently added 576 extra formatted output `printf' tests, which I admit to have committed myself, which owing to their duration I proposed to be a part of the extended set, but the community insisted that they be a part of the regular set, to widen coverage. This subset has already been running for ~30h and has made it through ~25%. So there you go. For reference the 576 extra test cases complete in ~30m on POWER9 (in a serial run; a parallel run is obviously much faster on this 64-way SMP system, but infeasible with the UP Alpha over the network, so I need to compare apples to apples), which just shows how irrelevant the performance of these legacy systems nowadays is and it's just the matter of keeping them alive with current software that has been my objective all the time. Maciej
© 2016 - 2026 Red Hat, Inc.