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: Thu, 23 Jan 2025 19:36:14 +0100 [thread overview]
Message-ID: <Z5KMHoA7GlHJyUU_@minute> (raw)
In-Reply-To: <Z4-jgMJgbVriLaCr@minute>
On Tue, Jan 21, 2025 at 02:39:12PM +0100, 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.
Ivan.
diff --git a/arch/alpha/include/uapi/asm/ptrace.h b/arch/alpha/include/uapi/asm/ptrace.h
index 5ca45934fcbb..d2e8e69a18f1 100644
--- a/arch/alpha/include/uapi/asm/ptrace.h
+++ b/arch/alpha/include/uapi/asm/ptrace.h
@@ -49,7 +49,7 @@ struct pt_regs {
unsigned long r16;
unsigned long r17;
unsigned long r18;
-};
+} __attribute__((aligned(16))); /* GCC expects 16-byte stack alignment */
/*
* This is the extended stack used by signal handlers and the context
next prev parent reply other threads:[~2025-01-23 18:36 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 [this message]
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
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=Z5KMHoA7GlHJyUU_@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.