Alpha arch development list
 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: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CA+=Fv5R9NG+1SHU9QV9hjmavycHKpnNyerQ=Ei90G98ukRcRJA@mail.gmail.com>
     [not found] ` <f1561626-fde6-41c0-9d45-87a6a7b13816@paulmck-laptop>
     [not found]   ` <CA+=Fv5TMZ1bckob2VZ1AaNwdU3R+5a8REKg4aZR8novx7+dj-g@mail.gmail.com>
     [not found]     ` <8e365392-0e0d-4d78-bae7-69f27c8350f9@paulmck-laptop>
2024-12-04 22:22       ` Kernel Oops on alpha with kernel version >=6.9.x 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
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox