linux-stable.git/arch, branch v3.18.52

MIPS: elf2ecoff: Fix warning due to dead code.

2017-05-08T05:44:12+00:00

commit 2d76e9633b572ae5a64150b638eed77f4afc12db upstream.

  HOSTCC  arch/mips/boot/elf2ecoff
arch/mips/boot/elf2ecoff.c: In function ‘main’:
arch/mips/boot/elf2ecoff.c:271:8: warning: variable ‘shstrtab’ set but not used [-Wunused-but-set-variable]
  char *shstrtab;

Signed-off-by: Ralf Baechle 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

MIPS: elf2ecoff: Ignore PT_MIPS_ABIFLAGS program headers.

2017-05-08T05:44:12+00:00

commit 26f7c4bd05cf34e63a4a794150ab66a40a5a84a9 upstream.

These are generated by very recent toolchains and result in an error
message when attenpting to convert a kernel from ELF to ECOFF.

Signed-off-by: Ralf Baechle 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

MIPS: jz4740: fix build error in irq.h

2017-05-08T05:44:12+00:00

kernelci found build error on the 3.18 stable tree that don't
show up in later versions:

arch/mips/jz4740/irq.h:21:38: error: 'struct irq_data' declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
arch/mips/jz4740/irq.h:20:39: error: 'struct irq_data' declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
include/linux/irqdesc.h:92:33: error: 'NR_IRQS' undeclared here (not in a function)
arch/mips/jz4740/irq.c:91:41: error: 'JZ4740_IRQ_BASE' undeclared (first use in this function)
arch/mips/jz4740/irq.c:68:6: error: conflicting types for 'jz4740_irq_resume'
arch/mips/jz4740/irq.c:62:6: error: conflicting types for 'jz4740_irq_suspend'
arch/mips/jz4740/irq.c:49:39: error: 'JZ4740_IRQ_BASE' undeclared (first use in this function)
arch/mips/jz4740/gpio.c:47:32: error: initializer element is not constant
arch/mips/jz4740/gpio.c:46:32: error: initializer element is not constant
arch/mips/jz4740/gpio.c:45:32: error: initializer element is not constant
arch/mips/jz4740/gpio.c:44:32: error: initializer element is not constant
arch/mips/jz4740/gpio.c:447:22: error: assignment from incompatible pointer type [-Werror=incompatible-pointer-types]
arch/mips/jz4740/gpio.c:446:23: error: assignment from incompatible pointer type [-Werror=incompatible-pointer-types]
arch/mips/jz4740/gpio.c:427:14: error: implicit declaration of function 'JZ4740_IRQ_INTC_GPIO' [-Werror=implicit-function-declaration]
arch/mips/jz4740/gpio.c:269:9: error: implicit declaration of function 'JZ4740_IRQ_GPIO' [-Werror=implicit-function-declaration]

