From: Yao Zi <me@ziyao.cc>
To: Nathan Chancellor <nathan@kernel.org>
Cc: "Thomas Bogendoerfer" <tsbogend@alpha.franken.de>,
"Nick Desaulniers" <nick.desaulniers+lkml@gmail.com>,
"Bill Wendling" <morbo@google.com>,
"Justin Stitt" <justinstitt@google.com>,
"Thomas Weißschuh" <thomas.weissschuh@linutronix.de>,
linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org,
llvm@lists.linux.dev, stable@vger.kernel.org
Subject: Re: [PATCH] MIPS: Work around LLVM bug when gp is used as global register variable
Date: Tue, 3 Feb 2026 04:03:58 +0000 [thread overview]
Message-ID: <aYFzrjOV91rBUEB4@pie> (raw)
In-Reply-To: <20260202232309.GA1070900@ax162>
On Mon, Feb 02, 2026 at 04:23:09PM -0700, Nathan Chancellor wrote:
> On Sun, Jan 18, 2026 at 09:02:35AM +0000, Yao Zi wrote:
> > On MIPS, __current_thread_info is defined as global register variable
> > locating in $gp, and is simply assigned with new address during kernel
> > relocation.
> >
> > This however is broken with LLVM, which always restores $gp if it finds
> > $gp is clobbered in any form, including when intentionally through a
> > global register variable. This is against GCC's documentation[1], which
> > requires a callee-saved register used as global register variable not to
> > be restored if it's clobbered.
> >
> > As a result, $gp will continue to point to the unrelocated kernel after
> > the epilog of relocate_kernel(), leading to an early crash in init_idle,
> >
> > [ 0.000000] CPU 0 Unable to handle kernel paging request at virtual address 0000000000000000, epc == ffffffff81afada8, ra == ffffffff81afad90
> > [ 0.000000] Oops[#1]:
> > [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Tainted: G W 6.19.0-rc5-00262-gd3eeb99bbc99-dirty #188 VOLUNTARY
> > [ 0.000000] Tainted: [W]=WARN
> > [ 0.000000] Hardware name: loongson,loongson64v-4core-virtio
> > [ 0.000000] $ 0 : 0000000000000000 0000000000000000 0000000000000001 0000000000000000
> > [ 0.000000] $ 4 : ffffffff80b80ec0 ffffffff80b53d48 0000000000000000 00000000000f4240
> > [ 0.000000] $ 8 : 0000000000000100 ffffffff81d82f80 ffffffff81d82f80 0000000000000001
> > [ 0.000000] $12 : 0000000000000000 ffffffff81776f58 00000000000005da 0000000000000002
> > [ 0.000000] $16 : ffffffff80b80e40 0000000000000000 ffffffff80b81614 9800000005dfbe80
> > [ 0.000000] $20 : 00000000540000e0 ffffffff81980000 0000000000000000 ffffffff80f81c80
> > [ 0.000000] $24 : 0000000000000a26 ffffffff8114fb90
> > [ 0.000000] $28 : ffffffff80b50000 ffffffff80b53d40 0000000000000000 ffffffff81afad90
> > [ 0.000000] Hi : 0000000000000000
> > [ 0.000000] Lo : 0000000000000000
> > [ 0.000000] epc : ffffffff81afada8 init_idle+0x130/0x270
> > [ 0.000000] ra : ffffffff81afad90 init_idle+0x118/0x270
> > [ 0.000000] Status: 540000e2 KX SX UX KERNEL EXL
> > [ 0.000000] Cause : 00000008 (ExcCode 02)
> > [ 0.000000] BadVA : 0000000000000000
> > [ 0.000000] PrId : 00006305 (ICT Loongson-3)
> > [ 0.000000] Process swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____), tls=0000000000000000)
> > [ 0.000000] Stack : 9800000005dfbf00 ffffffff8178e950 0000000000000000 0000000000000000
> > [ 0.000000] 0000000000000000 ffffffff81970000 000000000000003f ffffffff810a6528
> > [ 0.000000] 0000000000000001 9800000005dfbe80 9800000005dfbf00 ffffffff81980000
> > [ 0.000000] ffffffff810a6450 ffffffff81afb6c0 0000000000000000 ffffffff810a2258
> > [ 0.000000] ffffffff81d82ec8 ffffffff8198d010 ffffffff81b67e80 ffffffff8197dd98
> > [ 0.000000] ffffffff81d81c80 ffffffff81930000 0000000000000040 0000000000000000
> > [ 0.000000] 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > [ 0.000000] 0000000000000000 000000000000009e ffffffff9fc01000 0000000000000000
> > [ 0.000000] 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > [ 0.000000] 0000000000000000 ffffffff81ae86dc ffffffff81b3c741 0000000000000002
> > [ 0.000000] ...
> > [ 0.000000] Call Trace:
> > [ 0.000000] [<ffffffff81afada8>] init_idle+0x130/0x270
> > [ 0.000000] [<ffffffff81afb6c0>] sched_init+0x5c8/0x6c0
> > [ 0.000000] [<ffffffff81ae86dc>] start_kernel+0x27c/0x7a8
> >
> > This bug has been reported to LLVM[2] and affects version from (at
> > least) 18 to 21. Let's work around this by using inline assembly to
> > assign $gp before a fix is widely available.
> >
> > Cc: stable@vger.kernel.org
> > Link: https://gcc.gnu.org/onlinedocs/gcc-15.2.0/gcc/Global-Register-Variables.html # [1]
> > Link: https://github.com/llvm/llvm-project/issues/176546 # [2]
> > Signed-off-by: Yao Zi <me@ziyao.cc>
>
> Acked-by: Nathan Chancellor <nathan@kernel.org>
>
> Hopefully the MIPS LLVM folks can look into this (even though I think
> the MIPS backend is one of the less maintained backends in LLVM).
Sigh...
> > ---
> > arch/mips/kernel/relocate.c | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/arch/mips/kernel/relocate.c b/arch/mips/kernel/relocate.c
> > index 7f1c136ad850..12aa0bbdd65e 100644
> > --- a/arch/mips/kernel/relocate.c
> > +++ b/arch/mips/kernel/relocate.c
> > @@ -420,7 +420,18 @@ void *__init relocate_kernel(void)
> > goto out;
> >
> > /* The current thread is now within the relocated image */
> > +#ifndef CONFIG_CC_IS_CLANG
>
> I find
>
> #ifdef FOO
> <FOO block>
> #else
> <!FOO block>
> #endif
>
> to be easier to read and process
>
> #ifndef FOO
> <!FOO block>
> #else
> <FOO block>
> #endif
>
> but maybe that it is just personal preference.
I preferred to put Clang's workaround later, since
> > __current_thread_info = RELOCATED(&init_thread_union);
this simple assignment is easier to read and more clear than the inline
assembly, and matching the comment
/* The current thread is now within the relocated image */
better. But yes, this is basically a personal preference, and I'm happy
with both. Please tell me if you do prefer the other.
> > +#else
> > + /*
> > + * LLVM may wrongly restore $gp ($28) in epilog even if it's
> > + * intentionally modified. Work around this by using inline
> > + * assembly to assign $gp. $gp couldn't be listed as output or
> > + * clobber, or LLVM will still restore its original value.
>
> This comment should likely include a link to the LLVM upstream report to
> make it easier to version restrict this workaround when fixed in the
> future.
Sure, will do it in v2. Thanks for the feedback!
Best regards,
Yao Zi
prev parent reply other threads:[~2026-02-03 4:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-18 9:02 [PATCH] MIPS: Work around LLVM bug when gp is used as global register variable Yao Zi
2026-02-02 15:07 ` Yao Zi
2026-02-02 23:23 ` Nathan Chancellor
2026-02-03 4:03 ` Yao Zi [this message]
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=aYFzrjOV91rBUEB4@pie \
--to=me@ziyao.cc \
--cc=justinstitt@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=nick.desaulniers+lkml@gmail.com \
--cc=stable@vger.kernel.org \
--cc=thomas.weissschuh@linutronix.de \
--cc=tsbogend@alpha.franken.de \
/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.