linux-toradex.git/arch, branch v4.4.136

sparc64: Fix build warnings with gcc 7.

2018-06-06T14:46:23+00:00

commit 0fde7ad71ee371ede73b3f326e58f9e8d102feb6 upstream.

arch/sparc/kernel/ds.c: In function ‘register_services’:
arch/sparc/kernel/ds.c:912:3: error: ‘strcpy’: writing at least 1 byte
into a region of size 0 overflows the destination

Reported-by: Anatoly Pugachev 
Signed-off-by: David S. Miller 
Cc: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman

MIPS: prctl: Disallow FRE without FR with PR_SET_FP_MODE requests

2018-06-06T14:46:23+00:00

commit 28e4213dd331e944e7fca1954a946829162ed9d4 upstream.

Having PR_FP_MODE_FRE (i.e. Config5.FRE) set without PR_FP_MODE_FR (i.e.
Status.FR) is not supported as the lone purpose of Config5.FRE is to
emulate Status.FR=0 handling on FPU hardware that has Status.FR=1
hardwired[1][2].  Also we do not handle this case elsewhere, and assume
throughout our code that TIF_HYBRID_FPREGS and TIF_32BIT_FPREGS cannot
be set both at once for a task, leading to inconsistent behaviour if
this does happen.

Return unsuccessfully then from prctl(2) PR_SET_FP_MODE calls requesting
PR_FP_MODE_FRE to be set with PR_FP_MODE_FR clear.  This corresponds to
modes allowed by `mips_set_personality_fp'.

References:

[1] "MIPS Architecture For Programmers, Vol. III: MIPS32 / microMIPS32
    Privileged Resource Architecture", Imagination Technologies,
    Document Number: MD00090, Revision 6.02, July 10, 2015, Table 9.69
    "Config5 Register Field Descriptions", p. 262

[2] "MIPS Architecture For Programmers, Volume III: MIPS64 / microMIPS64
    Privileged Resource Architecture", Imagination Technologies,
    Document Number: MD00091, Revision 6.03, December 22, 2015, Table
    9.72 "Config5 Register Field Descriptions", p. 288

Fixes: 9791554b45a2 ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS")
Signed-off-by: Maciej W. Rozycki 
Cc: Ralf Baechle 
Cc: linux-mips@linux-mips.org
Cc:  # 4.0+
Patchwork: https://patchwork.linux-mips.org/patch/19327/
Signed-off-by: James Hogan 
Signed-off-by: Greg Kroah-Hartman

MIPS: ptrace: Fix PTRACE_PEEKUSR requests for 64-bit FGRs

2018-06-06T14:46:22+00:00

commit c7e814628df65f424fe197dde73bfc67e4a244d7 upstream.

Use 64-bit accesses for 64-bit floating-point general registers with
PTRACE_PEEKUSR, removing the truncation of their upper halves in the
FR=1 mode, caused by commit bbd426f542cb ("MIPS: Simplify FP context
access"), which inadvertently switched them to using 32-bit accesses.

The PTRACE_POKEUSR side is fine as it's never been broken and continues
using 64-bit accesses.

Fixes: bbd426f542cb ("MIPS: Simplify FP context access")
Signed-off-by: Maciej W. Rozycki 
Cc: Ralf Baechle 
Cc: linux-mips@linux-mips.org
Cc:  # 3.15+
Patchwork: https://patchwork.linux-mips.org/patch/19334/
Signed-off-by: James Hogan 
Signed-off-by: Greg Kroah-Hartman

sh: New gcc support

2018-06-06T14:46:20+00:00

commit 940d4113f3306e07a1f86541489b686d1a979d54 upstream.

New gcc (4.8 or later) used new shift helper functions.
So we need added new helper to private libgcc.

Signed-off-by: Yoshinori Sato 
Signed-off-by: Rich Felker 
Cc: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman

powerpc/64s: Clear PCR on boot

2018-06-06T14:46:20+00:00

commit faf37c44a105f3608115785f17cbbf3500f8bc71 upstream.

Clear the PCR (Processor Compatibility Register) on boot to ensure we
are not running in a compatibility mode.

We've seen this cause problems when a crash (and kdump) occurs while
running compat mode guests. The kdump kernel then runs with the PCR
set and causes problems. The symptom in the kdump kernel (also seen in
petitboot after fast-reboot) is early userspace programs taking
sigills on newer instructions (seen in libc).

Signed-off-by: Michael Neuling 
Cc: stable@vger.kernel.org
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

arm64: lse: Add early clobbers to some input/output asm operands

2018-06-06T14:46:20+00:00

commit 32c3fa7cdf0c4a3eb8405fc3e13398de019e828b upstream.

For LSE atomics that read and write a register operand, we need to
ensure that these operands are annotated as "early clobber" if the
register is written before all of the input operands have been consumed.
Failure to do so can result in the compiler allocating the same register
to both operands, leading to splats such as:

 Unable to handle kernel paging request at virtual address 11111122222221
 [...]
 x1 : 1111111122222222 x0 : 1111111122222221
 Process swapper/0 (pid: 1, stack limit = 0x000000008209f908)
 Call trace:
  test_atomic64+0x1360/0x155c

where x0 has been allocated as both the value to be stored and also the
atomic_t pointer.

This patch adds the missing clobbers.

Cc: 
Cc: Dave Martin 
Cc: Robin Murphy 
Reported-by: Mark Salter 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

s390/ftrace: use expoline for indirect branches

2018-05-30T05:49:17+00:00

commit 23a4d7fd34856da8218c4cfc23dba7a6ec0a423a upstream.

The return from the ftrace_stub, _mcount, ftrace_caller and
return_to_handler functions is done with "br %r14" and "br %r1".
These are indirect branches as well and need to use execute
trampolines for CONFIG_EXPOLINE=y.

The ftrace_caller function is a special case as it returns to the
start of a function and may only use %r0 and %r1. For a pre z10
machine the standard execute trampoline uses a LARL + EX to do
this, but this requires *two* registers in the range %r1..%r15.
To get around this the 'br %r1' located in the lowcore is used,
then the EX instruction does not need an address register.
But the lowcore trick may only be used for pre z14 machines,
with noexec=on the mapping for the first page may not contain
instructions. The solution for that is an ALTERNATIVE in the
expoline THUNK generated by 'GEN_BR_THUNK %r1' to switch to
EXRL, this relies on the fact that a machine that supports
noexec=on has EXRL as well.

Cc: stable@vger.kernel.org # 4.16
Fixes: f19fbd5ed6 ("s390: introduce execute-trampolines for branches")
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Greg Kroah-Hartman

x86/apic: Set up through-local-APIC mode on the boot CPU if 'noapic' specified

2018-05-30T05:49:16+00:00

[ Upstream commit bee3204ec3c49f6f53add9c3962c9012a5c036fa ]

Currently the kdump kernel becomes very slow if 'noapic' is specified.
Normal kernel doesn't have this bug.

Kernel parameter 'noapic' is used to disable IO-APIC in system for
testing or special purpose. Here the root cause is that in kdump
kernel LAPIC is disabled since commit:

  522e664644 ("x86/apic: Disable I/O APIC before shutdown of the local APIC")

In this case we need set up through-local-APIC on boot CPU in
setup_local_APIC().

In normal kernel the legacy irq mode is enabled by the BIOS. If
it is virtual wire mode, the local-APIC has been enabled and set as
through-local-APIC.

Though we fixed the regression introduced by commit 522e664644,
to further improve robustness set up the through-local-APIC mode
explicitly, do not rely on the default boot IRQ mode.

Signed-off-by: Baoquan He 
Reviewed-by: Eric W. Biederman 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: douly.fnst@cn.fujitsu.com
Cc: joro@8bytes.org
Cc: prarit@redhat.com
Cc: uobergfe@redhat.com
Link: http://lkml.kernel.org/r/20180214054656.3780-7-bhe@redhat.com
[ Rewrote the changelog. ]
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

MIPS: Octeon: Fix logging messages with spurious periods after newlines

2018-05-30T05:49:16+00:00

[ Upstream commit db6775ca6e0353d2618ca7d5e210fc36ad43bbd4 ]

Using a period after a newline causes bad output.

Fixes: 64b139f97c01 ("MIPS: OCTEON: irq: add CIB and other fixes")
Signed-off-by: Joe Perches 
Cc: Ralf Baechle 
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/17886/
Signed-off-by: James Hogan 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

x86/devicetree: Fix device IRQ settings in DT

2018-05-30T05:49:13+00:00

[ Upstream commit 0a5169add90e43ab45ab1ba34223b8583fcaf675 ]

IRQ parameters for the SoC devices connected directly to I/O APIC lines
(without PCI IRQ routing) may be specified in the Device Tree.

Called from DT IRQ parser, irq_create_fwspec_mapping() calls
irq_domain_alloc_irqs() with a pointer to irq_fwspec structure as @arg.

But x86-specific DT IRQ allocation code casts @arg to of_phandle_args
structure pointer and crashes trying to read the IRQ parameters. The
function was not converted when the mapping descriptor was changed to
irq_fwspec in the generic irqdomain code.

Fixes: 11e4438ee330 ("irqdomain: Introduce a firmware-specific IRQ specifier structure")
Signed-off-by: Ivan Gorinov 
Signed-off-by: Thomas Gleixner 
Cc: Mark Rutland 
Cc: Rob Herring 
Link: https://lkml.kernel.org/r/a234dee27ea60ce76141872da0d6bdb378b2a9ee.1520450752.git.ivan.gorinov@intel.com
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman