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

[Ivan Kokshaysky <ink@unseen.parts>]

On Thu, Jan 23, 2025 at 11:57:03PM +0000, Maciej W. Rozycki wrote:
> On Thu, 23 Jan 2025, Ivan Kokshaysky wrote:
> 
> > > Indeed, SP_OFF in entry.S is the main suspect at the moment.
> > 
> > In fact, it's the odd number of longs (29) in struct pt_regs that makes
> > the stack misaligned by 8 bytes. The patch below works for me - no more
> > oopses in rcu-torture test.
> > 
> > Unless I'm missing something, this change shouldn't have any ill effects.
> 
>  Umm, this is a part of UAPI, and the change in alignment changes the ABI 
> (think padding where `struct pt_regs' has been embedded into another 
> structure), so AFAICT it is a no-no.

Well, the only userspace applications I can think of that need kernel
stack layout are debuggers, but at least alpha gdb doesn't use this header.
Doesn't matter, though - padding *after* PAL-saved registers is wrong
thing to do. I think it's the reason for oopses that Magnus reported
today.

A "long" padding memder of pt_regs placed *before* PAL-saved registers
would be a proper fix for kernel, but it most likely would break gdb...

>  But the only place I could quickly find this should matter for is this:
> 
> 	/* ... and find our stack ... */
> 	lda	$30,0x4000 - SIZEOF_PT_REGS($8)
> 
> which should be straightforward to fix:
> 
> 	lda	$30,0x4000 - ((SIZEOF_PT_REGS + 15) & ~15)($8)
> 
> or suchlike.  Have I missed anything?

That's the first thing I thought of too, but no, it's just a kernel
entry point after the bootloader. The stack pointer of kernel threads
is assigned in alpha/kernel/process.c. Particularly, these macros
in ptrace.h (non-uapi) are interesting:

#define task_pt_regs(task) \
  ((struct pt_regs *) (task_stack_page(task) + 2*PAGE_SIZE) - 1)

#define current_pt_regs() \
  ((struct pt_regs *) ((char *)current_thread_info() + 2*PAGE_SIZE) - 1)

I'll try to play with alignment here, but it will take some time.

Ivan.