1. 25 May, 2015 26 commits
  2. 18 May, 2015 3 commits
  3. 11 May, 2015 2 commits
  4. 27 Apr, 2015 9 commits
    • Christoph Hellwig's avatar
      3w-9xxx: fix command completion race · 118c855b
      Christoph Hellwig authored
      The 3w-9xxx driver needs to tear down the dma mappings before returning
      the command to the midlayer, as there is no guarantee the sglist and
      count are valid after that point.  Also remove the dma mapping helpers
      which have another inherent race due to the request_id index.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Cc: stable@vger.kernel.org
      Acked-by: default avatarAdam Radford <aradford@gmail.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Odin.com>
      118c855b
    • Christoph Hellwig's avatar
      3w-xxxx: fix command completion race · 9cd95546
      Christoph Hellwig authored
      The 3w-xxxx driver needs to tear down the dma mappings before returning
      the command to the midlayer, as there is no guarantee the sglist and
      count are valid after that point.  Also remove the dma mapping helpers
      which have another inherent race due to the request_id index.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Cc: stable@vger.kernel.org
      Acked-by: default avatarAdam Radford <aradford@gmail.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Odin.com>
      9cd95546
    • Christoph Hellwig's avatar
      3w-sas: fix command completion race · 579d69bc
      Christoph Hellwig authored
      The 3w-sas driver needs to tear down the dma mappings before returning
      the command to the midlayer, as there is no guarantee the sglist and
      count are valid after that point.  Also remove the dma mapping helpers
      which have another inherent race due to the request_id index.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Reported-by: default avatarTorsten Luettgert <ml-lkml@enda.eu>
      Tested-by: default avatarBernd Kardatzki <Bernd.Kardatzki@med.uni-tuebingen.de>
      Cc: stable@vger.kernel.org
      Acked-by: default avatarAdam Radford <aradford@gmail.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Odin.com>
      579d69bc
    • Ondrej Zary's avatar
      aha1542: Allocate memory before taking a lock · 8c08a621
      Ondrej Zary authored
      The driver currently calls kmalloc with GFP_KERNEL while holding a lock.
      Fix it by doing the allocation earlier, before taking the lock.
      
      Tested on AHA-1542B.
      Signed-off-by: default avatarOndrej Zary <linux@rainbow-software.org>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Odin.com>
      8c08a621
    • Mike Christie's avatar
      SCSI: add 1024 max sectors black list flag · 35e9a9f9
      Mike Christie authored
      This works around a issue with qnap iscsi targets not handling large IOs
      very well.
      
      The target returns:
      
      VPD INQUIRY: Block limits page (SBC)
        Maximum compare and write length: 1 blocks
        Optimal transfer length granularity: 1 blocks
        Maximum transfer length: 4294967295 blocks
        Optimal transfer length: 4294967295 blocks
        Maximum prefetch, xdread, xdwrite transfer length: 0 blocks
        Maximum unmap LBA count: 8388607
        Maximum unmap block descriptor count: 1
        Optimal unmap granularity: 16383
        Unmap granularity alignment valid: 0
        Unmap granularity alignment: 0
        Maximum write same length: 0xffffffff blocks
        Maximum atomic transfer length: 0
        Atomic alignment: 0
        Atomic transfer length granularity: 0
      
      and it is *sometimes* able to handle at least one IO of size up to 8 MB. We
      have seen in traces where it will sometimes work, but other times it
      looks like it fails and it looks like it returns failures if we send
      multiple large IOs sometimes. Also it looks like it can return 2 different
      errors. It will sometimes send iscsi reject errors indicating out of
      resources or it will send invalid cdb illegal requests check conditions.
      And then when it sends iscsi rejects it does not seem to handle retries
      when there are command sequence holes, so I could not just add code to
      try and gracefully handle that error code.
      
      The problem is that we do not have a good contact for the company,
      so we are not able to determine under what conditions it returns
      which error and why it sometimes works.
      
      So, this patch just adds a new black list flag to set targets like this to
      the old max safe sectors of 1024. The max_hw_sectors changes added in 3.19
      caused this regression, so I also ccing stable.
      Reported-by: default avatarChristian Hesse <list@eworm.de>
      Signed-off-by: default avatarMike Christie <michaelc@cs.wisc.edu>
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Odin.com>
      35e9a9f9
    • Linus Torvalds's avatar
      Linux 4.1-rc1 · b787f68c
      Linus Torvalds authored
      b787f68c
    • Andy Lutomirski's avatar
      x86_64, asm: Work around AMD SYSRET SS descriptor attribute issue · 61f01dd9
      Andy Lutomirski authored
      AMD CPUs don't reinitialize the SS descriptor on SYSRET, so SYSRET with
      SS == 0 results in an invalid usermode state in which SS is apparently
      equal to __USER_DS but causes #SS if used.
      
      Work around the issue by setting SS to __KERNEL_DS __switch_to, thus
      ensuring that SYSRET never happens with SS set to NULL.
      
      This was exposed by a recent vDSO cleanup.
      
      Fixes: e7d6eefa x86/vdso32/syscall.S: Do not load __USER32_DS to %ss
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Cc: Peter Anvin <hpa@zytor.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Denys Vlasenko <vda.linux@googlemail.com>
      Cc: Brian Gerst <brgerst@gmail.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      61f01dd9
    • Linus Torvalds's avatar
      Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux · 1190944f
      Linus Torvalds authored
      Pull intel drm fixes from Dave Airlie.
      
      * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
        drm/i915: vlv: fix save/restore of GFX_MAX_REQ_COUNT reg
        drm/i915: Workaround to avoid lite restore with HEAD==TAIL
        drm/i915: cope with large i2c transfers
      1190944f
    • Linus Torvalds's avatar
      Merge git://git.infradead.org/intel-iommu · 9f86262d
      Linus Torvalds authored
      Pull intel iommu updates from David Woodhouse:
       "This lays a little of the groundwork for upcoming Shared Virtual
        Memory support — fixing some bogus #defines for capability bits and
        adding the new ones, and starting to use the new wider page tables
        where we can, in anticipation of actually filling in the new fields
        therein.
      
        It also allows graphics devices to be assigned to VM guests again.
        This got broken in 3.17 by disallowing assignment of RMRR-afflicted
        devices.  Like USB, we do understand why there's an RMRR for graphics
        devices — and unlike USB, it's actually sane.  So we can make an
        exception for graphics devices, just as we do USB controllers.
      
        Finally, tone down the warning about the X2APIC_OPT_OUT bit, due to
        persistent requests.  X2APIC_OPT_OUT was added to the spec as a nasty
        hack to allow broken BIOSes to forbid us from using X2APIC when they
        do stupid and invasive things and would break if we did.
      
        Someone noticed that since Windows doesn't have full IOMMU support for
        DMA protection, setting the X2APIC_OPT_OUT bit made Windows avoid
        initialising the IOMMU on the graphics unit altogether.
      
        This means that it would be available for use in "driver mode", where
        the IOMMU registers are made available through a BAR of the graphics
        device and the graphics driver can do SVM all for itself.
      
        So they started setting the X2APIC_OPT_OUT bit on *all* platforms with
        SVM capabilities.  And even the platforms which *might*, if the
        planets had been aligned correctly, possibly have had SVM capability
        but which in practice actually don't"
      
      * git://git.infradead.org/intel-iommu:
        iommu/vt-d: support extended root and context entries
        iommu/vt-d: Add new extended capabilities from v2.3 VT-d specification
        iommu/vt-d: Allow RMRR on graphics devices too
        iommu/vt-d: Print x2apic opt out info instead of printing a warning
        iommu/vt-d: kill bogus ecap_niotlb_iunits()
      9f86262d