Re: Kernel Oops on alpha with kernel version >=6.9.x

[Ivan Kokshaysky <ink@unseen.parts>]

On Sat, Jan 25, 2025 at 05:01:42PM +0000, Maciej W. Rozycki 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.

> > > 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.

Yeah, a bit of e-mail desync, sorry :)

At the moment I compile gdb with empty asm/ptrace.h just to be 100% sure.

>  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.

Ivan.