1. 04 Oct, 2014 4 commits
  2. 30 Sep, 2014 3 commits
    • Jon Medhurst's avatar
      ARM: 8179/1: kprobes-test: Fix compile error "bad immediate value for offset" · ad684dce
      Jon Medhurst authored
      
      
      When compiling kprobes-test-arm.c the following error has been observed
      
      /tmp/ccoT403o.s:21439: Error: bad immediate value for offset (4168)
      
      This is caused by the compiler spilling it's literal pool too far away
      from the site which is trying to reference it with a PC relative load.
      This arises because the compiler is underestimating the size of the
      inline assembler code present, which apparently it approximates as 4
      bytes per line or instruction.
      
      We fix this problem by moving the operations which generate more than
      4 bytes out of the text section. Specifically, moving the .ascii
      directives to the .rodata section.
      Signed-off-by: default avatarJon Medhurst <tixy@linaro.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      ad684dce
    • Nathan Lynch's avatar
      ARM: 8178/1: fix set_tls for !CONFIG_KUSER_HELPERS · 9cc6d9e5
      Nathan Lynch authored
      Joachim Eastwood reports that commit fbfb872f "ARM: 8148/1: flush
      TLS and thumbee register state during exec" causes a boot-time crash
      on a Cortex-M4 nommu system:
      
      Freeing unused kernel memory: 68K (281e5000 - 281f6000)
      Unhandled exception: IPSR = 00000005 LR = fffffff1
      CPU: 0 PID: 1 Comm: swapper Not tainted 3.17.0-rc6-00313-gd2205fa30aa7 #191
      task: 29834000 ti: 29832000 task.ti: 29832000
      PC is at flush_thread+0x2e/0x40
      LR is at flush_thread+0x21/0x40
      pc : [<2800954a>] lr : [<2800953d>] psr: 4100000b
      sp : 29833d60 ip : 00000000 fp : 00000001
      r10: 00003cf8 r9 : 29b1f000 r8 : 00000000
      r7 : 29b0bc00 r6 : 29834000 r5 : 29832000 r4 : 29832000
      r3 : ffff0ff0 r2 : 29832000 r1 : 00000000 r0 : 282121f0
      xPSR: 4100000b
      CPU: 0 PID: 1 Comm: swapper Not tainted 3.17.0-rc6-00313-gd2205fa30aa7 #191
      [<2800afa5>] (unwind_backtrace) from [<2800a327>] (show_stack+0xb/0xc)
      [<2800a327>] (show_stack) from [<2800a963>] (__invalid_entry+0x4b/0x4c)
      
      The problem is that set_tls is attempting to clear the TLS location in
      the kernel-user helper page, which isn't set up on V7M.
      
      Fix this by guarding the write to the kuser helper page with
      a CONFIG_KUSER_HELPERS ifdef.
      
      Fixes: fbfb872f
      
       ARM: 8148/1: flush TLS and thumbee register state during exec
      Reported-by: default avatarJoachim Eastwood <manabian@gmail.com>
      Tested-by: default avatarJoachim Eastwood <manabian@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarNathan Lynch <nathan_lynch@mentor.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      9cc6d9e5
    • Krzysztof Kozlowski's avatar
      ARM: 8177/1: cacheflush: Fix v7_exit_coherency_flush exynos build breakage on ARMv6 · ebc77251
      Krzysztof Kozlowski authored
      
      
      This fixes build breakage of platsmp.c if ARMv6 was chosen for compile
      time options (e.g. by building allmodconfig):
      
      $ make allmodconfig
      $ make
        CC      arch/arm/mach-exynos/platsmp.o
      /tmp/ccdQM0Eg.s: Assembler messages:
      /tmp/ccdQM0Eg.s:432: Error: selected processor does not support ARM mode `isb '
      /tmp/ccdQM0Eg.s:437: Error: selected processor does not support ARM mode `isb '
      /tmp/ccdQM0Eg.s:438: Error: selected processor does not support ARM mode `dsb '
      make[1]: *** [arch/arm/mach-exynos/platsmp.o] Error 1
      
      The error was introduced in commit "ARM: EXYNOS: Move code from
      hotplug.c to platsmp.c".  Previously code using
      v7_exit_coherency_flush() macro was built with '-march=armv7-a' flag but
      this flag dissapeared during the movement.
      
      Fix this by annotating the v7_exit_coherency_flush() asm code with
      armv7-a architecture.
      Signed-off-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Reported-by: default avatarMark Brown <broonie@kernel.org>
      Acked-by: default avatarNicolas Pitre <nico@linaro.org>
      Signed-off-by: default avatarKukjin Kim <kgene.kim@samsung.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      ebc77251
  3. 26 Sep, 2014 2 commits
  4. 25 Sep, 2014 2 commits
  5. 24 Sep, 2014 14 commits
  6. 23 Sep, 2014 4 commits
    • Matt Fleming's avatar
      Revert "efi/x86: efistub: Move shared dependencies to <asm/efi.h>" · 84be8805
      Matt Fleming authored
      This reverts commit f23cf8bd ("efi/x86: efistub: Move shared
      dependencies to <asm/efi.h>") as well as the x86 parts of commit
      f4f75ad5 ("efi: efistub: Convert into static library").
      
      The road leading to these two reverts is long and winding.
      
      The above two commits were merged during the v3.17 merge window and
      turned the common EFI boot stub code into a static library. This
      necessitated making some symbols global in the x86 boot stub which
      introduced new entries into the early boot GOT.
      
      The problem was that we weren't fixing up the newly created GOT entries
      before invoking the EFI boot stub, which sometimes resulted in hangs or
      resets. This failure was reported by Maarten on his Macbook pro.
      
      The proposed fix was commit 9cb0e394 ("x86/efi: Fixup GOT in all
      boot code paths"). However, that caused issues for Linus when booting
      his Sony Vaio Pro 11. It was subsequently reverted in commit
      f3670394
      
      .
      
      So that leaves us back with Maarten's Macbook pro not booting.
      
      At this stage in the release cycle the least risky option is to revert
      the x86 EFI boot stub to the pre-merge window code structure where we
      explicitly #include efi-stub-helper.c instead of linking with the static
      library. The arm64 code remains unaffected.
      
      We can take another swing at the x86 parts for v3.18.
      
      Conflicts:
      	arch/x86/include/asm/efi.h
      Tested-by: default avatarJosh Boyer <jwboyer@fedoraproject.org>
      Tested-by: default avatarMaarten Lankhorst <maarten.lankhorst@canonical.com>
      Tested-by: Leif Lindholm <leif.lindholm@linaro.org> [arm64]
      Tested-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
      Cc: Ingo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      84be8805
    • John David Anglin's avatar
      parisc: Only use -mfast-indirect-calls option for 32-bit kernel builds · d26a7730
      John David Anglin authored
      
      
      In spite of what the GCC manual says, the -mfast-indirect-calls has
      never been supported in the 64-bit parisc compiler. Indirect calls have
      always been done using function descriptors irrespective of the
      -mfast-indirect-calls option.
      
      Recently, it was noticed that a function descriptor was always requested
      when the -mfast-indirect-calls option was specified. This caused
      problems when the option was used in  application code and doesn't make
      any sense because the whole point of the option is to avoid using a
      function descriptor for indirect calls.
      
      Fixing this broke 64-bit kernel builds.
      
      I will fix GCC but for now we need the attached change. This results in
      the same kernel code as before.
      Signed-off-by: default avatarJohn David Anglin <dave.anglin@bell.net>
      Cc: stable@vger.kernel.org  # v3.0+
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      d26a7730
    • Tony Luck's avatar
      [IA64] refresh arch/ia64/configs/* using "make savedefconfig" · e8ee39e2
      Tony Luck authored
      Prompted by a change to drivers/scsi/Kconfig which used to do a
      "select NET" but now does a "depends on NET". This meant that some
      configurations ended up without CONFIG_NET=y
      
      Signed-off-by Tony Luck <tony.luck@intel.com>
      e8ee39e2
    • Linus Torvalds's avatar
      Revert "x86/efi: Fixup GOT in all boot code paths" · f3670394
      Linus Torvalds authored
      This reverts commit 9cb0e394
      
      .
      
      It causes my Sony Vaio Pro 11 to immediately reboot at startup.
      Acked-by: default avatarIngo Molnar <mingo@kernel.org>
      Cc: Peter Anvin <hpa@zytor.com>
      Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Matt Fleming <matt.fleming@intel.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f3670394
  7. 22 Sep, 2014 1 commit
    • Shawn Guo's avatar
      ARM: imx: fix .is_enabled() of shared gate clock · 9e1ac462
      Shawn Guo authored
      Commit 63288b72
      
       ("ARM: imx: fix shared gate clock") attempted to fix
      an issue with particular enable/disable sequence from two shared gate
      clocks.  But unfortunately, while it partially fixed the issue, it also
      did something wrong in .is_enabled() function hook.  In case of shared
      gate, the function shouldn't really query the hardware state via
      share_count, because the function is trying to query the enabling state
      of the clock in question, not the hardware state which is shared by
      multiple clocks.
      
      Fix the issue by returning the enable_count of the clock itself which is
      maintained by clock core, in case it's a clock sharing hardware gate
      with others.  As the result, the initialization of share_count per
      hardware state is not needed now.  So remove it.
      Reported-by: default avatarFabio Estevam <fabio.estevam@freescale.com>
      Fixes: 63288b72
      
       ("ARM: imx: fix shared gate clock")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarShawn Guo <shawn.guo@freescale.com>
      Tested-by: default avatarFabio Estevam <fabio.estevam@freescale.com>
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      9e1ac462
  8. 21 Sep, 2014 1 commit
  9. 19 Sep, 2014 2 commits
    • Alexei Starovoitov's avatar
      sparc: bpf_jit: fix support for ldx/stx mem and SKF_AD_VLAN_TAG · f6f2332d
      Alexei Starovoitov authored
      fix several issues in sparc BPF JIT compiler.
      
      ldx/stx related:
      . classic BPF instructions that access mem[] slots were not setting
        SEEN_MEM flag, so stack wasn't allocated. Fix that by advertising
        correct flags
      
      . LDX/STX instructions were missing SEEN_XREG, so register value
        could have leaked to user space. Fix it.
      
      . since stack for mem[] slots is allocated with 'sub %sp' instead
        of 'save %sp', use %sp as base register instead of %fp.
      
      . ldx mem[0] means first slot in classic BPF which should have
        -4 offset instead of 0.
      
      . sparc64 needs 2047 stack bias as per ABI to access stack
      
      . emit_stmem() was using LD32I macro instead of ST32I
      
      SKF_AD_VLAN_TAG* related:
      . SKF_AD_VLAN_TAG_PRESENT must return 1 or 0 instead of '> 0' or 0
        as per classic BPF de facto standard
      
      . SKF_AD_VLAN_TAG needs to mask the field correctly
      
      Fixes: 2809a208
      
       ("net: filter: Just In Time compiler for sparc")
      Signed-off-by: default avatarAlexei Starovoitov <ast@plumgrid.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f6f2332d
    • Kees Cook's avatar
      x86/kaslr: Avoid the setup_data area when picking location · 0cacbfbe
      Kees Cook authored
      
      
      The KASLR location-choosing logic needs to avoid the setup_data
      list memory areas as well. Without this, it would be possible to
      have the ASLR position stomp on the memory, ultimately causing
      the boot to fail.
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Tested-by: default avatarBaoquan He <bhe@redhat.com>
      Cc: stable@vger.kernel.org
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/20140911161931.GA12001@www.outflux.net
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      0cacbfbe
  10. 17 Sep, 2014 1 commit
    • Markos Chandras's avatar
      MIPS: SmartMIPS: Disable assembler warnings · dab1b445
      Markos Chandras authored
      
      
      The kernel code overrides the default ISA as passed by the compiler
      in quite a few places. This has unfortunate side effects when smartmips
      is enabled leading to hundreds of warnings during build such as:
      
      {standard input}: Assembler messages:
      {standard input}:411: Warning: the `smartmips' extension requires MIPS32
      revision 1 or greater
      {standard input}: Assembler messages:
      {standard input}:43: Warning: the 64-bit MIPS architecture does not support the
      `smartmips' extension
      [...]
      
      Until the kernel code is fixed properly (if possible), disable all the
      assembler warning messages to make the build logs readable again.
      This has no runtime side effects but it makes it easier to spot
      more critical warnings and problems during build.
      Signed-off-by: default avatarMarkos Chandras <markos.chandras@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/7356/
      
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      dab1b445
  11. 16 Sep, 2014 5 commits
    • Tony Lindgren's avatar
      ARM: OMAP3: Fix I/O chain clock line assertion timed out error · 7db143b8
      Tony Lindgren authored
      We are getting "PRM: I/O chain clock line assertion timed out" errors
      on early omaps for device tree based booting. This is because we are
      unconditionally calling reconfigure_io_chain while legacy booting
      has omap3_has_io_chain_ctrl() checks in place in omap_hwmod.c.
      
      For device tree based booting, we are calling reconfigure_io_chain
      unconditionally from pinctrl framework. So we need to add a check for
      omap3_has_io_chain_ctrl() to avoid the errors for trying to access
      a register that does not exist.
      
      For es3.0, the documentation in "4.11.2 Device Off-Mode Configuration"
      just mentions PM_WKEN_WKUP[8] bit. For es3.1, there's a new chapter in
      documentation for "4.11.2.2 I/O Wake-Up Mechanism" that describes the
      PM_WKEN_WKUP[16] ST_IO_CHAIN bit. So PM_WKEN_WKUP[16] bit did not get
      added until in es3.1 probaly to fix issues with flakey wake-up events.
      
      We are doing proper checks for ST_IO_CHAIN already in id.c and with
      omap3_has_io_chain_ctrl(). For more information, see also commit
      b02b9172 ("ARM: OMAP3: PM: fix I/O wakeup and I/O chain clock
      control detection").
      
      Let's fix the issue by selecting the right function during init for
      reconfigure_io_chain depending on the omap revision. For es3.0 and
      earlier we need to just toggle EN_IO. By doing this, we can move the
      check for omap3_has_io_chain_ctrl() from omap_hwmod.c to the init code
      in prm_3xxx.c. And then we can unconditionally call reconfigure_io_chain.
      
      Thanks to Paul Walmsley and Nishanth Menon for help with debugging the
      issue.
      
      Fixes: 30a69ef7
      
       ("ARM: OMAP: Move DT wake-up event handling over to use pinctrl-single-omap")
      Cc: Kevin Hilman <khilman@kernel.org>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Tero Kristo <t-kristo@ti.com>
      Reviewed-by: default avatarNishanth Menon <nm@ti.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      7db143b8
    • Bruno Prémont's avatar
      vgaarb: Don't default exclusively to first video device with mem+io · 86fd887b
      Bruno Prémont authored
      Commit 20cde694 ("x86, ia64: Move EFI_FB vga_default_device()
      initialization to pci_vga_fixup()") moved boot video device detection from
      efifb to x86 and ia64 pci/fixup.c.
      
      For dual-GPU Apple computers above change represents a regression as code
      in efifb did forcefully override vga_default_device while the merge did not
      (vgaarb happens prior to PCI fixup).
      
      To improve on initial device selection by vgaarb (it cannot know if PCI
      device not behind bridges see/decode legacy VGA I/O or not), move the
      screen_info based check from pci_video_fixup() to vgaarb's init function and
      use it to refine/override decision taken while adding the individual PCI
      VGA devices.  This way PCI fixup has no reason to adjust vga_default_device
      anymore but can depend on its value for flagging shadowed VBIOS.
      
      This has the nice benefit of removing duplicated code but does introduce a
      #if defined() block in vgaarb.  Not all architectures have screen_info and
      would cause compile to fail without it.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=84461
      
      Reported-and-Tested-By: default avatarAndreas Noever <andreas.noever@gmail.com>
      Signed-off-by: default avatarBruno Prémont <bonbons@linux-vserver.org>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: Matthew Garrett <matthew.garrett@nebula.com>
      CC: stable@vger.kernel.org # v3.5+
      86fd887b
    • Stephen Boyd's avatar
      ARM: 8149/1: perf: Don't sleep while atomic when enabling per-cpu interrupts · 505013bc
      Stephen Boyd authored
      Rob Clark reports a sleeping while atomic bug when using perf.
      
      BUG: sleeping function called from invalid context at ../kernel/locking/mutex.c:583
      in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/0
      ------------[ cut here ]------------
      WARNING: CPU: 2 PID: 4828 at ../kernel/locking/mutex.c:479 mutex_lock_nested+0x3a0/0x3e8()
      DEBUG_LOCKS_WARN_ON(in_interrupt())
      Modules linked in:
      CPU: 2 PID: 4828 Comm: Xorg.bin Tainted: G        W      3.17.0-rc3-00234-gd535c45-dirty #819
      [<c0216690>] (unwind_backtrace) from [<c0212174>] (show_stack+0x10/0x14)
      [<c0212174>] (show_stack) from [<c0867cc0>] (dump_stack+0x98/0xb8)
      [<c0867cc0>] (dump_stack) from [<c02492a4>] (warn_slowpath_common+0x70/0x8c)
      [<c02492a4>] (warn_slowpath_common) from [<c02492f0>] (warn_slowpath_fmt+0x30/0x40)
      [<c02492f0>] (warn_slowpath_fmt) from [<c086a3f8>] (mutex_lock_nested+0x3a0/0x3e8)
      [<c086a3f8>] (mutex_lock_nested) from [<c0294d08>] (irq_find_host+0x20/0x9c)
      [<c0294d08>] (irq_find_host) from [<c0769d50>] (of_irq_get+0x28/0x48)
      [<c0769d50>] (of_irq_get) from [<c057d104>] (platform_get_irq+0x1c/0x8c)
      [<c057d104>] (platform_get_irq) from [<c021a06c>] (cpu_pmu_enable_percpu_irq+0x14/0x38)
      [<c021a06c>] (cpu_pmu_enable_percpu_irq) from [<c02b1634>] (flush_smp_call_function_queue+0x88/0x178)
      [<c02b1634>] (flush_smp_call_function_queue) from [<c0214dc0>] (handle_IPI+0x88/0x160)
      [<c0214dc0>] (handle_IPI) from [<c0208930>] (gic_handle_irq+0x64/0x68)
      [<c0208930>] (gic_handle_irq) from [<c0212d04>] (__irq_svc+0x44/0x5c)
      Exception stack(0xe63ddea0 to 0xe63ddee8)
      dea0: 00000001 00000001 00000000 c2f3b200 c16db380 c032d4a0 e63ddf40 60010013
      dec0: 00000000 001fbfd4 00000100 00000000 00000001 e63ddee8 c0284770 c02a2e30
      dee0: 20010013 ffffffff
      [<c0212d04>] (__irq_svc) from [<c02a2e30>] (ktime_get_ts64+0x1c8/0x200)
      [<c02a2e30>] (ktime_get_ts64) from [<c032d4a0>] (poll_select_set_timeout+0x60/0xa8)
      [<c032d4a0>] (poll_select_set_timeout) from [<c032df64>] (SyS_select+0xa8/0x118)
      [<c032df64>] (SyS_select) from [<c020e8e0>] (ret_fast_syscall+0x0/0x48)
      ---[ end trace 0bb583b46342da6f ]---
      INFO: lockdep is turned off.
      
      We don't really need to get the platform irq again when we're
      enabling or disabling the per-cpu irq. Furthermore, we don't
      really need to set and clear bits in the active_irqs bitmask
      because that's only used in the non-percpu irq case to figure out
      when the last CPU PMU has been disabled. Just pass the irq
      directly to the enable/disable functions to clean all this up.
      This should be slightly more efficient and also fix the
      scheduling while atomic bug.
      
      Fixes: bbd64559
      
       "ARM: perf: support percpu irqs for the CPU PMU"
      Reported-by: default avatarRob Clark <robdclark@gmail.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      505013bc
    • Nathan Lynch's avatar
      ARM: 8148/1: flush TLS and thumbee register state during exec · fbfb872f
      Nathan Lynch authored
      
      
      The TPIDRURO and TPIDRURW registers need to be flushed during exec;
      otherwise TLS information is potentially leaked.  TPIDRURO in
      particular needs careful treatment.  Since flush_thread basically
      needs the same code used to set the TLS in arm_syscall, pull that into
      a common set_tls helper in tls.h and use it in both places.
      
      Similarly, TEEHBR needs to be cleared during exec as well.  Clearing
      its save slot in thread_info isn't right as there is no guarantee
      that a thread switch will occur before the new program runs.  Just
      setting the register directly is sufficient.
      Signed-off-by: default avatarNathan Lynch <nathan_lynch@mentor.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      fbfb872f
    • Victor Kamensky's avatar
      ARM: 8151/1: add missing exports for asm functions required by get_user macro · 7a0bd497
      Victor Kamensky authored
      
      
      Previous commits that dealt with get_user for 64bit type missed to
      export proper functions, so if get_user macro with particular target/value
      types are used by kernel module modpost would produce 'undefined!' error.
      Solution is to export all required functions.
      Signed-off-by: default avatarVictor Kamensky <victor.kamensky@linaro.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      7a0bd497
  12. 15 Sep, 2014 1 commit