All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ivan Kokshaysky <ink@unseen.parts>
To: "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc: Magnus Lindholm <linmag7@gmail.com>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Michael Cree <mcree@orcon.net.nz>,
	John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
	rcu@vger.kernel.org, linux-alpha@vger.kernel.org
Subject: Re: Kernel Oops on alpha with kernel version >=6.9.x
Date: Sat, 25 Jan 2025 18:09:15 +0100	[thread overview]
Message-ID: <Z5Uauwl0qqHhiGZk@minute> (raw)
In-Reply-To: <alpine.DEB.2.21.2501241058520.27203@angie.orcam.me.uk>

On Sat, Jan 25, 2025 at 03:35:08PM +0000, Maciej W. Rozycki wrote:
> On Fri, 24 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.
> 
>  So after a crash course in PALcode stack frames I have come up with the 
> following WIP patch that works for me.  If things go well, I'll clean it 
> up a little and turn into a proper patch submission.  Not that I think I 
> can make the end result particularly pretty, there's no easy way AFAICT.
> 
>  NB with some instrumentation here's what gets reported for stack without:
> 
> start_kernel: SP: fffffc0000dcfe98
> do_entInt: SP: fffffc0000dcfc30
> copy_thread: SP: fffffc0000dcfc98, regs: fffffc0000dcff18, childregs: fffffc0001837f18, childstack: fffffc0001837ed8
> do_page_fault: SP: fffffc0001837bc8
> sys_exit_group: SP: fffffc0002917ef8
> do_entUnaUser: SP: fffffc0001f33e70
> do_entArith: SP: fffffc0001f33ee8
> do_entIF: SP: fffffc000184bee8
> 
> and with the patch:
> 
> start_kernel: SP: fffffc0000dcfe90
> do_entInt: SP: fffffc0000dcfc20
> copy_thread: SP: fffffc0000dcfc90, regs: fffffc0000dcff18, childregs: fffffc000183bf18, childstack: fffffc000183bed0
> do_page_fault: SP: fffffc000183bbc0
> sys_exit_group: SP: fffffc00028d3ef0
> do_entUnaUser: SP: fffffc000292fe70
> do_entArith: SP: fffffc0001d7fee0
> do_entIF: SP: fffffc0002827ee0
> 
> for the relevant situations (except for `entDbg', but that's analogous and 
> largely unused anyway).
> 
>  Can you guys please give it a try?

Oh. I have little doubt it works, but so much hard work just to keep
the pt_regs thing intact? Instead of asking ourselves how come it ended
up in uapi?

It was commit 96433f6ee49032d7a8b back in 2012 done by some scripting,
I believe it was by mistake, because it's the kernel bowels exposed for
absolutely no reason. I was going to propose a patch below (I don't think
we can remove the file, as it probably break build of packages like
linux-libc), and then add padding to pt_regs with exactly the same effect
as your patch.

Ivan.

diff --git a/arch/alpha/include/uapi/asm/ptrace.h b/arch/alpha/include/uapi/asm/ptrace.h
index 5ca45934fcbb..6b09e1df343d 100644
--- a/arch/alpha/include/uapi/asm/ptrace.h
+++ b/arch/alpha/include/uapi/asm/ptrace.h
@@ -2,7 +2,7 @@
 #ifndef _UAPI_ASMAXP_PTRACE_H
 #define _UAPI_ASMAXP_PTRACE_H
 
-
+#ifdef __KERNEL__
 /*
  * This struct defines the way the registers are stored on the
  * kernel stack during a system call or other kernel entry
@@ -64,10 +64,7 @@ struct switch_stack {
 	unsigned long r14;
 	unsigned long r15;
 	unsigned long r26;
-#ifndef __KERNEL__
-	unsigned long fp[32];	/* fp[31] is fpcr */
-#endif
 };
-
+#endif
 
 #endif /* _UAPI_ASMAXP_PTRACE_H */

  reply	other threads:[~2025-01-25 17:09 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-30 22:22 Kernel Oops on alpha with kernel version >=6.9.x Magnus Lindholm
2024-12-01  4:31 ` Paul E. McKenney
2024-12-01 10:09   ` Magnus Lindholm
2024-12-01 17:04     ` Paul E. McKenney
2024-12-04 22:22       ` Magnus Lindholm
2024-12-05 15:39         ` John Paul Adrian Glaubitz
2024-12-05 17:02           ` Magnus Lindholm
2024-12-06 15:39             ` Magnus Lindholm
2024-12-06 17:05               ` John Paul Adrian Glaubitz
2024-12-07 12:33                 ` Magnus Lindholm
2024-12-07 12:39                   ` John Paul Adrian Glaubitz
2024-12-07 17:33                     ` Magnus Lindholm
2024-12-07 18:38                       ` John Paul Adrian Glaubitz
2024-12-08  9:43                         ` Magnus Lindholm
2024-12-08 21:39                           ` Magnus Lindholm
2024-12-08 23:18                             ` Michael Cree
2024-12-08 23:31                               ` John Paul Adrian Glaubitz
2024-12-09  8:11                                 ` Magnus Lindholm
2024-12-12 23:23                                   ` Magnus Lindholm
2024-12-09  8:05                               ` Magnus Lindholm
2024-12-16 22:10                                 ` Michael Cree
2024-12-17  6:23                                   ` Magnus Lindholm
2024-12-18 19:33                                     ` Magnus Lindholm
2024-12-18 20:31                                       ` Paul E. McKenney
2024-12-18 21:54                                         ` Magnus Lindholm
2024-12-18 22:50                                           ` Paul E. McKenney
2024-12-19 22:38                                             ` Magnus Lindholm
2024-12-19 23:03                                               ` Paul E. McKenney
2024-12-20  0:00                                                 ` Maciej W. Rozycki
2024-12-27 10:42                                                   ` Magnus Lindholm
2024-12-27 11:48                                                     ` John Paul Adrian Glaubitz
2024-12-27 16:30                                                     ` Maciej W. Rozycki
2024-12-31 10:43                                                       ` Magnus Lindholm
2025-01-12 23:25                                                         ` Magnus Lindholm
2025-01-13  0:19                                                           ` Maciej W. Rozycki
2025-01-13  3:08                                                             ` Maciej W. Rozycki
2025-01-13  5:59                                                             ` Magnus Lindholm
2025-01-13  8:04                                                               ` Maciej W. Rozycki
2025-01-13 16:52                                                               ` Magnus Lindholm
2025-01-20 13:01                                                                 ` Magnus Lindholm
2025-01-20 13:19                                                                   ` Maciej W. Rozycki
2025-01-21 13:39                                                                     ` Ivan Kokshaysky
2025-01-23 18:36                                                                       ` Ivan Kokshaysky
2025-01-23 23:00                                                                         ` Magnus Lindholm
2025-01-23 23:51                                                                           ` Michael Cree
2025-01-23 23:57                                                                         ` Maciej W. Rozycki
2025-01-24  6:06                                                                           ` Magnus Lindholm
2025-01-24 10:55                                                                           ` Ivan Kokshaysky
2025-01-24 16:57                                                                             ` Magnus Lindholm
2025-01-25 15:15                                                                               ` Ivan Kokshaysky
2025-01-25 17:01                                                                                 ` Maciej W. Rozycki
2025-01-25 17:43                                                                                   ` Ivan Kokshaysky
2025-01-25 18:25                                                                                     ` Maciej W. Rozycki
2025-01-25 18:59                                                                                       ` Maciej W. Rozycki
2025-01-25 19:48                                                                                         ` Ivan Kokshaysky
2025-01-25 22:06                                                                                           ` Maciej W. Rozycki
2025-01-25 23:02                                                                                             ` Ivan Kokshaysky
2025-01-26 14:00                                                                                               ` Ivan Kokshaysky
2025-01-26 19:15                                                                                                 ` Magnus Lindholm
2025-01-27 11:48                                                                                                   ` Ivan Kokshaysky
2025-01-27 11:56                                                                                                     ` John Paul Adrian Glaubitz
2025-01-25 18:07                                                                                 ` Magnus Lindholm
2025-01-25 15:35                                                                             ` Maciej W. Rozycki
2025-01-25 17:09                                                                               ` Ivan Kokshaysky [this message]
2025-01-24  6:54                                                                         ` John Paul Adrian Glaubitz
  -- strict thread matches above, loose matches on Subject: below --
2024-11-24 21:47 Magnus Lindholm

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z5Uauwl0qqHhiGZk@minute \
    --to=ink@unseen.parts \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=linmag7@gmail.com \
    --cc=linux-alpha@vger.kernel.org \
    --cc=macro@orcam.me.uk \
    --cc=mcree@orcon.net.nz \
    --cc=paulmck@kernel.org \
    --cc=rcu@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.