1. 01 5月, 2015 5 次提交
  2. 30 4月, 2015 2 次提交
    • M
      dm: fix free_rq_clone() NULL pointer when requeueing unmapped request · aa6df8dd
      Mike Snitzer 提交于
      Commit 02233342 ("dm: optimize dm_mq_queue_rq to _not_ use kthread if
      using pure blk-mq") mistakenly removed free_rq_clone()'s clone->q check
      before testing clone->q->mq_ops.  It was an oversight to discontinue
      that check for 1 of the 2 use-cases for free_rq_clone():
      1) free_rq_clone() called when an unmapped original request is requeued
      2) free_rq_clone() called in the request-based IO completion path
      
      The clone->q check made sense for case #1 but not for #2.  However, we
      cannot just reinstate the check as it'd mask a serious bug in the IO
      completion case #2 -- no in-flight request should have an uninitialized
      request_queue (basic block layer refcounting _should_ ensure this).
      
      The NULL pointer seen for case #1 is detailed here:
      https://www.redhat.com/archives/dm-devel/2015-April/msg00160.html
      
      Fix this free_rq_clone() NULL pointer by simply checking if the
      mapped_device's type is DM_TYPE_MQ_REQUEST_BASED (clone's queue is
      blk-mq) rather than checking clone->q->mq_ops.  This avoids the need to
      dereference clone->q, but a WARN_ON_ONCE is added to let us know if an
      uninitialized clone request is being completed.
      Reported-by: NBart Van Assche <bart.vanassche@sandisk.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      aa6df8dd
    • C
      dm: only initialize the request_queue once · 3e6180f0
      Christoph Hellwig 提交于
      Commit bfebd1cd ("dm: add full blk-mq support to request-based DM")
      didn't properly account for the need to short-circuit re-initializing
      DM's blk-mq request_queue if it was already initialized.
      
      Otherwise, reloading a blk-mq request-based DM table (either manually
      or via multipathd) resulted in errors, see:
       https://www.redhat.com/archives/dm-devel/2015-April/msg00132.html
      
      Fix is to only initialize the request_queue on the initial table load
      (when the mapped_device type is assigned).
      
      This is better than having dm_init_request_based_blk_mq_queue() return
      early if the queue was already initialized because it elevates the
      constraint to a more meaningful location in DM core.  As such the
      pre-existing early return in dm_init_request_based_queue() can now be
      removed.
      
      Fixes: bfebd1cd ("dm: add full blk-mq support to request-based DM")
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      3e6180f0
  3. 29 4月, 2015 3 次提交
  4. 28 4月, 2015 19 次提交
  5. 27 4月, 2015 11 次提交
    • G
    • G
      drivers: sh: Disable PM runtime for multi-platform r8a73a4 with genpd · 230f259f
      Geert Uytterhoeven 提交于
      If the default PM domain using PM_CLK is used for PM runtime, the real PM
      domain(s) cannot be registered from DT later.
      
      Hence do not enable it when running a multi-platform kernel with genpd
      support on an r8a73a4. The R-Mobile PM domain driver will take care of
      PM runtime management of the module clocks.
      
      The default PM domain is still needed for:
        - platforms without genpd support,
        - the legacy (non-DT) case, where genpd may take over later, except
          for the C5 "always on" PM domain.
      Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
      230f259f
    • G
      drivers: sh: Disable PM runtime for multi-platform sh73a0 with genpd · 41b4b3bc
      Geert Uytterhoeven 提交于
      If the default PM domain using PM_CLK is used for PM runtime, the real PM
      domain(s) cannot be registered from DT later.
      
      Hence do not enable it when running a multi-platform kernel with genpd
      support on an sh73a0. The R-Mobile PM domain driver will take care of
      PM runtime management of the module clocks.
      
      The default PM domain is still needed for:
        - platforms without genpd support,
        - the legacy (non-DT) case, where genpd may take over later, except
          for the C5 "always on" PM domain.
      Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
      41b4b3bc
    • D
      Merge branch 'ppp_mppe_desync' · 8e9b29cc
      David S. Miller 提交于
      Sylvain Rochet says:
      
      ====================
      ppp: mppe: fixes MPPE desync on links which don't guarantee packet ordering
      
      I am currently having an issue with PPP over L2TP (UDP) and MPPE in
      stateless mode (default mode), UDP does not guarantee packet ordering so
      we might get out of order packet. MPPE needs to be continuously synched
      so we should drop late UDP packet.
      
      I added a printk on the number of time we rekeyed in MPPE decompressor,
      this is what we currently have if we receive a slightly out of order UDP
      packet:
      
      [1731001.049206] mppe_decompress[1]: ccount 1559
      [1731001.049216] mppe_decompress[1]: rekeyed 1 times
      
      [1731001.049228] mppe_decompress[1]: ccount 1560
      [1731001.049232] mppe_decompress[1]: rekeyed 1 times
      
      [1731001.050170] mppe_decompress[1]: ccount 1562
      [1731001.050182] mppe_decompress[1]: rekeyed 2 times
      
      [1731001.050191] mppe_decompress[1]: ccount 1561
      [1731001.062576] mppe_decompress[1]: rekeyed 4095 times
                                                   ^^^^
      This is obviously wrong, we missed packet 1561 and we already rekeyed 2
      times for 1562 we previously received, we can't recover the decryption
      key we need for 1561, we should drop it instead of rekeying 4095 times.
      
      This patch series drop any packet with are not within the 4096/2 forward
      window.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8e9b29cc
    • S
      ppp: mppe: discard late packet in stateless mode · 03654763
      Sylvain Rochet 提交于
      When PPP is used over a link which does not guarantee packet ordering,
      we might get late MPPE packets. This is a problem because MPPE must be
      kept synchronized and the current implementation does not drop them and
      rekey 4095 times instead of 0, which is wrong.
      
      In order to prevent rekeying about a whole count space times (~ 4095
      times), drop packets which are not within the forward 4096/2 window and
      increase sanity error counter.
      Signed-off-by: NSylvain Rochet <sylvain.rochet@finsecur.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      03654763
    • S
      ppp: mppe: sanity error path rework · 32530189
      Sylvain Rochet 提交于
      We are going to need sanity error path a little further, rework to be
      able to use the sanity error path anywhere in decompressor.
      Signed-off-by: NSylvain Rochet <sylvain.rochet@finsecur.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      32530189
    • M
      net/bonding: Make DRV macros private · 73b5a6f2
      Matan Barak 提交于
      The bonding modules currently defines four macros with
      general names that pollute the global namespace:
      DRV_VERSION
      DRV_RELDATE
      DRV_NAME
      DRV_DESCRIPTION
      
      Fixing that by defining a private bonding_priv.h
      header files which includes those defines.
      Signed-off-by: NMatan Barak <matanb@mellanox.com>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      73b5a6f2
    • L
      Linux 4.1-rc1 · b787f68c
      Linus Torvalds 提交于
      b787f68c
    • A
      x86_64, asm: Work around AMD SYSRET SS descriptor attribute issue · 61f01dd9
      Andy Lutomirski 提交于
      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: NAndy 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: NLinus Torvalds <torvalds@linux-foundation.org>
      61f01dd9
    • L
      Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux · 1190944f
      Linus Torvalds 提交于
      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
    • L
      Merge git://git.infradead.org/intel-iommu · 9f86262d
      Linus Torvalds 提交于
      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