1. 27 Nov, 2015 2 commits
  2. 26 Nov, 2015 6 commits
  3. 25 Nov, 2015 5 commits
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs · 78c4a49a
      Linus Torvalds authored
      Pull vfs fixes from Al Viro:
       "A couple of fixes for sendfile lockups caught by Dmitry + a fix for
        ancient sysvfs symlink breakage"
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
        vfs: Avoid softlockups with sendfile(2)
        vfs: Make sendfile(2) killable even better
        fix sysvfs symlinks
      78c4a49a
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.dk/linux-block · 9b81d512
      Linus Torvalds authored
      Pull more block layer fixes from Jens Axboe:
       "I wasn't going to send off a new pull before next week, but the blk
        flush fix from Jan from the other day introduced a regression.  It's
        rare enough not to have hit during testing, since it requires both a
        device that rejects the first flush, and bad timing while it does
        that.  But since someone did hit it, let's get the revert into 4.4-rc3
        so we don't have a released rc with that known issue.
      
        Apart from that revert, three other fixes:
      
         - From Christoph, a fix for a missing unmap in NVMe request
           preparation.
      
         - An NVMe fix from Nishanth that fixes data corruption on powerpc.
      
         - Also from Christoph, fix a list_del() attempt on blk-mq that didn't
           have a matching list_add() at timer start"
      
      * 'for-linus' of git://git.kernel.dk/linux-block:
        Revert "blk-flush: Queue through IO scheduler when flush not required"
        block: fix blk_abort_request for blk-mq drivers
        nvme: add missing unmaps in nvme_queue_rq
        NVMe: default to 4k device page size
      9b81d512
    • Jens Axboe's avatar
      Revert "blk-flush: Queue through IO scheduler when flush not required" · dcd8376c
      Jens Axboe authored
      This reverts commit 1b2ff19e.
      
      Jan writes:
      
      --
      
      Thanks for report! After some investigation I found out we allocate
      elevator specific data in __get_request() only for non-flush requests. And
      this is actually required since the flush machinery uses the space in
      struct request for something else. Doh. So my patch is just wrong and not
      easy to fix since at the time __get_request() is called we are not sure
      whether the flush machinery will be used in the end. Jens, please revert
      1b2ff19e. Thanks!
      
      I'm somewhat surprised that you can reliably hit the race where flushing
      gets disabled for the device just while the request is in flight. But I
      guess during boot it makes some sense.
      
      --
      
      So let's just revert it, we can fix the queue run manually after the
      fact. This race is rare enough that it didn't trigger in testing, it
      requires the specific disable-while-in-flight scenario to trigger.
      dcd8376c
    • Linus Torvalds's avatar
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm · 4cf193b4
      Linus Torvalds authored
      Pull KVM fixes from Paolo Bonzini:
       "Bug fixes for all architectures.  Nothing really stands out"
      
      * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (21 commits)
        KVM: nVMX: remove incorrect vpid check in nested invvpid emulation
        arm64: kvm: report original PAR_EL1 upon panic
        arm64: kvm: avoid %p in __kvm_hyp_panic
        KVM: arm/arm64: vgic: Trust the LR state for HW IRQs
        KVM: arm/arm64: arch_timer: Preserve physical dist. active state on LR.active
        KVM: arm/arm64: Fix preemptible timer active state crazyness
        arm64: KVM: Add workaround for Cortex-A57 erratum 834220
        arm64: KVM: Fix AArch32 to AArch64 register mapping
        ARM/arm64: KVM: test properly for a PTE's uncachedness
        KVM: s390: fix wrong lookup of VCPUs by array index
        KVM: s390: avoid memory overwrites on emergency signal injection
        KVM: Provide function for VCPU lookup by id
        KVM: s390: fix pfmf intercept handler
        KVM: s390: enable SIMD only when no VCPUs were created
        KVM: x86: request interrupt window when IRQ chip is split
        KVM: x86: set KVM_REQ_EVENT on local interrupt request from user space
        KVM: x86: split kvm_vcpu_ready_for_interrupt_injection out of dm_request_for_irq_injection
        KVM: x86: fix interrupt window handling in split IRQ chip case
        MIPS: KVM: Uninit VCPU in vcpu_create error path
        MIPS: KVM: Fix CACHE immediate offset sign extension
        ...
      4cf193b4
    • Haozhong Zhang's avatar
      KVM: nVMX: remove incorrect vpid check in nested invvpid emulation · b2467e74
      Haozhong Zhang authored
      This patch removes the vpid check when emulating nested invvpid
      instruction of type all-contexts invalidation. The existing code is
      incorrect because:
       (1) According to Intel SDM Vol 3, Section "INVVPID - Invalidate
           Translations Based on VPID", invvpid instruction does not check
           vpid in the invvpid descriptor when its type is all-contexts
           invalidation.
       (2) According to the same document, invvpid of type all-contexts
           invalidation does not require there is an active VMCS, so/and
           get_vmcs12() in the existing code may result in a NULL-pointer
           dereference. In practice, it can crash both KVM itself and L1
           hypervisors that use invvpid (e.g. Xen).
      Signed-off-by: default avatarHaozhong Zhang <haozhong.zhang@intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      b2467e74
  4. 24 Nov, 2015 21 commits
    • Christoph Hellwig's avatar
      block: fix blk_abort_request for blk-mq drivers · 55ce0da1
      Christoph Hellwig authored
      We only added the request to the request list for the !blk-mq case,
      so we should only delete it in that case as well.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      55ce0da1
    • Christoph Hellwig's avatar
      nvme: add missing unmaps in nvme_queue_rq · bf508e91
      Christoph Hellwig authored
      When we fail various metadata related operations in nvme_queue_rq we
      need to unmap the data SGL.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarKeith Busch <keith.busch@intel.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      bf508e91
    • Nishanth Aravamudan's avatar
      NVMe: default to 4k device page size · c5c9f25b
      Nishanth Aravamudan authored
      We received a bug report recently when DDW (64-bit direct DMA on Power)
      is not enabled for NVMe devices. In that case, we fall back to 32-bit
      DMA via the IOMMU, which is always done via 4K TCEs (Translation Control
      Entries).
      
      The NVMe device driver, though, assumes that the DMA alignment for the
      PRP entries will match the device's page size, and that the DMA aligment
      matches the kernel's page aligment. On Power, the the IOMMU page size,
      as mentioned above, can be 4K, while the device can have a page size of
      8K, while the kernel has a page size of 64K. This eventually trips the
      BUG_ON in nvme_setup_prps(), as we have a 'dma_len' that is a multiple
      of 4K but not 8K (e.g., 0xF000).
      
      In this particular case of page sizes, we clearly want to use the
      IOMMU's page size in the driver. And generally, the NVMe driver in this
      function should be using the IOMMU's page size for the default device
      page size, rather than the kernel's page size. There is not currently an
      API to obtain the IOMMU's page size across all architectures and in the
      interest of a stop-gap fix to this functional issue, default the NVMe
      device page size to 4K, with the intent of adding such an API and
      implementation across all architectures in the next merge window.
      
      With the functionally equivalent v3 of this patch, our hardware test
      exerciser survives when using 32-bit DMA; without the patch, the kernel
      will BUG within a few minutes.
      
      Signed-off-by: Nishanth Aravamudan <nacc at linux.vnet.ibm.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      c5c9f25b
    • Linus Torvalds's avatar
      Merge tag 'dm-4.4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm · 6ffeba96
      Linus Torvalds authored
      Pull device mapper fixes from Mike Snitzer:
       "Two fixes for 4.4-rc1's DM ioctl changes that introduced the potential
        for infinite recursion on ioctl (with DM multipath).
      
        And four stable fixes:
      
         - A DM thin-provisioning fix to restore 'error_if_no_space' setting
           when a thin-pool is made writable again (after having been out of
           space).
      
         - A DM thin-provisioning fix to properly advertise discard support
           for thin volumes that are stacked on a thin-pool whose underlying
           data device doesn't support discards.
      
         - A DM ioctl fix to allow ctrl-c to break out of an ioctl retry loop
           when DM multipath is configured to 'queue_if_no_path'.
      
         - A DM crypt fix for a possible hang on dm-crypt device removal"
      
      * tag 'dm-4.4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
        dm thin: fix regression in advertised discard limits
        dm crypt: fix a possible hang due to race condition on exit
        dm mpath: fix infinite recursion in ioctl when no paths and !queue_if_no_path
        dm: do not reuse dm_blk_ioctl block_device input as local variable
        dm: fix ioctl retry termination with signal
        dm thin: restore requested 'error_if_no_space' setting on OODS to WRITE transition
      6ffeba96
    • Eric Dumazet's avatar
      pidns: fix NULL dereference in __task_pid_nr_ns() · 81b1a832
      Eric Dumazet authored
      I got a crash during a "perf top" session that was caused by a race in
      __task_pid_nr_ns() :
      
      pid_nr_ns() was inlined, but apparently compiler chose to read
      task->pids[type].pid twice, and the pid->level dereference crashed
      because we got a NULL pointer at the second read :
      
          if (pid && ns->level <= pid->level) { // CRASH
      
      Just use RCU API properly to solve this race, and not worry about "perf
      top" crashing hosts :(
      
      get_task_pid() can benefit from same fix.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      81b1a832
    • Paolo Bonzini's avatar
      Merge tag 'kvm-arm-for-v4.4-rc3' of... · 8bd142c0
      Paolo Bonzini authored
      Merge tag 'kvm-arm-for-v4.4-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into kvm-master
      
      KVM/ARM Fixes for v4.4-rc3.
      
      Includes some timer fixes, properly unmapping PTEs, an errata fix, and two
      tweaks to the EL2 panic code.
      8bd142c0
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.dk/linux-block · 4ce01c51
      Linus Torvalds authored
      Pull block layer fixes from Jens Axboe:
       "A round of fixes/updates for the current series.
      
        This looks a little bigger than it is, but that's mainly because we
        pushed the lightnvm enabled null_blk change out of the merge window so
        it could be updated a bit.  The rest of the volume is also mostly
        lightnvm.  In particular:
      
         - Lightnvm.  Various fixes, additions, updates from Matias and
           Javier, as well as from Wenwei Tao.
      
         - NVMe:
              - Fix for potential arithmetic overflow from Keith.
              - Also from Keith, ensure that we reap pending completions from
                a completion queue before deleting it.  Fixes kernel crashes
                when resetting a device with IO pending.
              - Various little lightnvm related tweaks from Matias.
      
         - Fixup flushes to go through the IO scheduler, for the cases where a
           flush is not required.  Fixes a case in CFQ where we would be
           idling and not see this request, hence not break the idling.  From
           Jan Kara.
      
         - Use list_{first,prev,next} in elevator.c for cleaner code.  From
           Gelian Tang.
      
         - Fix for a warning trigger on btrfs and raid on single queue blk-mq
           devices, where we would flush plug callbacks with preemption
           disabled.  From me.
      
         - A mac partition validation fix from Kees Cook.
      
         - Two merge fixes from Ming, marked stable.  A third part is adding a
           new warning so we'll notice this quicker in the future, if we screw
           up the accounting.
      
         - Cleanup of thread name/creation in mtip32xx from Rasmus Villemoes"
      
      * 'for-linus' of git://git.kernel.dk/linux-block: (32 commits)
        blk-merge: warn if figured out segment number is bigger than nr_phys_segments
        blk-merge: fix blk_bio_segment_split
        block: fix segment split
        blk-mq: fix calling unplug callbacks with preempt disabled
        mac: validate mac_partition is within sector
        mtip32xx: use formatting capability of kthread_create_on_node
        NVMe: reap completion entries when deleting queue
        lightnvm: add free and bad lun info to show luns
        lightnvm: keep track of block counts
        nvme: lightnvm: use admin queues for admin cmds
        lightnvm: missing free on init error
        lightnvm: wrong return value and redundant free
        null_blk: do not del gendisk with lightnvm
        null_blk: use device addressing mode
        null_blk: use ppa_cache pool
        NVMe: Fix possible arithmetic overflow for max segments
        blk-flush: Queue through IO scheduler when flush not required
        null_blk: register as a LightNVM device
        elevator: use list_{first,prev,next}_entry
        lightnvm: cleanup queue before target removal
        ...
      4ce01c51
    • Mark Rutland's avatar
      arm64: kvm: report original PAR_EL1 upon panic · fbb4574c
      Mark Rutland authored
      If we call __kvm_hyp_panic while a guest context is active, we call
      __restore_sysregs before acquiring the system register values for the
      panic, in the process throwing away the PAR_EL1 value at the point of
      the panic.
      
      This patch modifies __kvm_hyp_panic to stash the PAR_EL1 value prior to
      restoring host register values, enabling us to report the original
      values at the point of the panic.
      Acked-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      fbb4574c
    • Mark Rutland's avatar
      arm64: kvm: avoid %p in __kvm_hyp_panic · 1d7a4e31
      Mark Rutland authored
      Currently __kvm_hyp_panic uses %p for values which are not pointers,
      such as the ESR value. This can confusingly lead to "(null)" being
      printed for the value.
      
      Use %x instead, and only use %p for host pointers.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Cc: Christoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      1d7a4e31
    • Christoffer Dall's avatar
      KVM: arm/arm64: vgic: Trust the LR state for HW IRQs · 9f958c11
      Christoffer Dall authored
      We were probing the physial distributor state for the active state of a
      HW virtual IRQ, because we had seen evidence that the LR state was not
      cleared when the guest deactivated a virtual interrupted.
      
      However, this issue turned out to be a software bug in the GIC, which
      was solved by: 84aab5e68c2a5e1e18d81ae8308c3ce25d501b29
      (KVM: arm/arm64: arch_timer: Preserve physical dist. active
      state on LR.active, 2015-11-24)
      
      Therefore, get rid of the complexities and just look at the LR.
      Reviewed-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      9f958c11
    • Christoffer Dall's avatar
      KVM: arm/arm64: arch_timer: Preserve physical dist. active state on LR.active · 0e3dfda9
      Christoffer Dall authored
      We were incorrectly removing the active state from the physical
      distributor on the timer interrupt when the timer output level was
      deasserted.  We shouldn't be doing this without considering the virtual
      interrupt's active state, because the architecture requires that when an
      LR has the HW bit set and the pending or active bits set, then the
      physical interrupt must also have the corresponding bits set.
      
      This addresses an issue where we have been observing an inconsistency
      between the LR state and the physical distributor state where the LR
      state was active and the physical distributor was not active, which
      shouldn't happen.
      Reviewed-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      0e3dfda9
    • Christoffer Dall's avatar
      KVM: arm/arm64: Fix preemptible timer active state crazyness · 7e16aa81
      Christoffer Dall authored
      We were setting the physical active state on the GIC distributor in a
      preemptible section, which could cause us to set the active state on
      different physical CPU from the one we were actually going to run on,
      hacoc ensues.
      
      Since we are no longer descheduling/scheduling soft timers in the
      flush/sync timer functions, simply moving the timer flush into a
      non-preemptible section.
      Reviewed-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      7e16aa81
    • Marc Zyngier's avatar
      arm64: KVM: Add workaround for Cortex-A57 erratum 834220 · 498cd5c3
      Marc Zyngier authored
      Cortex-A57 parts up to r1p2 can misreport Stage 2 translation faults
      when a Stage 1 permission fault or device alignment fault should
      have been reported.
      
      This patch implements the workaround (which is to validate that the
      Stage-1 translation actually succeeds) by using code patching.
      
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      498cd5c3
    • Marc Zyngier's avatar
      arm64: KVM: Fix AArch32 to AArch64 register mapping · c0f09634
      Marc Zyngier authored
      When running a 32bit guest under a 64bit hypervisor, the ARMv8
      architecture defines a mapping of the 32bit registers in the 64bit
      space. This includes banked registers that are being demultiplexed
      over the 64bit ones.
      
      On exceptions caused by an operation involving a 32bit register, the
      HW exposes the register number in the ESR_EL2 register. It was so
      far understood that SW had to distinguish between AArch32 and AArch64
      accesses (based on the current AArch32 mode and register number).
      
      It turns out that I misinterpreted the ARM ARM, and the clue is in
      D1.20.1: "For some exceptions, the exception syndrome given in the
      ESR_ELx identifies one or more register numbers from the issued
      instruction that generated the exception. Where the exception is
      taken from an Exception level using AArch32 these register numbers
      give the AArch64 view of the register."
      
      Which means that the HW is already giving us the translated version,
      and that we shouldn't try to interpret it at all (for example, doing
      an MMIO operation from the IRQ mode using the LR register leads to
      very unexpected behaviours).
      
      The fix is thus not to perform a call to vcpu_reg32() at all from
      vcpu_reg(), and use whatever register number is supplied directly.
      The only case we need to find out about the mapping is when we
      actively generate a register access, which only occurs when injecting
      a fault in a guest.
      
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      c0f09634
    • Ard Biesheuvel's avatar
      ARM/arm64: KVM: test properly for a PTE's uncachedness · e6fab544
      Ard Biesheuvel authored
      The open coded tests for checking whether a PTE maps a page as
      uncached use a flawed '(pte_val(xxx) & CONST) != CONST' pattern,
      which is not guaranteed to work since the type of a mapping is
      not a set of mutually exclusive bits
      
      For HYP mappings, the type is an index into the MAIR table (i.e, the
      index itself does not contain any information whatsoever about the
      type of the mapping), and for stage-2 mappings it is a bit field where
      normal memory and device types are defined as follows:
      
          #define MT_S2_NORMAL            0xf
          #define MT_S2_DEVICE_nGnRE      0x1
      
      I.e., masking *and* comparing with the latter matches on the former,
      and we have been getting lucky merely because the S2 device mappings
      also have the PTE_UXN bit set, or we would misidentify memory mappings
      as device mappings.
      
      Since the unmap_range() code path (which contains one instance of the
      flawed test) is used both for HYP mappings and stage-2 mappings, and
      considering the difference between the two, it is non-trivial to fix
      this by rewriting the tests in place, as it would involve passing
      down the type of mapping through all the functions.
      
      However, since HYP mappings and stage-2 mappings both deal with host
      physical addresses, we can simply check whether the mapping is backed
      by memory that is managed by the host kernel, and only perform the
      D-cache maintenance if this is the case.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Tested-by: default avatarPavel Fedin <p.fedin@samsung.com>
      Reviewed-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      e6fab544
    • Ming Lei's avatar
      blk-merge: warn if figured out segment number is bigger than nr_phys_segments · 12e57f59
      Ming Lei authored
      We had seen lots of reports of this kind issue, so add one
      warnning in blk-merge, then it can be triggered easily and
      avoid to depend on warning/bug from drivers.
      Signed-off-by: default avatarMing Lei <ming.lei@canonical.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      12e57f59
    • Ming Lei's avatar
      blk-merge: fix blk_bio_segment_split · 02e70742
      Ming Lei authored
      Commit bdced438(block: setup bi_phys_segments after
      splitting) introduces function of computing bio->bi_phys_segments
      during bio splitting.
      
      Unfortunately both bio->bi_seg_front_size and bio->bi_seg_back_size
      arn't computed, so too many physical segments may be obtained
      for one request since both the two are used to check if one segment
      across two bios can be possible.
      
      This patch fixes the issue by computing the two variables in
      blk_bio_segment_split().
      
      Fixes: bdced438(block: setup bi_phys_segments after splitting)
      Reported-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Reported-by: default avatarMark Salter <msalter@redhat.com>
      Tested-by: default avatarLaurent Dufour <ldufour@linux.vnet.ibm.com>
      Tested-by: default avatarMark Salter <msalter@redhat.com>
      Signed-off-by: default avatarMing Lei <ming.lei@canonical.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      02e70742
    • Ming Lei's avatar
      block: fix segment split · 578270bf
      Ming Lei authored
      Inside blk_bio_segment_split(), previous bvec pointer(bvprvp)
      always points to the iterator local variable, which is obviously
      wrong, so fix it by pointing to the local variable of 'bvprv'.
      
      Fixes: 5014c311(block: fix bogus compiler warnings in blk-merge.c)
      Cc: stable@kernel.org #4.3
      Reported-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Reported-by: default avatarMark Salter <msalter@redhat.com>
      Tested-by: default avatarLaurent Dufour <ldufour@linux.vnet.ibm.com>
      Tested-by: default avatarMark Salter <msalter@redhat.com>
      Signed-off-by: default avatarMing Lei <ming.lei@canonical.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      578270bf
    • Jan Kara's avatar
      vfs: Avoid softlockups with sendfile(2) · c2489e07
      Jan Kara authored
      The following test program from Dmitry can cause softlockups or RCU
      stalls as it copies 1GB from tmpfs into eventfd and we don't have any
      scheduling point at that path in sendfile(2) implementation:
      
              int r1 = eventfd(0, 0);
              int r2 = memfd_create("", 0);
              unsigned long n = 1<<30;
              fallocate(r2, 0, 0, n);
              sendfile(r1, r2, 0, n);
      
      Add cond_resched() into __splice_from_pipe() to fix the problem.
      
      CC: Dmitry Vyukov <dvyukov@google.com>
      CC: stable@vger.kernel.org
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      c2489e07
    • Jan Kara's avatar
      vfs: Make sendfile(2) killable even better · c725bfce
      Jan Kara authored
      Commit 296291cd (mm: make sendfile(2) killable) fixed an issue where
      sendfile(2) was doing a lot of tiny writes into a filesystem and thus
      was unkillable for a long time. However sendfile(2) can be (mis)used to
      issue lots of writes into arbitrary file descriptor such as evenfd or
      similar special file descriptors which never hit the standard filesystem
      write path and thus are still unkillable. E.g. the following example
      from Dmitry burns CPU for ~16s on my test system without possibility to
      be killed:
      
              int r1 = eventfd(0, 0);
              int r2 = memfd_create("", 0);
              unsigned long n = 1<<30;
              fallocate(r2, 0, 0, n);
              sendfile(r1, r2, 0, n);
      
      There are actually quite a few tests for pending signals in sendfile
      code however we data to write is always available none of them seems to
      trigger. So fix the problem by adding a test for pending signal into
      splice_from_pipe_next() also before the loop waiting for pipe buffers to
      be available. This should fix all the lockup issues with sendfile of the
      do-ton-of-tiny-writes nature.
      
      CC: stable@vger.kernel.org
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      c725bfce
    • Al Viro's avatar
      fix sysvfs symlinks · 0ebf7f10
      Al Viro authored
      The thing got broken back in 2002 - sysvfs does *not* have inline
      symlinks; even short ones have bodies stored in the first block
      of file.  sysv_symlink() handles that correctly; unfortunately,
      attempting to look an existing symlink up will end up confusing
      them for inline symlinks, and interpret the block number containing
      the body as the body itself.
      
      Nobody has noticed until now, which says something about the level
      of testing sysvfs gets ;-/
      
      Cc: stable@vger.kernel.org # all of them, not that anyone cared
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      0ebf7f10
  5. 23 Nov, 2015 6 commits
    • Linus Torvalds's avatar
      Merge tag 'linux-kselftest-4.4-rc3' of... · a2931547
      Linus Torvalds authored
      Merge tag 'linux-kselftest-4.4-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
      
      Pull kselftest fixes from Shuah Khan:
       "This update consists of one minor documentation fix and a fix to an
        existing test"
      
      * tag 'linux-kselftest-4.4-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest:
        selftests/seccomp: Get page size from sysconf
        tools:testing/selftests: fix typo in futex/README
      a2931547
    • Mike Snitzer's avatar
      dm thin: fix regression in advertised discard limits · 0fcb04d5
      Mike Snitzer authored
      When establishing a thin device's discard limits we cannot rely on the
      underlying thin-pool device's discard capabilities (which are inherited
      from the thin-pool's underlying data device) given that DM thin devices
      must provide discard support even when the thin-pool's underlying data
      device doesn't support discards.
      
      Users were exposed to this thin device discard limits regression if
      their thin-pool's underlying data device does _not_ support discards.
      This regression caused all upper-layers that called the
      blkdev_issue_discard() interface to not be able to issue discards to
      thin devices (because discard_granularity was 0).  This regression
      wasn't caught earlier because the device-mapper-test-suite's extensive
      'thin-provisioning' discard tests are only ever performed against
      thin-pool's with data devices that support discards.
      
      Fix is to have thin_io_hints() test the pool's 'discard_enabled' feature
      rather than inferring whether or not a thin device's discard support
      should be enabled by looking at the thin-pool's discard_granularity.
      
      Fixes: 21607670 ("dm thin: disable discard support for thin devices if pool's is disabled")
      Reported-by: default avatarMike Gerber <mike@sprachgewalt.de>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Cc: stable@vger.kernel.org # 4.1+
      0fcb04d5
    • Vineet Gupta's avatar
      ARC: dw2 unwind: Remove falllback linear search thru FDE entries · 2e22502c
      Vineet Gupta authored
      Fixes STAR 9000953410: "perf callgraph profiling causing RCU stalls"
      
      | perf record -g -c 15000 -e cycles /sbin/hackbench
      |
      | INFO: rcu_preempt self-detected stall on CPU
      | 1: (1 GPs behind) idle=609/140000000000002/0 softirq=2914/2915 fqs=603
      | Task dump for CPU 1:
      
      in-kernel dwarf unwinder has a fast binary lookup and a fallback linear
      search (which iterates thru each of ~11K entries) thus takes 2 orders of
      magnitude longer (~3 million cycles vs. 2000). Routines written in hand
      assembler lack dwarf info (as we don't support assembler CFI pseudo-ops
      yet) fail the unwinder binary lookup, hit linear search, failing
      nevertheless in the end.
      
      However the linear search is pointless as binary lookup tables are created
      from it in first place. It is impossible to have binary lookup fail while
      succeed the linear search. It is pure waste of cycles thus removed by
      this patch.
      
      This manifested as RCU stalls / NMI watchdog splat when running
      hackbench under perf with callgraph profiling. The triggering condition
      was perf counter overflowing in routine lacking dwarf info (like memset)
      leading to patheic 3 million cycle unwinder slow path and by the time it
      returned new interrupts were already pending (Timer, IPI) and taken
      rightaway. The original memset didn't make forward progress, system kept
      accruing more interrupts and more unwinder delayes in a vicious feedback
      loop, ultimately triggering the NMI diagnostic.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      2e22502c
    • Michael Neuling's avatar
      powerpc/tm: Check for already reclaimed tasks · 7f821fc9
      Michael Neuling authored
      Currently we can hit a scenario where we'll tm_reclaim() twice.  This
      results in a TM bad thing exception because the second reclaim occurs
      when not in suspend mode.
      
      The scenario in which this can happen is the following.  We attempt to
      deliver a signal to userspace.  To do this we need obtain the stack
      pointer to write the signal context.  To get this stack pointer we
      must tm_reclaim() in case we need to use the checkpointed stack
      pointer (see get_tm_stackpointer()).  Normally we'd then return
      directly to userspace to deliver the signal without going through
      __switch_to().
      
      Unfortunatley, if at this point we get an error (such as a bad
      userspace stack pointer), we need to exit the process.  The exit will
      result in a __switch_to().  __switch_to() will attempt to save the
      process state which results in another tm_reclaim().  This
      tm_reclaim() now causes a TM Bad Thing exception as this state has
      already been saved and the processor is no longer in TM suspend mode.
      Whee!
      
      This patch checks the state of the MSR to ensure we are TM suspended
      before we attempt the tm_reclaim().  If we've already saved the state
      away, we should no longer be in TM suspend mode.  This has the
      additional advantage of checking for a potential TM Bad Thing
      exception.
      
      Found using syscall fuzzer.
      
      Fixes: fb09692e ("powerpc: Add reclaim and recheckpoint functions for context switching transactional memory processes")
      Cc: stable@vger.kernel.org # v3.9+
      Signed-off-by: default avatarMichael Neuling <mikey@neuling.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      7f821fc9
    • Michael Neuling's avatar
      powerpc/tm: Block signal return setting invalid MSR state · d2b9d2a5
      Michael Neuling authored
      Currently we allow both the MSR T and S bits to be set by userspace on
      a signal return.  Unfortunately this is a reserved configuration and
      will cause a TM Bad Thing exception if attempted (via rfid).
      
      This patch checks for this case in both the 32 and 64 bit signals
      code.  If both T and S are set, we mark the context as invalid.
      
      Found using a syscall fuzzer.
      
      Fixes: 2b0a576d ("powerpc: Add new transactional memory state to the signal context")
      Cc: stable@vger.kernel.org # v3.9+
      Signed-off-by: default avatarMichael Neuling <mikey@neuling.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      d2b9d2a5
    • Linus Torvalds's avatar
      Linux 4.4-rc2 · 1ec21837
      Linus Torvalds authored
      1ec21837