A collection of MIPS fixes:

- Fill the struct cacheinfo shared_cpu_map field with sensible values,
  notably avoiding issues with perf which was unhappy in the absence of
  these values.

- A boot fix for Loongson 2E & 2F machines which was fallout from some
  refactoring performed this cycle.

- A Kconfig dependency fix for the Loongson CPU HWMon driver.

- A couple of VDSO fixes, ensuring gettimeofday() behaves appropriately
  for kernel configurations that don't include support for a clocksource
  the VDSO can use & fixing the calling convention for the n32 & n64
  VDSOs which would previously clobber the $gp/$28 register.

- A build fix for vmlinuz compressed images which were inappropriately
  building with -fsanitize-coverage despite not being part of the kernel
  proper, then failing to link due to the missing
  __sanitizer_cov_trace_pc() function.

- A couple of eBPF JIT fixes, including disabling it for MIPS32 due to a
  large number of issues with the code generated there & reflecting ISA
  dependencies in Kconfig to enforce that systems which don't support
  the JIT must include the interpreter.

MIPS: Avoid VDSO ABI breakage due to global register variable

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.

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>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Christian Brauner <christian.brauner@canonical.com>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: <stable@vger.kernel.org> # v4.4+
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
1 file changed