1. 08 Nov, 2015 3 commits
  2. 03 Nov, 2015 4 commits
    • Max Filippov's avatar
      Revert "xtensa: cache inquiry and unaligned cache handling functions" · e2b31f75
      Max Filippov authored
      Drop unaligned dcache management functions as they are no longer used.
      This reverts commit bd974240 ("xtensa: cache inquiry and
      unaligned cache handling functions").
      Signed-off-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
      e2b31f75
    • Max Filippov's avatar
      xtensa: drop unused sections and remapped reset handlers · 0d848afe
      Max Filippov authored
      There are no .bootstrap or .ResetVector.text sections linked to the
      vmlinux image, drop these sections from vmlinux.ld.S. Drop
      RESET_VECTOR_VADDR definition only used for .ResetVector.text.
      
      Drop remapped copies of primary and secondary reset vectors, as modern
      gdb don't have problems stepping through instructions at arbitrary
      locations. Drop corresponding sections from the corresponding linker
      scripts.
      Signed-off-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
      0d848afe
    • Max Filippov's avatar
      xtensa: fix secondary core boot in SMP · ab45fb14
      Max Filippov authored
      There are multiple factors adding to the issue in different
      configurations:
      
      - commit 17290231 ("xtensa: add fixup for double exception raised
        in window overflow") added function window_overflow_restore_a0_fixup to
        double exception vector overlapping reset vector location of secondary
        processor cores.
      - on MMUv2 cores RESET_VECTOR1_VADDR may point to uncached kernel memory
        making code overlapping depend on cache type and size, so that without
        cache or with WT cache reset vector code overwrites double exception
        code, making issue even harder to detect.
      - on MMUv3 cores RESET_VECTOR1_VADDR may point to unmapped area, as
        MMUv3 cores change virtual address map to match MMUv2 layout, but
        reset vector virtual address is given for the original MMUv3 mapping.
      - physical memory region of the secondary reset vector is not reserved
        in the physical memory map, and thus may be allocated and overwritten
        at arbitrary moment.
      
      Fix it as follows:
      
      - move window_overflow_restore_a0_fixup code to .text section.
      - define RESET_VECTOR1_VADDR so that it points to reset vector in the
        cacheable MMUv2 map for cores with MMU.
      - reserve reset vector region in the physical memory map. Drop separate
        literal section and build mxhead.S with text section literals.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
      ab45fb14
    • Max Filippov's avatar
      xtensa: add FORCE_MAX_ZONEORDER to Kconfig · a9df9338
      Max Filippov authored
      Make maximal memory allocation order configurable, so that drivers could
      allocate huge buffers when they need to.
      Signed-off-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
      a9df9338
  3. 02 Nov, 2015 11 commits
  4. 01 Nov, 2015 7 commits
    • Linus Torvalds's avatar
      Merge branch 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm · 95fc00a4
      Linus Torvalds authored
      Pull memremap fix from Dan Williams:
       "The new memremap() api introduced in the 4.3 cycle to unify/replace
        ioremap_cache() and ioremap_wt() is mishandling the highmem case.
        This patch has received a build success notification from a
        0day-kbuild-robot run and has received an ack from Ard"
      
      From the commit message:
       "The impact of this bug is low for now since the pmem driver is the
        only user of memremap(), but this is important to fix before more
        conversions to memremap arrive in 4.4"
      
      * 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
        memremap: fix highmem support
      95fc00a4
    • Linus Torvalds's avatar
      Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · ca04d396
      Linus Torvalds authored
      Pull x86 fixes from Thomas Gleixner:
       "This set of updates contains:
      
         - Another bugfix for the pathologic vm86 machinery.  Clear
           thread.vm86 on fork to prevent corrupting the parent state.  This
           comes along with an update to the vm86 selftest case
      
         - Fix another corner case in the ioapic setup code which causes a
           boot crash on some oddball systems
      
         - Fix the fallout from the dma allocation consolidation work, which
           leads to a NULL pointer dereference when the allocation code is
           called with a NULL device"
      
      * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86/vm86: Set thread.vm86 to NULL on fork/clone
        selftests/x86: Add a fork() to entry_from_vm86 to catch fork bugs
        x86/ioapic: Prevent NULL pointer dereference in setup_ioapic_dest()
        x86/dma-mapping: Fix arch_dma_alloc_attrs() oops with NULL dev
      ca04d396
    • Linus Torvalds's avatar
      Merge branch 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · f5eab267
      Linus Torvalds authored
      Pull timer fixes from Thomas Gleixner:
       "The last round of minimalistic fixes for clocksource drivers:
      
         - Prevent multiple shutdown of the sh_mtu2 clocksource
      
         - Annotate a bunch of clocksource/schedclock functions with notrace
           to prevent an annoying ftrace recursion issue"
      
      * 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        clocksource/drivers/sh_mtu2: Fix multiple shutdown call issue
        clocksource/drivers/digicolor: Prevent ftrace recursion
        clocksource/drivers/fsl_ftm_timer: Prevent ftrace recursion
        clocksource/drivers/vf_pit_timer: Prevent ftrace recursion
        clocksource/drivers/prima2: Prevent ftrace recursion
        clocksource/drivers/samsung_pwm_timer: Prevent ftrace recursion
        clocksource/drivers/pistachio: Prevent ftrace recursion
        clocksource/drivers/arm_global_timer: Prevent ftrace recursion
      f5eab267
    • Linus Torvalds's avatar
      Merge branch 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 4bf690d7
      Linus Torvalds authored
      Pull irq fixes from Thomas Gleixner:
       "The last two one-liners for 4.3 from the irqchip space:
      
         - Regression fix for armada SoC which addresses the fallout from the
           set_irq_flags() cleanup
      
         - Add the missing propagation of the irq_set_type() callback to the
           parent interrupt controller of the tegra interrupt chip"
      
      * 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        irqchip/tegra: Propagate IRQ type setting to parent
        irqchip/armada-370-xp: Fix regression by clearing IRQ_NOAUTOEN
      4bf690d7
    • Linus Torvalds's avatar
      Merge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc · 56ef9db2
      Linus Torvalds authored
      Pull ARM SoC fixes from Olof Johansson:
       "This should be our final batch of fixes for 4.3:
      
         - A patch from Sudeep Holla that fixes annotation of wakeup sources
           properly, old unused format seems to have spread through copying.
      
         - Two patches from Tony for OMAP.  One dealing with MUSB setup
           problems due to runtime PM being enabled too early on the parent
           device.  The other fixes IRQ numbering for OMAP1"
      
      * tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
        usb: musb: omap2430: Fix regression caused by driver core change
        ARM: OMAP1: fix incorrect INT_DMA_LCD
        ARM: dts: fix gpio-keys wakeup-source property
      56ef9db2
    • Linus Torvalds's avatar
      Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi · 060b85b0
      Linus Torvalds authored
      Pull SCSI fixes from James Bottomley:
       "This is three essential bug fixes for various SCSI parts.
      
        The only affected users are SCSI multi-path via device handler
        (basically all the enterprise) and mvsas users.  The dh bugs are an
        async entanglement in boot resulting in a serious WARN_ON trip and a
        use after free on remove leading to a crash with strict memory
        accounting.  The mvsas bug manifests as a null deref oops but only on
        abort sequences; however, these can commonly occur with SATA attached
        devices, hence the fix"
      
      * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
        scsi_dh: don't try to load a device handler during async probing
        scsi_dh: fix use-after-free when removing scsi device
        mvsas: Fix NULL pointer dereference in mvs_slot_task_free
      060b85b0
    • Linus Torvalds's avatar
      Merge tag 'md/4.3-rc7-fixes' of git://neil.brown.name/md · af7eba01
      Linus Torvalds authored
      Pull md bug fixes from Neil Brown:
       "Two more bug fixes for md.
      
        One bugfix for a list corruption in raid5 because of incorrect
        locking.
      
        Other for possible data corruption when a recovering device is failed,
        removed, and re-added.
      
        Both tagged for -stable"
      
      * tag 'md/4.3-rc7-fixes' of git://neil.brown.name/md:
        Revert "md: allow a partially recovered device to be hot-added to an array."
        md/raid5: fix locking in handle_stripe_clean_event()
      af7eba01
  5. 31 Oct, 2015 12 commits
  6. 30 Oct, 2015 3 commits
    • Linus Torvalds's avatar
      Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux · 9b971e77
      Linus Torvalds authored
      Pull arm64 fixes from Will Deacon:
       "Apologies for this being so late, but we've uncovered a few nasty
        issues on arm64 which didn't settle down until yesterday and the fixes
        all look suitable for 4.3.  Of the four patches, three of them are
        Cc'd to stable, with the remaining patch fixing an issue that only
        took effect during the merge window.
      
        Summary:
      
         - Fix corruption in SWP emulation when STXR fails due to contention
         - Fix MMU re-initialisation when resuming from a low-power state
         - Fix stack unwinding code to match what ftrace expects
         - Fix relocation code in the EFI stub when DRAM base is not 2MB aligned"
      
      * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
        arm64/efi: do not assume DRAM base is aligned to 2 MB
        Revert "ARM64: unwind: Fix PC calculation"
        arm64: kernel: fix tcr_el1.t0sz restore on systems with extended idmap
        arm64: compat: fix stxr failure case in SWP emulation
      9b971e77
    • Linus Torvalds's avatar
      Merge tag 'please-pull-syscalls' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux · 7c0f488f
      Linus Torvalds authored
      Pull ia64 kcmp syscall from Tony Luck:
       "Missed adding the kcmp() syscall a long time ago.  Now it seems that
        it is essential to build systemd"
      
      * tag 'please-pull-syscalls' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux:
        [IA64] Wire up kcmp syscall
      7c0f488f
    • Roman Gushchin's avatar
      md/raid5: fix locking in handle_stripe_clean_event() · b8a9d66d
      Roman Gushchin authored
      After commit 566c09c5 ("raid5: relieve lock contention in get_active_stripe()")
      __find_stripe() is called under conf->hash_locks + hash.
      But handle_stripe_clean_event() calls remove_hash() under
      conf->device_lock.
      
      Under some cirscumstances the hash chain can be circuited,
      and we get an infinite loop with disabled interrupts and locked hash
      lock in __find_stripe(). This leads to hard lockup on multiple CPUs
      and following system crash.
      
      I was able to reproduce this behavior on raid6 over 6 ssd disks.
      The devices_handle_discard_safely option should be set to enable trim
      support. The following script was used:
      
      for i in `seq 1 32`; do
          dd if=/dev/zero of=large$i bs=10M count=100 &
      done
      
      neilb: original was against a 3.x kernel.  I forward-ported
        to 4.3-rc.  This verison is suitable for any kernel since
        Commit: 59fc630b ("RAID5: batch adjacent full stripe write")
        (v4.1+).  I'll post a version for earlier kernels to stable.
      Signed-off-by: default avatarRoman Gushchin <klamm@yandex-team.ru>
      Fixes: 566c09c5 ("raid5: relieve lock contention in get_active_stripe()")
      Signed-off-by: default avatarNeilBrown <neilb@suse.com>
      Cc: Shaohua Li <shli@kernel.org>
      Cc: <stable@vger.kernel.org> # 3.13 - 4.2
      b8a9d66d