All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Burton <paulburton@kernel.org>
To: Paul Burton <paulburton@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, Paul Burton <paulburton@kernel.org>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Christian Brauner <christian.brauner@canonical.com>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	stable@vger.kernel.org
Cc: linux-mips@vger.kernel.org
Subject: Re: [PATCH v2] MIPS: Avoid VDSO ABI breakage due to global register  variable
Date: Thu, 02 Jan 2020 16:42:38 -0800	[thread overview]
Message-ID: <5e0e8dff.1c69fb81.86508.5dbe@mx.google.com> (raw)
In-Reply-To: <20200102045038.102772-1-paulburton@kernel.org>

Hello,

Paul Burton wrote:
> 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.
> 
> One fix for this would be to move 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.
> Unfortunately this causes issues for clang, which doesn't support local
> register variables as pointed out by commit fe92da0f355e ("MIPS: Changed
> current_thread_info() to an equivalent supported by both clang and GCC")
> which introduced the global register variable before we had a VDSO to
> worry about.
> 
> Instead, fix this by continuing to use the global register variable for
> the kernel proper but declare __current_thread_info as a simple extern
> variable when building the VDSO. It should never be referenced, and will
> cause a link error if it is. This resolves the calling convention issue
> for the VDSO without having any impact upon the build of the kernel
> itself for either clang or gcc.

Applied to mips-fixes.

> commit bbcc5672b006
> https://git.kernel.org/mips/c/bbcc5672b006
> 
> Signed-off-by: Paul Burton <paulburton@kernel.org>
> Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
> Reported-by: Jason A. Donenfeld <Jason@zx2c4.com>
> Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
> Tested-by: Jason A. Donenfeld <Jason@zx2c4.com>

Thanks,
    Paul

[ This message was auto-generated; if you believe anything is incorrect
  then please email paulburton@kernel.org to report it. ]

      parent reply	other threads:[~2020-01-03  0:42 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-01 17:59 [PATCH] MIPS: Don't declare __current_thread_info globally Paul Burton
2020-01-01 20:51 ` Arnd Bergmann
2020-01-02  0:53   ` Arvind Sankar
2020-01-02  3:02     ` Nathan Chancellor
2020-01-02  4:50     ` [PATCH v2] MIPS: Avoid VDSO ABI breakage due to global register variable Paul Burton
2020-01-02 10:58       ` Jason A. Donenfeld
2020-01-02 16:56       ` Vincenzo Frascino
2020-01-03  0:42         ` Paul Burton
2020-01-03  9:15           ` Vincenzo Frascino
2020-01-03  0:42       ` Paul Burton [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=5e0e8dff.1c69fb81.86508.5dbe@mx.google.com \
    --to=paulburton@kernel.org \
    --cc=linux-mips@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.