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.
