1. 13 3月, 2014 2 次提交
  2. 07 3月, 2014 2 次提交
    • A
      net/mlx4_core: mlx4_init_slave() shouldn't access comm channel before PF is ready · 97989356
      Amir Vadai 提交于
      Currently, the PF call to pci_enable_sriov from the PF probe function
      stalls for 10 seconds times the number of VFs probed on the host. This
      happens because the way for such VFs to determine of the PF
      initialization finished, is by attempting to issue reset on the
      comm-channel and get timeout (after 10s).
      
      The PF probe function is called from a kenernel workqueue, and therefore
      during that time, rcu lock is being held and kernel's workqueue is
      stalled. This blocks other processes that try to use the workqueue
      or rcu lock.  For example, interface renaming which is calling
      rcu_synchronize is blocked, and timedout by systemd.
      
      Changed mlx4_init_slave() to allow VF probed on the host to immediatly
      detect that the PF is not ready, and return EPROBE_DEFER instantly.
      
      Only when the PF finishes the initialization, allow such VFs to
      access the comm channel.
      
      This issue and fix are relevant only for probed VFs on the hypervisor,
      there is no way to pass this information to a VM until comm channel is
      ready, so in a VM, if PF is not ready, the first command will be timedout
      after 10 seconds and return EPROBE_DEFER.
      Signed-off-by: NAmir Vadai <amirv@mellanox.com>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      97989356
    • A
      net/mlx4_core: Fix memory access error in mlx4_QUERY_DEV_CAP_wrapper() · 57352ef4
      Amir Vadai 提交于
      Fix a regression introduced by [1]. outbox was accessed instead of
      outbox->buf. Typo was copy-pasted to [2] and [3].
      
      [1] - cc1ade94 mlx4_core: Disable memory windows for virtual functions
      [2] - 4de65803 mlx4_core: Add support for steerable IB UD QPs
      [3] - 7ffdf726 net/mlx4_core: Add basic support for TCP/IP offloads under
            tunneling
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NAmir Vadai <amirv@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      57352ef4
  3. 06 3月, 2014 1 次提交
  4. 26 2月, 2014 1 次提交
  5. 17 2月, 2014 1 次提交
  6. 14 2月, 2014 1 次提交
  7. 23 1月, 2014 8 次提交
  8. 22 1月, 2014 1 次提交
    • M
      net/mlx4_core: Remove unnecessary validation for port number · 6cd28f04
      Moni Shoua 提交于
      This is a fix to a regression introduced by commit:
      "982290a7 net/mlx4_core: Check port number for validity
      before accessing data"
      
      IPoIB could not attach to multicast group and we get this in dmesg:
      [144214.145008] ib0: failed to attach to multicast group, ret = -22
      [144214.145016] ib0: couldn't attach QP to multicast group ff12:401b:ffff:0000:0000:0000:ffff:ffff
      [144214.145019] ib0: multicast join failed for ff12:401b:ffff:0000:0000:0000:ffff:ffff, status -22
      
      The cause to the problem is because port is extracted from gid[5].
      Which is only valid for Ethernet.
      Removed this validation in mlx4_qp_attach_common(), which is accessed
      from both Ethernet and IB flows.
      Error flow for bad port value in Ethernet is already exists in that
      function.
      Signed-off-by: NMoni Shoua <monis@mellanox.co.il>
      Signed-off-by: NMatan Barak <matanb@mellanox.com>
      Signed-off-by: NAmir Vadai <amirv@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6cd28f04
  9. 19 1月, 2014 1 次提交
  10. 17 1月, 2014 3 次提交
    • P
      net/mlx4_core: clean up srq_res_start_move_to() · f088cbb8
      Paul Bolle 提交于
      Building resource_tracker.o triggers a GCC warning:
          drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function 'mlx4_HW2SW_SRQ_wrapper':
          drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:3202:17: warning: 'srq' may be used uninitialized in this function [-Wmaybe-uninitialized]
            atomic_dec(&srq->mtt->ref_count);
                           ^
      
      This is a false positive. But a cleanup of srq_res_start_move_to() can
      help GCC here. The code currently uses a switch statement where a plain
      if/else would do, since only two of the switch's four cases can ever
      occur. Dropping that switch makes the warning go away.
      
      While we're at it, add some missing braces, and convert state to the
      correct type.
      Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f088cbb8
    • P
      net/mlx4_core: clean up cq_res_start_move_to() · c9218a9e
      Paul Bolle 提交于
      Building resource_tracker.o triggers a GCC warning:
          drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function 'mlx4_HW2SW_CQ_wrapper':
          drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:3019:16: warning: 'cq' may be used uninitialized in this function [-Wmaybe-uninitialized]
            atomic_dec(&cq->mtt->ref_count);
                          ^
      
      This is a false positive. But a cleanup of cq_res_start_move_to() can
      help GCC here. The code currently uses a switch statement where an
      if/else construct would do too, since only two of the switch's four
      cases can ever occur. Dropping that switch makes the warning go away.
      
      While we're at it, add some missing braces.
      Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c9218a9e
    • P
      drivers/net: delete non-required instances of include <linux/init.h> · a81ab36b
      Paul Gortmaker 提交于
      None of these files are actually using any __init type directives
      and hence don't need to include <linux/init.h>.   Most are just a
      left over from __devinit and __cpuinit removal, or simply due to
      code getting copied from one driver to the next.
      
      This covers everything under drivers/net except for wireless, which
      has been submitted separately.
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a81ab36b
  11. 15 1月, 2014 2 次提交
  12. 14 1月, 2014 1 次提交
  13. 11 1月, 2014 1 次提交
    • J
      net: core: explicitly select a txq before doing l2 forwarding · f663dd9a
      Jason Wang 提交于
      Currently, the tx queue were selected implicitly in ndo_dfwd_start_xmit(). The
      will cause several issues:
      
      - NETIF_F_LLTX were removed for macvlan, so txq lock were done for macvlan
        instead of lower device which misses the necessary txq synchronization for
        lower device such as txq stopping or frozen required by dev watchdog or
        control path.
      - dev_hard_start_xmit() was called with NULL txq which bypasses the net device
        watchdog.
      - dev_hard_start_xmit() does not check txq everywhere which will lead a crash
        when tso is disabled for lower device.
      
      Fix this by explicitly introducing a new param for .ndo_select_queue() for just
      selecting queues in the case of l2 forwarding offload. netdev_pick_tx() was also
      extended to accept this parameter and dev_queue_xmit_accel() was used to do l2
      forwarding transmission.
      
      With this fixes, NETIF_F_LLTX could be preserved for macvlan and there's no need
      to check txq against NULL in dev_hard_start_xmit(). Also there's no need to keep
      a dedicated ndo_dfwd_start_xmit() and we can just reuse the code of
      dev_queue_xmit() to do the transmission.
      
      In the future, it was also required for macvtap l2 forwarding support since it
      provides a necessary synchronization method.
      
      Cc: John Fastabend <john.r.fastabend@intel.com>
      Cc: Neil Horman <nhorman@tuxdriver.com>
      Cc: e1000-devel@lists.sourceforge.net
      Signed-off-by: NJason Wang <jasowang@redhat.com>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      Acked-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f663dd9a
  14. 08 1月, 2014 2 次提交
  15. 06 1月, 2014 1 次提交
  16. 02 1月, 2014 2 次提交
  17. 01 1月, 2014 3 次提交
  18. 20 12月, 2013 7 次提交