1. 12 8月, 2019 1 次提交
  2. 26 7月, 2019 2 次提交
  3. 25 7月, 2019 1 次提交
  4. 22 6月, 2019 1 次提交
  5. 21 6月, 2019 2 次提交
  6. 12 6月, 2019 2 次提交
  7. 11 6月, 2019 3 次提交
  8. 22 5月, 2019 2 次提交
  9. 21 5月, 2019 1 次提交
  10. 03 5月, 2019 1 次提交
  11. 09 4月, 2019 2 次提交
  12. 08 4月, 2019 1 次提交
    • W
      drivers: Remove explicit invocations of mmiowb() · fb24ea52
      Will Deacon 提交于
      mmiowb() is now implied by spin_unlock() on architectures that require
      it, so there is no reason to call it from driver code. This patch was
      generated using coccinelle:
      
      	@mmiowb@
      	@@
      	- mmiowb();
      
      and invoked as:
      
      $ for d in drivers include/linux/qed sound; do \
      spatch --include-headers --sp-file mmiowb.cocci --dir $d --in-place; done
      
      NOTE: mmiowb() has only ever guaranteed ordering in conjunction with
      spin_unlock(). However, pairing each mmiowb() removal in this patch with
      the corresponding call to spin_unlock() is not at all trivial, so there
      is a small chance that this change may regress any drivers incorrectly
      relying on mmiowb() to order MMIO writes between CPUs using lock-free
      synchronisation. If you've ended up bisecting to this commit, you can
      reintroduce the mmiowb() calls using wmb() instead, which should restore
      the old behaviour on all architectures other than some esoteric ia64
      systems.
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      fb24ea52
  13. 02 4月, 2019 3 次提交
  14. 26 3月, 2019 1 次提交
  15. 18 3月, 2019 1 次提交
  16. 27 2月, 2019 1 次提交
  17. 23 2月, 2019 2 次提交
    • L
      RDMA: Handle ucontext allocations by IB/core · a2a074ef
      Leon Romanovsky 提交于
      Following the PD conversion patch, do the same for ucontext allocations.
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      a2a074ef
    • H
      IB/mlx4: Increase the timeout for CM cache · 2612d723
      Håkon Bugge 提交于
      Using CX-3 virtual functions, either from a bare-metal machine or
      pass-through from a VM, MAD packets are proxied through the PF driver.
      
      Since the VF drivers have separate name spaces for MAD Transaction Ids
      (TIDs), the PF driver has to re-map the TIDs and keep the book keeping
      in a cache.
      
      Following the RDMA Connection Manager (CM) protocol, it is clear when
      an entry has to evicted form the cache. But life is not perfect,
      remote peers may die or be rebooted. Hence, it's a timeout to wipe out
      a cache entry, when the PF driver assumes the remote peer has gone.
      
      During workloads where a high number of QPs are destroyed concurrently,
      excessive amount of CM DREQ retries has been observed
      
      The problem can be demonstrated in a bare-metal environment, where two
      nodes have instantiated 8 VFs each. This using dual ported HCAs, so we
      have 16 vPorts per physical server.
      
      64 processes are associated with each vPort and creates and destroys
      one QP for each of the remote 64 processes. That is, 1024 QPs per
      vPort, all in all 16K QPs. The QPs are created/destroyed using the
      CM.
      
      When tearing down these 16K QPs, excessive CM DREQ retries (and
      duplicates) are observed. With some cat/paste/awk wizardry on the
      infiniband_cm sysfs, we observe as sum of the 16 vPorts on one of the
      nodes:
      
      cm_rx_duplicates:
            dreq  2102
      cm_rx_msgs:
            drep  1989
            dreq  6195
             rep  3968
             req  4224
             rtu  4224
      cm_tx_msgs:
            drep  4093
            dreq 27568
             rep  4224
             req  3968
             rtu  3968
      cm_tx_retries:
            dreq 23469
      
      Note that the active/passive side is equally distributed between the
      two nodes.
      
      Enabling pr_debug in cm.c gives tons of:
      
      [171778.814239] <mlx4_ib> mlx4_ib_multiplex_cm_handler: id{slave:
      1,sl_cm_id: 0xd393089f} is NULL!
      
      By increasing the CM_CLEANUP_CACHE_TIMEOUT from 5 to 30 seconds, the
      tear-down phase of the application is reduced from approximately 90 to
      50 seconds. Retries/duplicates are also significantly reduced:
      
      cm_rx_duplicates:
            dreq  2460
      []
      cm_tx_retries:
            dreq  3010
             req    47
      
      Increasing the timeout further didn't help, as these duplicates and
      retries stems from a too short CMA timeout, which was 20 (~4 seconds)
      on the systems. By increasing the CMA timeout to 22 (~17 seconds), the
      numbers fell down to about 10 for both of them.
      
      Adjustment of the CMA timeout is not part of this commit.
      Signed-off-by: NHåkon Bugge <haakon.bugge@oracle.com>
      Acked-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      2612d723
  18. 16 2月, 2019 1 次提交
  19. 09 2月, 2019 1 次提交
  20. 31 1月, 2019 1 次提交
  21. 22 1月, 2019 1 次提交
    • J
      IB/mlx4: Fix using wrong function to destroy sqp AHs under SRIOV · f45f8edb
      Jack Morgenstein 提交于
      The commit cited below replaced rdma_create_ah with
      mlx4_ib_create_slave_ah when creating AHs for the paravirtualized special
      QPs.
      
      However, this change also required replacing rdma_destroy_ah with
      mlx4_ib_destroy_ah in the affected flows.
      
      The commit missed 3 places where rdma_destroy_ah should have been replaced
      with mlx4_ib_destroy_ah.
      
      As a result, the pd usecount was decremented when the ah was destroyed --
      although the usecount was NOT incremented when the ah was created.
      
      This caused the pd usecount to become negative, and resulted in the
      WARN_ON stack trace below when the mlx4_ib.ko module was unloaded:
      
      WARNING: CPU: 3 PID: 25303 at drivers/infiniband/core/verbs.c:329 ib_dealloc_pd+0x6d/0x80 [ib_core]
      Modules linked in: rdma_ucm rdma_cm iw_cm ib_cm ib_umad mlx4_ib(-) ib_uverbs ib_core mlx4_en mlx4_core nfsv3 nfs fscache configfs xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c ipt_REJECT nf_reject_ipv4 tun ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter bridge stp llc dm_mirror dm_region_hash dm_log dm_mod dax rndis_wlan rndis_host coretemp kvm_intel cdc_ether kvm usbnet iTCO_wdt iTCO_vendor_support cfg80211 irqbypass lpc_ich ipmi_si i2c_i801 mii pcspkr i2c_core mfd_core ipmi_devintf i7core_edac ipmi_msghandler ioatdma pcc_cpufreq dca acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables ext4 mbcache jbd2 sr_mod cdrom ata_generic pata_acpi mptsas scsi_transport_sas mptscsih crc32c_intel ata_piix bnx2 mptbase ipv6 crc_ccitt autofs4 [last unloaded: mlx4_core]
      CPU: 3 PID: 25303 Comm: modprobe Tainted: G        W I       5.0.0-rc1-net-mlx4+ #1
      Hardware name: IBM  -[7148ZV6]-/Node 1, System Card, BIOS -[MLE170CUS-1.70]- 09/23/2011
      RIP: 0010:ib_dealloc_pd+0x6d/0x80 [ib_core]
      Code: 00 00 85 c0 75 02 5b c3 80 3d aa 87 03 00 00 75 f5 48 c7 c7 88 d7 8f a0 31 c0 c6 05 98 87 03 00 01 e8 07 4c 79 e0 0f 0b 5b c3 <0f> 0b eb be 0f 0b eb ab 90 66 2e 0f 1f 84 00 00 00 00 00 66 66 66
      RSP: 0018:ffffc90005347e30 EFLAGS: 00010282
      RAX: 00000000ffffffea RBX: ffff8888589e9540 RCX: 0000000000000006
      RDX: 0000000000000006 RSI: ffff88885d57ad40 RDI: 0000000000000000
      RBP: ffff88885b029c00 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000001 R11: 0000000000000004 R12: ffff8887f06c0000
      R13: ffff8887f06c13e8 R14: 0000000000000000 R15: 0000000000000000
      FS:  00007fd6743c6740(0000) GS:ffff88887fcc0000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000ed1038 CR3: 00000007e3156000 CR4: 00000000000006e0
      Call Trace:
       mlx4_ib_close_sriov+0x125/0x180 [mlx4_ib]
       mlx4_ib_remove+0x57/0x1f0 [mlx4_ib]
       mlx4_remove_device+0x92/0xa0 [mlx4_core]
       mlx4_unregister_interface+0x39/0x90 [mlx4_core]
       mlx4_ib_cleanup+0xc/0xd7 [mlx4_ib]
       __x64_sys_delete_module+0x17d/0x290
       ? trace_hardirqs_off_thunk+0x1a/0x1c
       ? do_syscall_64+0x12/0x180
       do_syscall_64+0x4a/0x180
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Fixes: 5e62d5ff ("IB/mlx4: Create slave AH's directly")
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      f45f8edb
  22. 15 1月, 2019 2 次提交
  23. 11 1月, 2019 3 次提交
  24. 21 12月, 2018 1 次提交
  25. 20 12月, 2018 2 次提交
  26. 19 12月, 2018 1 次提交