06 Feb, 2015

5 commits

  • commit dcad68876c21bac709b01eda24e39d4410dc36a8 upstream.

    Since commit f2c3c67f00 (merge commit that adds commit "ARM: mvebu:
    completely disable hardware I/O coherency"), we disable I/O coherency
    on Armada EBU platforms.

    However, we continue to initialize the coherency fabric, because this
    coherency fabric is needed on Armada XP for inter-CPU
    coherency. Unfortunately, due to this, we also continued to execute
    the coherency fabric initialization code for Armada 375/38x, which
    switched the PL310 into I/O coherent mode. This has the effect of
    disabling the outer cache sync operation: this is needed when I/O
    coherency is enabled to work around a PCIe/L2 deadlock. But obviously,
    when I/O coherency is disabled, having the outer cache sync operation
    is crucial.

    Therefore, this commit fixes the armada_375_380_coherency_init() so
    that the PL310 is switched to I/O coherent mode only if I/O coherency
    is enabled.

    Without this fix, all devices using DMA are broken on Armada 375/38x.

    Signed-off-by: Thomas Petazzoni
    Acked-by: Gregory CLEMENT
    Tested-by: Gregory CLEMENT
    Signed-off-by: Andrew Lunn
    Signed-off-by: Greg Kroah-Hartman

    Thomas Petazzoni
     
  • commit e6eb2eba494d6f99e69ca3c3748cd37a2544ab38 upstream.

    The commit 3b8a3c010969 ("powerpc/pseries: Fix endiannes issue in RTAS
    call from xmon") was fixing an endianness issue in the call made from
    xmon to RTAS.

    However, as Michael Ellerman noticed, this fix was not complete, the
    token value was not byte swapped. This lead to call an unexpected and
    most of the time unexisting RTAS function, which is silently ignored by
    RTAS.

    This fix addresses this hole.

    Reported-by: Michael Ellerman
    Signed-off-by: Laurent Dufour
    Signed-off-by: Michael Ellerman
    Signed-off-by: Greg Kroah-Hartman

    Laurent Dufour
     
  • commit e262eb9381ad51b5de7a9e762ee773bbd25ce650 upstream.

    Fix misspelled define.

    Fixes: 33692f27597f ("vm: add VM_FAULT_SIGSEGV handling support")
    Signed-off-by: Guenter Roeck
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    Guenter Roeck
     
  • commit 33692f27597fcab536d7cbbcc8f52905133e4aa7 upstream.

    The core VM already knows about VM_FAULT_SIGBUS, but cannot return a
    "you should SIGSEGV" error, because the SIGSEGV case was generally
    handled by the caller - usually the architecture fault handler.

    That results in lots of duplication - all the architecture fault
    handlers end up doing very similar "look up vma, check permissions, do
    retries etc" - but it generally works. However, there are cases where
    the VM actually wants to SIGSEGV, and applications _expect_ SIGSEGV.

    In particular, when accessing the stack guard page, libsigsegv expects a
    SIGSEGV. And it usually got one, because the stack growth is handled by
    that duplicated architecture fault handler.

    However, when the generic VM layer started propagating the error return
    from the stack expansion in commit fee7e49d4514 ("mm: propagate error
    from stack expansion even for guard page"), that now exposed the
    existing VM_FAULT_SIGBUS result to user space. And user space really
    expected SIGSEGV, not SIGBUS.

    To fix that case, we need to add a VM_FAULT_SIGSEGV, and teach all those
    duplicate architecture fault handlers about it. They all already have
    the code to handle SIGSEGV, so it's about just tying that new return
    value to the existing code, but it's all a bit annoying.

    This is the mindless minimal patch to do this. A more extensive patch
    would be to try to gather up the mostly shared fault handling logic into
    one generic helper routine, and long-term we really should do that
    cleanup.

    Just from this patch, you can generally see that most architectures just
    copied (directly or indirectly) the old x86 way of doing things, but in
    the meantime that original x86 model has been improved to hold the VM
    semaphore for shorter times etc and to handle VM_FAULT_RETRY and other
    "newer" things, so it would be a good idea to bring all those
    improvements to the generic case and teach other architectures about
    them too.

    Reported-and-tested-by: Takashi Iwai
    Tested-by: Jan Engelhardt
    Acked-by: Heiko Carstens # "s390 still compiles and boots"
    Cc: linux-arch@vger.kernel.org
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    Linus Torvalds
     
  • commit d69911a68c865b152a067feaa45e98e6bb0f655b upstream.

    Commit e6023367d779 ("x86, kaslr: Prevent .bss from overlaping initrd")
    added Perl to the required build environment. This reimplements in
    shell the Perl script used to find the size of the kernel with bss and
    brk added.

    Signed-off-by: Kees Cook
    Reported-by: Rob Landley
    Acked-by: Rob Landley
    Cc: Anca Emanuel
    Cc: Fengguang Wu
    Cc: Junjie Mao
    Cc: Kees Cook
    Cc: Thomas Gleixner
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    Kees Cook
     

30 Jan, 2015

15 commits

  • commit 3e14dcf7cb80b34a1f38b55bc96f02d23fdaaaaf upstream.

    Commit 5d26a105b5a7 ("crypto: prefix module autoloading with "crypto-"")
    changed the automatic module loading when requesting crypto algorithms
    to prefix all module requests with "crypto-". This requires all crypto
    modules to have a crypto specific module alias even if their file name
    would otherwise match the requested crypto algorithm.

    Even though commit 5d26a105b5a7 added those aliases for a vast amount of
    modules, it was missing a few. Add the required MODULE_ALIAS_CRYPTO
    annotations to those files to make them get loaded automatically, again.
    This fixes, e.g., requesting 'ecb(blowfish-generic)', which used to work
    with kernels v3.18 and below.

    Also change MODULE_ALIAS() lines to MODULE_ALIAS_CRYPTO(). The former
    won't work for crypto modules any more.

    Fixes: 5d26a105b5a7 ("crypto: prefix module autoloading with "crypto-"")
    Cc: Kees Cook
    Signed-off-by: Mathias Krause
    Signed-off-by: Herbert Xu
    Signed-off-by: Greg Kroah-Hartman

    Mathias Krause
     
  • commit 4943ba16bbc2db05115707b3ff7b4874e9e3c560 upstream.

    This adds the module loading prefix "crypto-" to the template lookup
    as well.

    For example, attempting to load 'vfat(blowfish)' via AF_ALG now correctly
    includes the "crypto-" prefix at every level, correctly rejecting "vfat":

    net-pf-38
    algif-hash
    crypto-vfat(blowfish)
    crypto-vfat(blowfish)-all
    crypto-vfat

    Reported-by: Mathias Krause
    Signed-off-by: Kees Cook
    Acked-by: Mathias Krause
    Signed-off-by: Herbert Xu
    Signed-off-by: Greg Kroah-Hartman

    Kees Cook
     
  • commit 5d26a105b5a73e5635eae0629b42fa0a90e07b7b upstream.

    This prefixes all crypto module loading with "crypto-" so we never run
    the risk of exposing module auto-loading to userspace via a crypto API,
    as demonstrated by Mathias Krause:

    https://lkml.org/lkml/2013/3/4/70

    Signed-off-by: Kees Cook
    Signed-off-by: Herbert Xu
    Signed-off-by: Greg Kroah-Hartman

    Kees Cook
     
  • commit 38a1dfda8e77d7ba74c94d06d8bc41ba98a4bc8c upstream.

    Commit 0dbc6078c06bc0 ('x86, build, pci: Fix PCI_MSI build on !SMP')
    introduced the dependency that X86_UP_APIC is only available when
    PCI_MSI is false. This effectively prevents PCI_MSI support on 32bit
    UP systems because it disables both APIC and IO-APIC. But APIC support
    is architecturally required for PCI_MSI.

    The intention of the patch was to enforce APIC support when PCI_MSI is
    enabled, but failed to do so.

    Remove the !PCI_MSI dependency from X86_UP_APIC and enforce
    X86_UP_APIC when PCI_MSI support is enabled on 32bit UP systems.

    [ tglx: Massaged changelog ]

    Fixes 0dbc6078c06bc0 'x86, build, pci: Fix PCI_MSI build on !SMP'
    Signed-off-by: Bryan O'Donoghue
    Suggested-by: Thomas Gleixner
    Reviewed-by: Andy Shevchenko
    Cc: Thomas Petazzoni
    Link: http://lkml.kernel.org/r/1421967529-9037-1-git-send-email-pure.logic@nexus-software.ie
    Signed-off-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Bryan O'Donoghue
     
  • commit 3669ef9fa7d35f573ec9c0e0341b29251c2734a7 upstream.

    The Witcher 2 did something like this to allocate a TLS segment index:

    struct user_desc u_info;
    bzero(&u_info, sizeof(u_info));
    u_info.entry_number = (uint32_t)-1;

    syscall(SYS_set_thread_area, &u_info);

    Strictly speaking, this code was never correct. It should have set
    read_exec_only and seg_not_present to 1 to indicate that it wanted
    to find a free slot without putting anything there, or it should
    have put something sensible in the TLS slot if it wanted to allocate
    a TLS entry for real. The actual effect of this code was to
    allocate a bogus segment that could be used to exploit espfix.

    The set_thread_area hardening patches changed the behavior, causing
    set_thread_area to return -EINVAL and crashing the game.

    This changes set_thread_area to interpret this as a request to find
    a free slot and to leave it empty, which isn't *quite* what the game
    expects but should be close enough to keep it working. In
    particular, using the code above to allocate two segments will
    allocate the same segment both times.

    According to FrostbittenKing on Github, this fixes The Witcher 2.

    If this somehow still causes problems, we could instead allocate
    a limit==0 32-bit data segment, but that seems rather ugly to me.

    Fixes: 41bdc78544b8 x86/tls: Validate TLS entries to protect espfix
    Signed-off-by: Andy Lutomirski
    Cc: torvalds@linux-foundation.org
    Link: http://lkml.kernel.org/r/0cb251abe1ff0958b8e468a9a9a905b80ae3a746.1421954363.git.luto@amacapital.net
    Signed-off-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Andy Lutomirski
     
  • commit e30ab185c490e9a9381385529e0fd32f0a399495 upstream.

    32-bit programs don't have an lm bit in their ABI, so they can't
    reliably cause LDT_empty to return true without resorting to memset.
    They shouldn't need to do this.

    This should fix a longstanding, if minor, issue in all 64-bit kernels
    as well as a potential regression in the TLS hardening code.

    Fixes: 41bdc78544b8 x86/tls: Validate TLS entries to protect espfix
    Signed-off-by: Andy Lutomirski
    Cc: torvalds@linux-foundation.org
    Link: http://lkml.kernel.org/r/72a059de55e86ad5e2935c80aa91880ddf19d07c.1421954363.git.luto@amacapital.net
    Signed-off-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Andy Lutomirski
     
  • commit 63ea0a49ae0b145b91ff2b070c01b66fc75854b9 upstream.

    STR and SLDT with rip-relative operand can cause a host kernel oops.
    Mark them as DstMem as well.

    Signed-off-by: Nadav Amit
    Signed-off-by: Paolo Bonzini
    Signed-off-by: Greg Kroah-Hartman

    Nadav Amit
     
  • commit f3747379accba8e95d70cec0eae0582c8c182050 upstream.

    SYSENTER emulation is broken in several ways:
    1. It misses the case of 16-bit code segments completely (CVE-2015-0239).
    2. MSR_IA32_SYSENTER_CS is checked in 64-bit mode incorrectly (bits 0 and 1 can
    still be set without causing #GP).
    3. MSR_IA32_SYSENTER_EIP and MSR_IA32_SYSENTER_ESP are not masked in
    legacy-mode.
    4. There is some unneeded code.

    Fix it.

    Signed-off-by: Nadav Amit
    Signed-off-by: Paolo Bonzini
    Signed-off-by: Greg Kroah-Hartman

    Nadav Amit
     
  • commit f285f4a21c3253887caceed493089ece17579d59 upstream.

    On 64-bit, relocation is not required unless the load address gets
    changed. Without this, relocations do unexpected things when the kernel
    is above 4G.

    Reported-by: Baoquan He
    Signed-off-by: Kees Cook
    Tested-by: Thomas D.
    Cc: Vivek Goyal
    Cc: Jan Beulich
    Cc: Junjie Mao
    Cc: Andi Kleen
    Link: http://lkml.kernel.org/r/20150116005146.GA4212@www.outflux.net
    Signed-off-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Kees Cook
     
  • commit 520452172e6b318f3a8bd9d4fe1e25066393de25 upstream.

    Many users see this message when booting without knowning that it is
    of no importance and that TSC calibration may have succeeded by
    another way.

    As explained by Paul Bolle in
    http://lkml.kernel.org/r/1348488259.1436.22.camel@x61.thuisdomein

    "Fast TSC calibration failed" should not be considered as an error
    since other calibration methods are being tried afterward. At most,
    those send a warning if they fail (not an error). So let's change
    the message from error to warning.

    [ tglx: Make if pr_info. It's really not important at all ]

    Fixes: c767a54ba065 x86/debug: Add KERN_ to bare printks, convert printks to pr_
    Signed-off-by: Alexandre Demers
    Link: http://lkml.kernel.org/r/1418106470-6906-1-git-send-email-alexandre.f.demers@gmail.com
    Signed-off-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Alexandre Demers
     
  • commit 32c6590d126836a062b3140ed52d898507987017 upstream.

    The Hyper-V clocksource is continuous; mark it accordingly.

    Signed-off-by: K. Y. Srinivasan
    Acked-by: jasowang@redhat.com
    Cc: gregkh@linuxfoundation.org
    Cc: devel@linuxdriverproject.org
    Cc: olaf@aepfle.de
    Cc: apw@canonical.com
    Link: http://lkml.kernel.org/r/1421108762-3331-1-git-send-email-kys@microsoft.com
    Signed-off-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    K. Y. Srinivasan
     
  • commit 4a0d3107d6b19125f21172c2b7d95f9c30ecaf6f upstream.

    The mis-naming likely was a copy-and-paste effect.

    Signed-off-by: Jan Beulich
    Link: http://lkml.kernel.org/r/54B9408B0200007800055E8B@mail.emea.novell.com
    Signed-off-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Jan Beulich
     
  • commit 8f1e8ee28660018a935c7576b9af8ffe1feab54c upstream.

    The current hardware I/O coherency is known to cause problems with DMA
    coherent buffers, as it still requires explicit I/O synchronization
    barriers, which is not compatible with the semantics expected by the
    Linux DMA coherent buffers API.

    So, in order to have enough time to validate a new solution based on
    automatic I/O synchronization barriers, this commit disables hardware
    I/O coherency entirely. Future patches will re-enable it.

    Signed-off-by: Thomas Petazzoni
    Signed-off-by: Andrew Lunn
    Signed-off-by: Greg Kroah-Hartman

    Thomas Petazzoni
     
  • commit 7ecd0bde5bfea524a843ad8fa8cb66ccbce68779 upstream.

    Currently PWM functionality is broken on mx25 due to the wrong assignment of the
    PWM "per" clock.

    According to Documentation/devicetree/bindings/clock/imx25-clock.txt:
    pwm_ipg_per 52

    ,so update the pwm "per" to use 'pwm_ipg_per' instead of 'per10' clock.

    With this change PWM can work fine on mx25.

    Reported-by: Carlos Soto
    Signed-off-by: Fabio Estevam
    Signed-off-by: Shawn Guo
    Signed-off-by: Greg Kroah-Hartman

    Fabio Estevam
     
  • commit 851b09369255a91e77f56d83e3643439ac5b209a upstream.

    Every PCI-PCI bridge window should fit inside an upstream bridge window
    because orphaned address space is unreachable from the primary side of the
    upstream bridge. If we inherit invalid bridge windows that overlap an
    upstream window from firmware, clip them to fit and update the bridge
    accordingly.

    [bhelgaas: changelog]
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
    Reported-by: Marek Kordik
    Tested-by: Marek Kordik
    Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
    Signed-off-by: Yinghai Lu
    Signed-off-by: Bjorn Helgaas
    CC: Thomas Gleixner
    CC: Ingo Molnar
    CC: "H. Peter Anvin"
    CC: x86@kernel.org
    Signed-off-by: Greg Kroah-Hartman

    Yinghai Lu
     

28 Jan, 2015

20 commits

  • commit 78051e3b7e35722ad3f31dd611f1b34770bddab8 upstream.

    If L0 has disabled EPT, don't advertise unrestricted
    mode at all since it depends on EPT to run real mode code.

    Fixes: 92fbc7b195b824e201d9f06f2b93105f72384d65
    Reviewed-by: Jan Kiszka
    Signed-off-by: Bandan Das
    Signed-off-by: Paolo Bonzini
    Signed-off-by: Greg Kroah-Hartman

    Bandan Das
     
  • commit b485342bd79af363c77ef1a421c4a0aef2de9812 upstream.

    Commit a074335a370e ("x86, um: Mark system call tables readonly") was
    supposed to mark the sys_call_table in UML as RO by adding the const,
    but it doesn't have the desired effect as it's nevertheless being placed
    into the data section since __cacheline_aligned enforces sys_call_table
    being placed into .data..cacheline_aligned instead. We need to use
    the ____cacheline_aligned version instead to fix this issue.

    Before:

    $ nm -v arch/x86/um/sys_call_table_64.o | grep -1 "sys_call_table"
    U sys_writev
    0000000000000000 D sys_call_table
    0000000000000000 D syscall_table_size

    After:

    $ nm -v arch/x86/um/sys_call_table_64.o | grep -1 "sys_call_table"
    U sys_writev
    0000000000000000 R sys_call_table
    0000000000000000 D syscall_table_size

    Fixes: a074335a370e ("x86, um: Mark system call tables readonly")
    Cc: H. Peter Anvin
    Cc: Andrew Morton
    Signed-off-by: Daniel Borkmann
    Signed-off-by: Richard Weinberger
    Signed-off-by: Greg Kroah-Hartman

    Daniel Borkmann
     
  • commit f911d731054ab3d82ee72a16b889e17ca3a2332a upstream.

    futex_atomic_cmpxchg_inatomic() does not work on UML because
    it triggers a copy_from_user() in kernel context.
    On UML copy_from_user() can only be used if the kernel was called
    by a real user space process such that UML can use ptrace()
    to fetch the value.

    Reported-by: Miklos Szeredi
    Suggested-by: Geert Uytterhoeven
    Signed-off-by: Richard Weinberger
    Tested-by: Daniel Walter
    Signed-off-by: Greg Kroah-Hartman

    Richard Weinberger
     
  • commit 69d2626f97b7f017ee4416b7dc071e9499c2c944 upstream.

    64KiB is allocated for qspi dtb partition which is not
    sufficient, so updating the partition table size to 512KiB
    for device tree partition.

    This also aligns the QSPI partition definitions between
    kernel and U-Boot.

    Fixes: dc2dd5b8 ("ARM: dts: dra7: Add qspi device")

    Signed-off-by: Mugunthan V N
    Signed-off-by: Tony Lindgren
    Signed-off-by: Greg Kroah-Hartman

    Mugunthan V N
     
  • commit b0ddb319db3d7a1943445f0de0a45c07a7f3457a upstream.

    The sh73a0 INTC can't mask interrupts properly most likely due to a
    hardware bug. Set the .control_parent flag to delegate masking to the
    parent interrupt controller, like was already done for irqpin1.

    Without this, accessing the three-axis digital accelerometer ADXL345
    on kzm9g through /dev/input/event1 causes an interrupt storm, which
    requires a power-cycle to recover from.

    This was inspired by a patch for arch/arm/boot/dts/sh73a0.dtsi from
    Laurent Pinchart .

    Signed-off-by: Geert Uytterhoeven
    Fixes: 341eb5465f67437a ("ARM: shmobile: INTC External IRQ pin driver on sh73a0")
    Signed-off-by: Simon Horman
    Signed-off-by: Greg Kroah-Hartman

    Geert Uytterhoeven
     
  • commit 5adba7c2daaecccf377e7ed5a2996caedd5384f1 upstream.

    There's no card detection for the eMMC, so this patch adds the missing
    broken-cd property. This patch also sets bus width as 8 to add
    MMC_CAP_8_BIT_DATA in the Host capabilities.

    Fixes: 3047086dfd56 ("ARM: dts: berlin: enable SD card reader and eMMC for the BG2Q DMP")
    Signed-off-by: Jisheng Zhang
    Signed-off-by: Sebastian Hesselbarth
    Signed-off-by: Greg Kroah-Hartman

    Jisheng Zhang
     
  • commit 999f934de195a1506089b52c77429fdba25da688 upstream.

    If the boot loader enables HYP mode on the boot CPU, the secondary CPU
    also needs to call into the ROM to switch to HYP mode before booting.
    The firmwares on the omap5 and dra7xx unfortunately do not take care
    of this, so it has to be handled by the kernel.

    This patch is based on "[PATCH 2/2] ARM: OMAP5: Add HYP mode entry support
    for secondary CPUs" by Santosh Shilimkar ,
    except this version does not require a compile time CONFIG to control
    if it should enable HYP mode or not, it simply does it based on the mode
    of the boot CPU, so it works whether the CPU boots in SVC or HYP mode,
    and should even work as a guest kernel inside kvm if qemu decides to
    support emulating the omap5 or dra7xx.

    Signed-off-by: Len Sorensen
    Signed-off-by: Tony Lindgren
    Signed-off-by: Greg Kroah-Hartman

    Lennart Sorensen
     
  • commit 572b24e6d85d98cdc552f07e9fb9870d9460d81b upstream.

    The switch statement of the possible list of SYSCLK1 frequencies is
    missing a 0 in 4 out of the 7 frequencies.

    Fixes: fa6d79d27614 ("ARM: OMAP: Add initialisation for the real-time counter")
    Signed-off-by: Len Sorensen
    Reviewed-by: Lokesh Vutla
    Acked-by: Nishanth Menon
    Signed-off-by: Tony Lindgren
    Signed-off-by: Greg Kroah-Hartman

    Lennart Sorensen
     
  • commit 81ef447950bf0955aca46f4a7617d8ce435cf0ce upstream.

    The post dividers do not work on i.MX6Q rev T0 1.0 so they must be fixed
    to 1. As the table index was wrong, a divider a of 4 could still be
    requested which implied the clock not to be set properly. This is the
    root cause of the HDMI not working at high resolution on rev T0 1.0 of
    the SoC.

    Signed-off-by: Gary Bisson
    Cc:
    Signed-off-by: Shawn Guo
    Signed-off-by: Greg Kroah-Hartman

    Gary Bisson
     
  • commit d2a10a1727b3948019128e83162f22c65859f1fd upstream.

    Drop unnecessary semicolon after closing curly bracket.

    Signed-off-by: Dmitry Voytik
    Signed-off-by: Shawn Guo
    Signed-off-by: Greg Kroah-Hartman

    Dmitry Voytik
     
  • commit 7a9f0604bd56936b2b18f49824e0e392dc7878c3 upstream.

    GPIO2_5 is the reset GPIO for the USB3317 ULPI PHY. Instead of modelling it as
    a regulator, the correct approach is to use the 'reset_gpios' property of the
    "usb-nop-xceiv" node.

    GPIO1_7 is the reset GPIO for the USB2517 USB hub. As we currently don't have
    dt bindings to describe a HUB reset, let's keep using the regulator approach.

    Rename the regulator to 'reg_hub_reset' to better describe its function and bind
    it with the USB host1 port instead.

    USB host support has been introduced by commit 9bf206a9d13be3 ("ARM: dts:
    imx51-babbage: Add USB Host1 support"), which landed in 3.16 and it seems that
    USB has only been functional due to previous bootloader initialization.

    With this patch applied we can get USB host to work without relying on the
    bootloader.

    Signed-off-by: Fabio Estevam
    Signed-off-by: Shawn Guo
    Signed-off-by: Greg Kroah-Hartman

    Fabio Estevam
     
  • commit 7a87e9cbc3a2f0ff0955815335e08c9862359130 upstream.

    From Documentation/devicetree/bindings/clock/imx25-clock.txt:

    cspi1_ipg 78
    cspi2_ipg 79
    cspi3_ipg 80

    , so fix the SPI1 clocks accordingly to avoid a kernel hang when trying to
    access SPI1.

    Signed-off-by: Fabio Estevam
    Signed-off-by: Shawn Guo
    Signed-off-by: Greg Kroah-Hartman

    Fabio Estevam
     
  • commit 7c168ed898931f6c3314d696e63cf993378ca192 upstream.

    The default qspi2_clk_sel field of register CCM_CS2CDR contains '110' which is
    marked as 'reserved', so we can't rely on the default value.

    Provide a proper parent for QSPI clocks to avoid a kernel oops:

    [ 1.037920] Division by zero in kernel.
    [ 1.041807] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.0-rc7-next-20141204-00002-g5aa23e1 #2143
    [ 1.050967] Hardware name: Freescale i.MX6 SoloX (Device Tree)
    [ 1.056853] Backtrace:
    [ 1.059360] [] (dump_backtrace) from [] (show_stack+0x18/0x1c)
    [ 1.066982] r6:00000000 r5:00000000 r4:00000000 r3:00000000
    [ 1.072754] [] (show_stack) from [] (dump_stack+0x88/0xa4)
    [ 1.080038] [] (dump_stack) from [] (__div0+0x18/0x20)
    [ 1.086958] r5:be018500 r4:be017c00
    [ 1.090600] [] (__div0) from [] (Ldiv0+0x8/0x10)
    [ 1.097012] [] (clk_divider_set_rate) from [] (clk_change_rate+0x14c/0x17c)
    [ 1.105759] r7:00000000 r6:00000000 r5:be018500 r4:00000000
    [ 1.111516] [] (clk_change_rate) from [] (clk_set_rate+0x94/0x98)
    [ 1.119391] r8:be7e0368 r7:00000000 r6:be11a000 r5:be018500 r4:00000000 r3:00000000
    [ 1.127290] [] (clk_set_rate) from [] (fsl_qspi_probe+0x23c/0x75c)
    [ 1.135260] r5:be11a010 r4:be350010
    [ 1.138900] [] (fsl_qspi_probe) from [] (platform_drv_probe+0x50/0xac)

    Signed-off-by: Fabio Estevam
    Signed-off-by: Shawn Guo
    Signed-off-by: Greg Kroah-Hartman

    Fabio Estevam
     
  • commit 40d1746d2eeec5e05956d749cca6364573b472b6 upstream.

    CONFIG_GENERIC_CPUFREQ_CPU0 disappeared with commit bbcf071969b20f
    ("cpufreq: cpu0: rename driver and internals to 'cpufreq_dt'")

    Use the renamed CONFIG_CPUFREQ_DT generic driver. It looks like with
    v3.18-rc1, commit bbcf071969b20f and fdc509b15eb3eb came in via
    different trees causing the resultant v3.18-rc1 to be non-functional for
    cpufreq as default supported with omap2plus_defconfig.

    Fixes: fdc509b15eb3eb ("ARM: omap2plus_defconfig: Add cpufreq to defconfig")
    Signed-off-by: Nishanth Menon
    Acked-by: Viresh Kumar
    Signed-off-by: Tony Lindgren
    Signed-off-by: Greg Kroah-Hartman

    Nishanth Menon
     
  • commit 5138d5c562e3bfe30964e20ab46eec9f8b89225d upstream.

    The gpio4 and gpio5 are in 0xf7fc0000 apb which is located in the SM domain.
    This patch moves gpio4 and gpio5 to the correct location. This patch also
    renames them as the following to match the names we internally used in
    marvell:
    gpio4 -> sm_gpio1
    gpio5 -> sm_gpio0
    porte -> portf
    portf -> porte

    This also matches what we did for BG2 and BG2CD's SM GPIO.

    Fixes: cedf57fc4f2f ("ARM: dts: berlin: add the BG2Q GPIO nodes")
    Signed-off-by: Jisheng Zhang
    Signed-off-by: Sebastian Hesselbarth
    Signed-off-by: Greg Kroah-Hartman

    Jisheng Zhang
     
  • commit 237d28db036e411f22c03cfd5b0f6dc2aa9bf3bc upstream.

    If the function graph tracer traces a jprobe callback, the system will
    crash. This can easily be demonstrated by compiling the jprobe
    sample module that is in the kernel tree, loading it and running the
    function graph tracer.

    # modprobe jprobe_example.ko
    # echo function_graph > /sys/kernel/debug/tracing/current_tracer
    # ls

    The first two commands end up in a nice crash after the first fork.
    (do_fork has a jprobe attached to it, so "ls" just triggers that fork)

    The problem is caused by the jprobe_return() that all jprobe callbacks
    must end with. The way jprobes works is that the function a jprobe
    is attached to has a breakpoint placed at the start of it (or it uses
    ftrace if fentry is supported). The breakpoint handler (or ftrace callback)
    will copy the stack frame and change the ip address to return to the
    jprobe handler instead of the function. The jprobe handler must end
    with jprobe_return() which swaps the stack and does an int3 (breakpoint).
    This breakpoint handler will then put back the saved stack frame,
    simulate the instruction at the beginning of the function it added
    a breakpoint to, and then continue on.

    For function tracing to work, it hijakes the return address from the
    stack frame, and replaces it with a hook function that will trace
    the end of the call. This hook function will restore the return
    address of the function call.

    If the function tracer traces the jprobe handler, the hook function
    for that handler will not be called, and its saved return address
    will be used for the next function. This will result in a kernel crash.

    To solve this, pause function tracing before the jprobe handler is called
    and unpause it before it returns back to the function it probed.

    Some other updates:

    Used a variable "saved_sp" to hold kcb->jprobe_saved_sp. This makes the
    code look a bit cleaner and easier to understand (various tries to fix
    this bug required this change).

    Note, if fentry is being used, jprobes will change the ip address before
    the function graph tracer runs and it will not be able to trace the
    function that the jprobe is probing.

    Link: http://lkml.kernel.org/r/20150114154329.552437962@goodmis.org

    Acked-by: Masami Hiramatsu
    Signed-off-by: Steven Rostedt
    Signed-off-by: Greg Kroah-Hartman

    Steven Rostedt (Red Hat)
     
  • commit 0145058c3d30b4319d747f64caa16a9cb15f0581 upstream.

    This patch partially reverts commit 421520ba98290a73b35b7644e877a48f18e06004
    (only the arm64 part). There is no guarantee that the boot-loader places other
    images like dtb in a different page than initrd start/end, especially when the
    kernel is built with 64KB pages. When this happens, such pages must not be
    freed. The free_reserved_area() already takes care of rounding up "start" and
    rounding down "end" to avoid freeing partially used pages.

    Reported-by: Peter Maydell
    Signed-off-by: Catalin Marinas
    Signed-off-by: Will Deacon
    Signed-off-by: Greg Kroah-Hartman

    Catalin Marinas
     
  • commit bfe5fda8e7ced129716f5741cf7ed2592a338824 upstream.

    Patch c49f63530bb6 ("powernv: Add OPAL tracepoints") has a spurious
    store to the stack:

    ld r12,opal_tracepoint_refcount@toc(r2); \
    std r12,32(r1); \

    The store was originally used to save the current tracepoint status
    so the entry and the exit tracepoints were always balanced. In the
    end I just created a separate path when tracepoints are enabled.

    The offset on the stack used for this store is not valid for ABIv2
    and it causes strange issues. I noticed it because OPAL console input
    was broken.

    Fixes: c49f63530bb6 ("powernv: Add OPAL tracepoints")
    Signed-off-by: Anton Blanchard
    Signed-off-by: Michael Ellerman
    Signed-off-by: Greg Kroah-Hartman

    Anton Blanchard
     
  • commit 280dbc572357eb50184663fc9e4aaf09c8141e9b upstream.

    Commit 9def39be4e96 ("x86: Support compiling out human-friendly
    processor feature names") made two source file targets
    conditional. Such conditional targets will not be cleaned
    automatically by make mrproper.

    Fix by adding explicit clean-files targets for the two files.

    Fixes: 9def39be4e96 ("x86: Support compiling out human-friendly processor feature names")
    Signed-off-by: Bjørn Mork
    Cc: Josh Triplett
    Link: http://lkml.kernel.org/r/1419335863-10608-1-git-send-email-bjorn@mork.no
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Bjørn Mork
     
  • commit 45db07382a5c78b0c43b3b0002b63757fb60e873 upstream.

    The __ldcw macro has a problem when its argument needs to be reloaded from
    memory. The output memory operand and the input register operand both need to
    be reloaded using a register in class R1_REGS when generating 64-bit code.
    This fails because there's only a single register in the class. Instead, use a
    memory clobber. This also makes the __ldcw macro a compiler memory barrier.

    Signed-off-by: John David Anglin
    Signed-off-by: Helge Deller
    Signed-off-by: Greg Kroah-Hartman

    John David Anglin