[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 1 Jan 2020 21:51:02 +0100
From: Arnd Bergmann <arnd@...db.de>
To: Paul Burton <paulburton@...nel.org>
Cc: "open list:BROADCOM NVRAM DRIVER" <linux-mips@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Jason A. Donenfeld" <Jason@...c4.com>,
Christian Brauner <christian.brauner@...onical.com>,
Vincenzo Frascino <vincenzo.frascino@....com>,
"# 3.4.x" <stable@...r.kernel.org>
Subject: Re: [PATCH] MIPS: Don't declare __current_thread_info globally
On Wed, Jan 1, 2020 at 6:57 PM Paul Burton <paulburton@...nel.org> 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
Powered by blists - more mailing lists