The problem seems to be caused by commit 83bc76920080 ("MIPS: JZ4740: Use
generic irq chip") from linux-3.2, but only showed up in a defconfig
build when qi_lb60_defconfig was added in linux-3.13 and that configuration
never successfully built.

The code has changed in a number of ways before 4.4, which builds fine.
While I did not bisect the problem to a specific change, I found a simple
fix by including the obviously missing header.

Cc: Lars-Peter Clausen 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

arm64: build vdso without libgcov

2017-05-08T05:44:12+00:00

commit 543097843ca7c9ac3758d0b5879ea2a6f44089de upstream.

On a cross-toolchain without glibc support, libgcov may not be
available, and attempting to build an arm64 kernel with GCOV
enabled then results in a build error:

/home/arnd/cross-gcc/lib/gcc/aarch64-linux/5.2.1/../../../../aarch64-linux/bin/ld: cannot find -lgcov

We don't really want to link libgcov into the vdso anyway, so
this patch just disables GCOV in the vdso directory, just as
we do for most other architectures.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Catalin Marinas 
Signed-off-by: Greg Kroah-Hartman

arm64: Provide a namespace to NCAPS

2017-05-08T05:44:11+00:00

commit 06f9eb884be81431d54d7d37390043e3b5b7f14a upstream.

Building arm64.allmodconfig leads to the following warning:

usb/gadget/function/f_ncm.c:203:0: warning: "NCAPS" redefined
 #define NCAPS (USB_CDC_NCM_NCAP_ETH_FILTER | USB_CDC_NCM_NCAP_CRC_MODE)
 ^
In file included from /home/build/work/batch/arch/arm64/include/asm/io.h:32:0,
                 from /home/build/work/batch/include/linux/clocksource.h:19,
                 from /home/build/work/batch/include/clocksource/arm_arch_timer.h:19,
                 from /home/build/work/batch/arch/arm64/include/asm/arch_timer.h:27,
                 from /home/build/work/batch/arch/arm64/include/asm/timex.h:19,
                 from /home/build/work/batch/include/linux/timex.h:65,
                 from /home/build/work/batch/include/linux/sched.h:19,
                 from /home/build/work/batch/arch/arm64/include/asm/compat.h:25,
                 from /home/build/work/batch/arch/arm64/include/asm/stat.h:23,
                 from /home/build/work/batch/include/linux/stat.h:5,
                 from /home/build/work/batch/include/linux/module.h:10,
                 from /home/build/work/batch/drivers/usb/gadget/function/f_ncm.c:19:
arch/arm64/include/asm/cpufeature.h:27:0: note: this is the location of the previous definition
 #define NCAPS     2

So add a ARM64 prefix to avoid such problem.

Reported-by: Olof's autobuilder 
Signed-off-by: Fabio Estevam 
Signed-off-by: Will Deacon 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

ARM: cns3xxx: shut up frame size warning

2017-05-08T05:44:11+00:00

This shuts up a warning in the 3.18-stable series that has been fixed
in newer kernels with commit 498a92d42596 ("ARM: cns3xxx: pci: avoid
potential stack overflow"):

arch/arm/mach-cns3xxx/pcie.c: In function 'cns3xxx_pcie_hw_init':
arch/arm/mach-cns3xxx/pcie.c:313:1: error: the frame size of 1080 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]

The fix that went into v4.4 is known to be buggy and was later
fixed again with commit 88e9da9a2a70 ("CNS3xxx: Fix PCI
cns3xxx_write_config()"). While we could backport both to 3.18,
they are fairly invasive and the warning is definitely harmless
here as the call chain is known to not overflow the stack of the
init task.

This simply adds a Makefile flag to extend the limit for this one
file.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

powerpc/ptrace: Fix out of bounds array access warning

2017-05-08T05:44:09+00:00

commit 1e407ee3b21f981140491d5b8a36422979ca246f upstream.

gcc-6 correctly warns about a out of bounds access

arch/powerpc/kernel/ptrace.c:407:24: warning: index 32 denotes an offset greater than size of 'u64[32][1] {aka long long unsigned int[32][1]}' [-Warray-bounds]
        offsetof(struct thread_fp_state, fpr[32][0]));
                        ^

check the end of array instead of beginning of next element to fix this

Signed-off-by: Khem Raj 
Cc: Kees Cook 
Cc: Michael Ellerman 
Cc: Segher Boessenkool 
Tested-by: Aaro Koskinen 
Acked-by: Olof Johansson 
Cc: Arnd Bergmann 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

ftrace/x86: Fix triple fault with graph tracing and suspend-to-ram

2017-05-08T05:44:09+00:00

commit 34a477e5297cbaa6ecc6e17c042a866e1cbe80d6 upstream.

On x86-32, with CONFIG_FIRMWARE and multiple CPUs, if you enable function
graph tracing and then suspend to RAM, it will triple fault and reboot when
it resumes.

The first fault happens when booting a secondary CPU:

startup_32_smp()
  load_ucode_ap()
    prepare_ftrace_return()
      ftrace_graph_is_dead()
        (accesses 'kill_ftrace_graph')

The early head_32.S code calls into load_ucode_ap(), which has an an
ftrace hook, so it calls prepare_ftrace_return(), which calls
ftrace_graph_is_dead(), which tries to access the global
'kill_ftrace_graph' variable with a virtual address, causing a fault
because the CPU is still in real mode.

The fix is to add a check in prepare_ftrace_return() to make sure it's
running in protected mode before continuing.  The check makes sure the
stack pointer is a virtual kernel address.  It's a bit of a hack, but
it's not very intrusive and it works well enough.

For reference, here are a few other (more difficult) ways this could
have potentially been fixed:

- Move startup_32_smp()'s call to load_ucode_ap() down to *after* paging
  is enabled.  (No idea what that would break.)

- Track down load_ucode_ap()'s entire callee tree and mark all the
  functions 'notrace'.  (Probably not realistic.)

- Pause graph tracing in ftrace_suspend_notifier_call() or bringup_cpu()
  or __cpu_up(), and ensure that the pause facility can be queried from
  real mode.

Reported-by: Paul Menzel 
Signed-off-by: Josh Poimboeuf 
Tested-by: Paul Menzel 
Reviewed-by: Steven Rostedt (VMware) 
Cc: "Rafael J . Wysocki" 
Cc: linux-acpi@vger.kernel.org
Cc: Borislav Petkov 
Cc: Len Brown 
Link: http://lkml.kernel.org/r/5c1272269a580660703ed2eccf44308e790c7a98.1492123841.git.jpoimboe@redhat.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

MIPS: KGDB: Use kernel context for sleeping threads

2017-05-08T05:44:09+00:00

commit 162b270c664dca2e0944308e92f9fcc887151a72 upstream.

KGDB is a kernel debug stub and it can't be used to debug userland as it
can only safely access kernel memory.

On MIPS however KGDB has always got the register state of sleeping
processes from the userland register context at the beginning of the
kernel stack. This is meaningless for kernel threads (which never enter
userland), and for user threads it prevents the user seeing what it is
doing while in the kernel:

(gdb) info threads
  Id   Target Id         Frame
  ...
  3    Thread 2 (kthreadd) 0x0000000000000000 in ?? ()
  2    Thread 1 (init)   0x000000007705c4b4 in ?? ()
  1    Thread -2 (shadowCPU0) 0xffffffff8012524c in arch_kgdb_breakpoint () at arch/mips/kernel/kgdb.c:201

Get the register state instead from the (partial) kernel register
context stored in the task's thread_struct for resume() to restore. All
threads now correctly appear to be in context_switch():

(gdb) info threads
  Id   Target Id         Frame
  ...
  3    Thread 2 (kthreadd) context_switch (rq=, cookie=..., next=, prev=0x0) at kernel/sched/core.c:2903
  2    Thread 1 (init)   context_switch (rq=, cookie=..., next=, prev=0x0) at kernel/sched/core.c:2903
  1    Thread -2 (shadowCPU0) 0xffffffff8012524c in arch_kgdb_breakpoint () at arch/mips/kernel/kgdb.c:201

Call clobbered registers which aren't saved and exception registers
(BadVAddr & Cause) which can't be easily determined without stack
unwinding are reported as 0. The PC is taken from the return address,
such that the state presented matches that found immediately after
returning from resume().

Fixes: 8854700115ec ("[MIPS] kgdb: add arch support for the kernel's kgdb core")
Signed-off-by: James Hogan 
Cc: Jason Wessel 
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/15829/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman

sparc64: Fix kernel panic due to erroneous #ifdef surrounding pmd_write()

2017-05-08T05:44:08+00:00

[ Upstream commit 9ae34dbd8afd790cb5f52467e4f816434379eafa ]

This commit moves sparc64's prototype of pmd_write() outside
of the CONFIG_TRANSPARENT_HUGEPAGE ifdef.

In 2013, commit a7b9403f0e6d ("sparc64: Encode huge PMDs using PTE
encoding.") exposed a path where pmd_write() could be called without
CONFIG_TRANSPARENT_HUGEPAGE defined.  This can result in the panic below.

The diff is awkward to read, but the changes are straightforward.
pmd_write() was moved outside of #ifdef CONFIG_TRANSPARENT_HUGEPAGE.
Also, __HAVE_ARCH_PMD_WRITE was defined.

kernel BUG at include/asm-generic/pgtable.h:576!
              \|/ ____ \|/
              "@'/ .. \`@"
              /_| \__/ |_\
                 \__U_/
oracle_8114_cdb(8114): Kernel bad sw trap 5 [#1]
CPU: 120 PID: 8114 Comm: oracle_8114_cdb Not tainted
4.1.12-61.7.1.el6uek.rc1.sparc64 #1
task: fff8400700a24d60 ti: fff8400700bc4000 task.ti: fff8400700bc4000
TSTATE: 0000004411e01607 TPC: 00000000004609f8 TNPC: 00000000004609fc Y:
00000005    Not tainted
TPC: 
g0: 000000000001c000 g1: 0000000000ef3954 g2: 0000000000000000 g3: 0000000000000001
g4: fff8400700a24d60 g5: fff8001fa5c10000 g6: fff8400700bc4000 g7: 0000000000000720
o0: 0000000000bc5058 o1: 0000000000000240 o2: 0000000000006000 o3: 0000000000001c00
o4: 0000000000000000 o5: 0000048000080000 sp: fff8400700bc6ab1 ret_pc: 00000000004609f0
RPC: 
l0: fff8400700bc74fc l1: 0000000000020000 l2: 0000000000002000 l3: 0000000000000000
l4: fff8001f93250950 l5: 000000000113f800 l6: 0000000000000004 l7: 0000000000000000
i0: fff8400700ca46a0 i1: bd0000085e800453 i2: 000000026a0c4000 i3: 000000026a0c6000
i4: 0000000000000001 i5: fff800070c958de8 i6: fff8400700bc6b61 i7: 0000000000460dd0
I7: 
Call Trace:
 [0000000000460dd0] gup_pud_range+0x170/0x1a0
 [0000000000460e84] get_user_pages_fast+0x84/0x120
 [00000000006f5a18] iov_iter_get_pages+0x98/0x240
 [00000000005fa744] do_direct_IO+0xf64/0x1e00
 [00000000005fbbc0] __blockdev_direct_IO+0x360/0x15a0
 [00000000101f74fc] ext4_ind_direct_IO+0xdc/0x400 [ext4]
 [00000000101af690] ext4_ext_direct_IO+0x1d0/0x2c0 [ext4]
 [00000000101af86c] ext4_direct_IO+0xec/0x220 [ext4]
 [0000000000553bd4] generic_file_read_iter+0x114/0x140
 [00000000005bdc2c] __vfs_read+0xac/0x100
 [00000000005bf254] vfs_read+0x54/0x100
 [00000000005bf368] SyS_pread64+0x68/0x80

Signed-off-by: Tom Hromatka 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman