MIPS: Don't declare __current_thread_info globally

Commit Message

Paul Burton Jan. 1, 2020, 5:59 p.m. UTC

Declaring __current_thread_info as a global register variable has the
effect of preventing GCC from saving & restoring its value in cases
where the ABI would typically do so.

To quote GCC documentation:

> If the register is a call-saved register, call ABI is affected: the
> register will not be restored in function epilogue sequences after the
> variable has been assigned. Therefore, functions cannot safely return
> to callers that assume standard ABI.

When our position independent VDSO is built for the n32 or n64 ABIs all
functions it exposes should be preserving the value of $gp/$28 for their
caller, but in the presence of the __current_thread_info global register
variable GCC stops doing so & simply clobbers $gp/$28 when calculating
the address of the GOT.

In cases where the VDSO returns success this problem will typically be
masked by the caller in libc returning & restoring $gp/$28 itself, but
that is by no means guaranteed. In cases where the VDSO returns an error
libc will typically contain a fallback path which will now fail
(typically with a bad memory access) if it attempts anything which
relies upon the value of $gp/$28 - eg. accessing anything via the GOT.

Fix this by moving the declaration of __current_thread_info inside the
current_thread_info() function, demoting it from global register
variable to local register variable & avoiding inadvertently creating a
non-standard calling ABI for the VDSO.

Signed-off-by: Paul Burton <[e-mail]>
Reported-by: "Jason A. Donenfeld" <[e-mail]>
Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
Cc: Arnd Bergmann <[e-mail]>
Cc: Christian Brauner <[e-mail]>
Cc: Vincenzo Frascino <[e-mail]>
Cc: <[e-mail]> # v4.4+
---
 arch/mips/include/asm/thread_info.h | 4 ++--
 arch/mips/kernel/relocate.c         | 1 +
 2 files changed, 3 insertions(+), 2 deletions(-)

Comments

Arnd Bergmann Jan. 1, 2020, 8:51 p.m. UTC | #1

On Wed, Jan 1, 2020 at 6:57 PM Paul Burton <[e-mail]> wrote:
> diff --git a/arch/mips/include/asm/thread_info.h b/arch/mips/include/asm/thread_info.h
> index 4993db40482c..aceefc3f9a1a 100644
> --- a/arch/mips/include/asm/thread_info.h
> +++ b/arch/mips/include/asm/thread_info.h
> @@ -50,10 +50,10 @@ struct thread_info {
>  }
>
>  /* How to get the thread information struct from C.  */
> -register struct thread_info *__current_thread_info __asm__("$28");
> -
>  static inline struct thread_info *current_thread_info(void)
>  {
> +       register struct thread_info *__current_thread_info __asm__("$28");
> +
>         return __current_thread_info;
>  }

This looks like a nice fix, but are you sure it doesn't allow the compiler to
reuse $28 for another purpose in the kernel under register pressure,
which would break current_thread_info()?

I see in the MIPS ABI document that $28 is preserved across function
calls, but I don't see any indication that a function is not allowed
to modify it and later restore the original content.

        Arnd

Arvind Sankar Jan. 2, 2020, 12:53 a.m. UTC | #2

On Wed, Jan 01, 2020 at 09:51:02PM +0100, Arnd Bergmann wrote:
> On Wed, Jan 1, 2020 at 6:57 PM Paul Burton <[e-mail]> wrote:
> > diff --git a/arch/mips/include/asm/thread_info.h b/arch/mips/include/asm/thread_info.h
> > index 4993db40482c..aceefc3f9a1a 100644
> > --- a/arch/mips/include/asm/thread_info.h
> > +++ b/arch/mips/include/asm/thread_info.h
> > @@ -50,10 +50,10 @@ struct thread_info {
> >  }
> >
> >  /* How to get the thread information struct from C.  */
> > -register struct thread_info *__current_thread_info __asm__("$28");
> > -
> >  static inline struct thread_info *current_thread_info(void)
> >  {
> > +       register struct thread_info *__current_thread_info __asm__("$28");
> > +
> >         return __current_thread_info;
> >  }
> 
> This looks like a nice fix, but are you sure it doesn't allow the compiler to
> reuse $28 for another purpose in the kernel under register pressure,
> which would break current_thread_info()?
> 
> I see in the MIPS ABI document that $28 is preserved across function
> calls, but I don't see any indication that a function is not allowed
> to modify it and later restore the original content.
> 
>         Arnd

The compiler can already do that even with a global definition.

The doc since gcc 9 [1] says:

"Accesses to the variable may be optimized as usual and the register
remains available for allocation and use in any computations, provided
that observable values of the variable are not affected."

and

"Furthermore, since the register is not reserved exclusively for the
variable, accessing it from handlers of asynchronous signals may observe
unrelated temporary values residing in the register."

I'm not sure if this was a change in gcc 9 or simply the doc was wrong
earlier.

