On Sat, 25 Jan 2025, Ivan Kokshaysky wrote:
> > 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.
>
> Interesting. Perhaps these frames are aligned by PAL-code as well,
> the reference manual wasn't clear about that.
I think it just boils down to the amount of exception nesting.
> > 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.
>
> Yeah, a bit of e-mail desync, sorry :)
No worries.
> At the moment I compile gdb with empty asm/ptrace.h just to be 100% sure.
I can't see this stuff being used anywhere in Alpha/GDB.
> > 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.
>
> I knew about entUna, I thought it's safe as it only deals with 64-bit data
> and not going to be changed in future, but missed entMM...
>
> I agree, better fix both.
Well, we may get away with it in many cases, which is obviously why
this bug has survived so long, but in principle it is not safe to enter
C code with the stack misaligned, so yes, we need to fix all the code
paths, also because a nested exception will cause hell to break loose.
Here just bumping up the frame size and adjusting offsets in assembly
code accordingly so as to account for the empty longword at the bottom
of the frame should do, just as I did across my change.
Maciej
