1. 26 9月, 2008 1 次提交
  2. 17 9月, 2008 2 次提交
    • Y
      IPoIB: Fix deadlock on RTNL between bcast join comp and ipoib_stop() · e8224e4b
      Yossi Etigin 提交于
      Taking rtnl_lock in ipoib_mcast_join_complete() causes a deadlock with
      ipoib_stop().  We avoid it by scheduling the piece of code that takes
      the lock on ipoib_workqueue instead of executing it directly.  This
      works because we only flush the ipoib_workqueue with the RTNL not held.
      
      The deadlock happens because ipoib_stop() calls ipoib_ib_dev_down()
      which calls ipoib_mcast_dev_flush(), which calls ipoib_mcast_free(),
      which calls ipoib_mcast_leave(). The latter calls
      ib_sa_free_multicast(), and this waits until the multicast completion
      handler finishes.  This handler is ipoib_mcast_join_complete(), which
      waits for the rtnl_lock(), which was already taken by ipoib_stop().
      
      This bug was introduced in commit a77a57a1 ("IPoIB: Fix deadlock on
      RTNL in ipoib_stop()").
      Signed-off-by: NYossi Etigin <yosefe@voltaire.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      e8224e4b
    • F
      RDMA/nes: Fix client side QP destroy · d7ffd507
      Faisal Latif 提交于
      Fix QP not being destroyed properly on the client, which leads to
      userspace programs hanging on exit.  This is a missing chunk from the
      connection management rewrite in commit 6492cdf3 ("RDMA/nes: CM
      connection setup/teardown rework").
      Signed-off-by: NFaisal Latif <flatif@neteffect.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      d7ffd507
  3. 16 9月, 2008 1 次提交
  4. 28 8月, 2008 1 次提交
  5. 24 8月, 2008 1 次提交
  6. 20 8月, 2008 1 次提交
    • R
      IPoIB: Fix deadlock on RTNL in ipoib_stop() · a77a57a1
      Roland Dreier 提交于
      Commit c8c2afe3 ("IPoIB: Use rtnl lock/unlock when changing device
      flags") added a call to rtnl_lock() in ipoib_mcast_join_task(), which
      is run from the ipoib_workqueue.  However, ipoib_stop() (which is run
      inside rtnl_lock()) flushes this workqueue, which leads to a deadlock
      if the join task is pending.
      
      Fix this by simply not flushing the workqueue from ipoib_stop().  It
      turns out that we really don't care about workqueue tasks running
      during or after ipoib_stop(), as long as we make sure to flush the
      workqueue before unregistering a netdev.
      
      This fixes <https://bugs.openfabrics.org/show_bug.cgi?id=1114>.
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      a77a57a1
  7. 16 8月, 2008 2 次提交
  8. 13 8月, 2008 5 次提交
  9. 09 8月, 2008 1 次提交
  10. 08 8月, 2008 2 次提交
  11. 07 8月, 2008 1 次提交
  12. 05 8月, 2008 5 次提交
    • A
      IB/ipath: Fix printk format warnings · 70117b9e
      Alexander Beregalov 提交于
          ipath_driver.c:1260: warning: format '%Lx' expects type 'long long unsigned int', but argument 6 has type 'long unsigned int'
          ipath_driver.c:1459: warning: format '%Lx' expects type 'long long unsigned int', but argument 4 has type 'u64'
          ipath_intr.c:358: warning: format '%Lx' expects type 'long long unsigned int', but argument 3 has type 'u64'
          ipath_intr.c:358: warning: format '%Lu' expects type 'long long unsigned int', but argument 6 has type 'u64'
          ipath_intr.c:1119: warning: format '%Lx' expects type 'long long unsigned int', but argument 5 has type 'u64'
          ipath_intr.c:1119: warning: format '%Lx' expects type 'long long unsigned int', but argument 3 has type 'u64'
          ipath_intr.c:1123: warning: format '%Lx' expects type 'long long unsigned int', but argument 3 has type 'u64'
          ipath_intr.c:1130: warning: format '%Lx' expects type 'long long unsigned int', but argument 4 has type 'u64'
          ipath_iba7220.c:1032: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'u64'
          ipath_iba7220.c:1045: warning: format '%llX' expects type 'long long unsigned int', but argument 3 has type 'u64'
          ipath_iba7220.c:2506: warning: format '%Lu' expects type 'long long unsigned int', but argument 4 has type 'u64'
      Signed-off-by: NAlexander Beregalov <a.beregalov@gmail.com>
      Cc: Sean Hefty <sean.hefty@intel.com>
      Cc: Hal Rosenstock <hal.rosenstock@gmail.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      70117b9e
    • S
      RDMA/cxgb3: Fix deadlock initializing iw_cxgb3 device · be43324d
      Steve Wise 提交于
      Running 'ifconfig up' on the cxgb3 interface with iw_cxgb3 loaded
      causes a deadlock.  The rtnl lock is already held in this path.  The
      function fw_supports_fastreg() was introduced in 2.6.27 to
      conditionally set the IB_DEVICE_MEM_MGT_EXTENSIONS bit iff the
      firmware was at 7.0 or greater, and this function also acquires the
      rtnl lock and which thus causes a deadlock.  Further, if iw_cxgb3 is
      loaded _after_ the nic interface is brought up, then the deadlock does
      not occur and therefore fw_supports_fastreg() does need to grab the
      rtnl lock in that path.
      
      It turns out this code is all useless anyway.  The low level driver
      will NOT allow the open if the firmware isn't 7.0, so iw_cxgb3 can
      always set the MEM_MGT_EXTENSIONS bit.  Simplify...
      Signed-off-by: NSteve Wise <swise@opengridcomputing.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      be43324d
    • S
      RDMA/cxgb3: Fix up MW access rights · 1c355a6e
      Steve Wise 提交于
      - MWs don't have local read/write permissions.
      - Set the MW_BIND enabled bit if a MR has MW_BIND access.
      Signed-off-by: NSteve Wise <swise@opengridcomputing.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      1c355a6e
    • S
      RDMA/cxgb3: Fix QP capabilities · 5f0f66b0
      Steve Wise 提交于
      - Set the stag0 and fastreg capability bits only for kernel qps.
      - QP_PRIV flag is no longer used, so don't set it.
      Signed-off-by: NSteve Wise <swise@opengridcomputing.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      5f0f66b0
    • R
      RDMA/cma: Remove padding arrays by using struct sockaddr_storage · 3f446754
      Roland Dreier 提交于
      There are a few places where the RDMA CM code handles IPv6 by doing
      
      	struct sockaddr		addr;
      	u8			pad[sizeof(struct sockaddr_in6) -
      				    sizeof(struct sockaddr)];
      
      This is fragile and ugly; handle this in a better way with just
      
      	struct sockaddr_storage	addr;
      
      [ Also roll in patch from Aleksey Senin <alekseys@voltaire.com> to
        switch to struct sockaddr_storage and get rid of padding arrays in
        struct rdma_addr. ]
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      3f446754
  13. 04 8月, 2008 1 次提交
  14. 02 8月, 2008 1 次提交
  15. 31 7月, 2008 1 次提交
    • V
      IB/ipath: Use unsigned long for irq flags · 52fd8ca6
      Vegard Nossum 提交于
      A few functions in the ipath driver incorrectly use unsigned int to
      hold irq flags for spin_lock_irqsave().
      
      This patch was generated using the Coccinelle framework with the
      following semantic patch:
      
      The semantic patch I used was this:
      
      @@
      expression lock;
      identifier flags;
      expression subclass;
      @@
      
      - unsigned int flags;
      + unsigned long flags;
      
      ...
      
      <+...
      
      (
       spin_lock_irqsave(lock, flags)
      |
       _spin_lock_irqsave(lock)
      |
       spin_unlock_irqrestore(lock, flags)
      |
       _spin_unlock_irqrestore(lock, flags)
      |
       read_lock_irqsave(lock, flags)
      |
       _read_lock_irqsave(lock)
      |
       read_unlock_irqrestore(lock, flags)
      |
       _read_unlock_irqrestore(lock, flags)
      |
       write_lock_irqsave(lock, flags)
      |
       _write_lock_irqsave(lock)
      |
       write_unlock_irqrestore(lock, flags)
      |
       _write_unlock_irqrestore(lock, flags)
      |
       spin_lock_irqsave_nested(lock, flags, subclass)
      |
       _spin_lock_irqsave_nested(lock, subclass)
      |
       spin_unlock_irqrestore(lock, flags)
      |
       _spin_unlock_irqrestore(lock, flags)
      |
       _raw_spin_lock_flags(lock, flags)
      |
       __raw_spin_lock_flags(lock, flags)
      )
      
      ...+>
      
      Cc: Ralph Campbell <ralph.campbell@qlogic.com>
      Cc: Julia Lawall <julia@diku.dk>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NVegard Nossum <vegard.nossum@gmail.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      52fd8ca6
  16. 30 7月, 2008 1 次提交
  17. 27 7月, 2008 1 次提交
    • F
      dma-mapping: add the device argument to dma_mapping_error() · 8d8bb39b
      FUJITA Tomonori 提交于
      Add per-device dma_mapping_ops support for CONFIG_X86_64 as POWER
      architecture does:
      
      This enables us to cleanly fix the Calgary IOMMU issue that some devices
      are not behind the IOMMU (http://lkml.org/lkml/2008/5/8/423).
      
      I think that per-device dma_mapping_ops support would be also helpful for
      KVM people to support PCI passthrough but Andi thinks that this makes it
      difficult to support the PCI passthrough (see the above thread).  So I
      CC'ed this to KVM camp.  Comments are appreciated.
      
      A pointer to dma_mapping_ops to struct dev_archdata is added.  If the
      pointer is non NULL, DMA operations in asm/dma-mapping.h use it.  If it's
      NULL, the system-wide dma_ops pointer is used as before.
      
      If it's useful for KVM people, I plan to implement a mechanism to register
      a hook called when a new pci (or dma capable) device is created (it works
      with hot plugging).  It enables IOMMUs to set up an appropriate
      dma_mapping_ops per device.
      
      The major obstacle is that dma_mapping_error doesn't take a pointer to the
      device unlike other DMA operations.  So x86 can't have dma_mapping_ops per
      device.  Note all the POWER IOMMUs use the same dma_mapping_error function
      so this is not a problem for POWER but x86 IOMMUs use different
      dma_mapping_error functions.
      
      The first patch adds the device argument to dma_mapping_error.  The patch
      is trivial but large since it touches lots of drivers and dma-mapping.h in
      all the architecture.
      
      This patch:
      
      dma_mapping_error() doesn't take a pointer to the device unlike other DMA
      operations.  So we can't have dma_mapping_ops per device.
      
      Note that POWER already has dma_mapping_ops per device but all the POWER
      IOMMUs use the same dma_mapping_error function.  x86 IOMMUs use device
      argument.
      
      [akpm@linux-foundation.org: fix sge]
      [akpm@linux-foundation.org: fix svc_rdma]
      [akpm@linux-foundation.org: build fix]
      [akpm@linux-foundation.org: fix bnx2x]
      [akpm@linux-foundation.org: fix s2io]
      [akpm@linux-foundation.org: fix pasemi_mac]
      [akpm@linux-foundation.org: fix sdhci]
      [akpm@linux-foundation.org: build fix]
      [akpm@linux-foundation.org: fix sparc]
      [akpm@linux-foundation.org: fix ibmvscsi]
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: Muli Ben-Yehuda <muli@il.ibm.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Avi Kivity <avi@qumranet.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8d8bb39b
  18. 26 7月, 2008 1 次提交
  19. 25 7月, 2008 5 次提交
  20. 23 7月, 2008 6 次提交