Should there be a -ffixed-28 cflag for MIPS? alpha and hexagon seem to
have that and they also keep current_thread_info in a register.

Also, commit fe92da0f355e9 ("MIPS: Changed current_thread_info() to an
equivalent supported by both clang and GCC") moved this from local to
global because local apparently didn't work on clang?

[1] https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Global-Register-Variables.html

Nathan Chancellor Jan. 2, 2020, 3:02 a.m. UTC | #3

On Wed, Jan 01, 2020 at 07:53:45PM -0500, Arvind Sankar wrote:
> On Wed, Jan 01, 2020 at 09:51:02PM +0100, Arnd Bergmann wrote:
> > On Wed, Jan 1, 2020 at 6:57 PM Paul Burton <[e-mail]> wrote:
> > > diff --git a/arch/mips/include/asm/thread_info.h b/arch/mips/include/asm/thread_info.h
> > > index 4993db40482c..aceefc3f9a1a 100644
> > > --- a/arch/mips/include/asm/thread_info.h
> > > +++ b/arch/mips/include/asm/thread_info.h
> > > @@ -50,10 +50,10 @@ struct thread_info {
> > >  }
> > >
> > >  /* How to get the thread information struct from C.  */
> > > -register struct thread_info *__current_thread_info __asm__("$28");
> > > -
> > >  static inline struct thread_info *current_thread_info(void)
> > >  {
> > > +       register struct thread_info *__current_thread_info __asm__("$28");
> > > +
> > >         return __current_thread_info;
> > >  }
> > 
> > This looks like a nice fix, but are you sure it doesn't allow the compiler to
> > reuse $28 for another purpose in the kernel under register pressure,
> > which would break current_thread_info()?
> > 
> > I see in the MIPS ABI document that $28 is preserved across function
> > calls, but I don't see any indication that a function is not allowed
> > to modify it and later restore the original content.
> > 
> >         Arnd
> 
> The compiler can already do that even with a global definition.
> 
> The doc since gcc 9 [1] says:
> 
> "Accesses to the variable may be optimized as usual and the register
> remains available for allocation and use in any computations, provided
> that observable values of the variable are not affected."
> 
> and
> 
> "Furthermore, since the register is not reserved exclusively for the
> variable, accessing it from handlers of asynchronous signals may observe
> unrelated temporary values residing in the register."
> 
> I'm not sure if this was a change in gcc 9 or simply the doc was wrong
> earlier.
> 
> Should there be a -ffixed-28 cflag for MIPS? alpha and hexagon seem to
> have that and they also keep current_thread_info in a register.
> 
> Also, commit fe92da0f355e9 ("MIPS: Changed current_thread_info() to an
> equivalent supported by both clang and GCC") moved this from local to
> global because local apparently didn't work on clang?
> 
> [1] https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Global-Register-Variables.html

Yeah this patch appears to break booting malta_defconfig in QEMU when
built with clang; additionally, there are a TON of warnings about this
variable being uninitialized:

../arch/mips/include/asm/thread_info.h:57:9: warning: variable '__current_thread_info' is uninitialized when used here [-Wuninitialized]
        return __current_thread_info;
               ^~~~~~~~~~~~~~~~~~~~~
../arch/mips/include/asm/thread_info.h:55:52: note: initialize the variable '__current_thread_info' to silence this warning
        register struct thread_info *__current_thread_info __asm__("$28");
                                                          ^
                                                           = NULL
1 warning generated.

Seems like this is expected according to that previous commit? I
noticed there is another instance in arch/mips but it doesn't appear to
affect everything.

https://github.com/ClangBuiltLinux/linux/issues/606

Cheers,
Nathan

Patch

diff --git a/arch/mips/include/asm/thread_info.h b/arch/mips/include/asm/thread_info.h
index 4993db40482c..aceefc3f9a1a 100644
--- a/arch/mips/include/asm/thread_info.h
+++ b/arch/mips/include/asm/thread_info.h
@@ -50,10 +50,10 @@  struct thread_info {
 }
 
 /* How to get the thread information struct from C.  */
-register struct thread_info *__current_thread_info __asm__("$28");
-
 static inline struct thread_info *current_thread_info(void)
 {
+	register struct thread_info *__current_thread_info __asm__("$28");
+
 	return __current_thread_info;
 }
 
diff --git a/arch/mips/kernel/relocate.c b/arch/mips/kernel/relocate.c
index 3d80a51256de..c9afdc39b003 100644
--- a/arch/mips/kernel/relocate.c
+++ b/arch/mips/kernel/relocate.c
@@ -296,6 +296,7 @@  static inline int __init relocation_addr_valid(void *loc_new)
 
 void *__init relocate_kernel(void)
 {
+	register struct thread_info *__current_thread_info __asm__("$28");
 	void *loc_new;
 	unsigned long kernel_length;
 	unsigned long bss_length;