On Sat, 25 Jan 2025, Ivan Kokshaysky wrote:
> > Are there other parts of the code that might unalign the stack, even
> > if the stack is properly aligned to begin with? i.e passing an uneven
> > number of function arguments on the stack or inside interrupt
> > handlers? Alpha does not make use of a separate interrupt stack,
> > right?
>
> Good questions. No, there is no separate interrupt stack, it's always the
> kernel one. Stack frames from interrupts in user mode are 64-byte aligned
> though. Interrupts in kernel mode, user mode syscalls and exceptions all
> use 6 x 64-bit word frames and do not change the stack [mis]alignment.
>
> So, what we have now:
> 1. The "normal" kernel stack is always misaligned by 8, thanks to
> the sizeof(struct pt_regs);
> 2. Syscalls and exceptions handlers receive 16-byte aligned stack, as it
> gets "fixed" by SAVE_ALL macro in entry.S, which pushes the odd number
> of registers on the stack;
> 3. Interrupt handlers may, or may not, have got an aligned stack depending
> on kernel/user mode in which the interrupt had come.
>
> Ugh.
Yeah, just as I observed in my other reply, but notice that syscalls and
exceptions handlers typically actually do *not* receive a 16-byte aligned
stack now.
> > On stack alignment in "ALPHA Calling Standard":
> > D.3.1 Stack Alignment
> >
> > "This standard requires that stacks be octaword aligned at the time a
> > new procedure is invoked. During the body of a procedure, however,
> > there is no requirement to keep this level of alignment (even though
> > it may be beneficial). This implies that any asynchronous interrupt
> > handlers must properly align the stack before any standard calls are
> > made."
>
> I hope we can rely on GCC changing $sp only by multiplies of 16.
Absolutely, the compiler would be completely broken otherwise.
> (Yes, there is still the UAPI issue that Maciej pointed out, but that's
> another story.)
So we now have two variants to pick from. I wish we could take yours as
it's certainly neater, but is it safe enough?
I can see arch/alpha/include/uapi/asm/ptrace.h was only incarnated as
late as in 2012 with commit 96433f6ee490 ("UAPI: (Scripted) Disintegrate
arch/alpha/include/asm") and according to the change heading made in an
automated way, with little public discussion, so maybe its existence is
actually an accident? Unlike some other platforms we don't expose this
`struct pt_regs' via ptrace(2) for PTRACE_GETREGS/PTRACE_SETREGS, which
we don't implement.
NB, here's a corresponding stack alignment report for your change:
start_kernel: SP: fffffc0000dcfe90
do_entInt: SP: fffffc0000dcfc60
copy_thread: SP: fffffc0000dcfc90, regs: fffffc0000dcff10, childregs: fffffc0001837f10, childstack: fffffc0001837ed0
do_page_fault: SP: fffffc0001837bb8
sys_exit_group: SP: fffffc00028bfef0
do_entUnaUser: SP: fffffc0001bcfe68
do_entArith: SP: fffffc0001dfbee0
do_entIF: SP: fffffc0001fafee0
so there's still work to be done for `entMM' and `entUna' exceptions.
Maciej
