1. 20 2月, 2016 1 次提交
  2. 12 2月, 2016 1 次提交
  3. 11 2月, 2016 2 次提交
  4. 08 2月, 2016 5 次提交
  5. 20 1月, 2016 1 次提交
    • D
      RDMA/be2net: Remove open and close entry points · 9781808c
      Devesh Sharma 提交于
      Recently Dough Ledford reported a deadlock happening
      between ocrdma-load sequence and NetworkManager service
      issueing "open" on be2net interface.
      
      The deadlock happens when any be2net hook (e.g. open/close) is called
      in parallel to insmod ocrdma.ko.
      
      A. be2net is sending administrative open/close event to ocrdma holding
         device_list_mutex. It does this from ndo_open/ndo_stop hooks of be2net.
         So sequence of locks is rtnl_lock---> device_list lock
      
      B.  When new ocrdma roce device gets registered, infiniband stack now
          takes rtnl_lock in ib_register_device() in GID initialization routines.
          So sequence of locks in this path is device_list lock ---> rtnl_lock.
      
      This improper locking sequence causes deadlock.
      
      In order to resolve the above deadlock condition, ocrdma intorduced a
      patch to stop listening to administrative open/close events generated from
      be2net driver. It now depends on link-state-change async-event generated from
      CNA. This change leaves behind dead code which used to generate administrative
      open/close events. This patch cleans-up all that dead code from be2net.
      Reported-by: NDoug Ledford <dledford@redhat.com>
      CC: Sathya Perla <sathya.perla@avagotech.com>
      Signed-off-by: NPadmanabh Ratnakar <padmanabh.ratnakar@avagotech.com>
      Signed-off-by: NSelvin Xavier <selvin.xavier@avagotech.com>
      Signed-off-by: NDevesh Sharma <devesh.sharma@avagotech.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      9781808c
  6. 31 12月, 2015 6 次提交
  7. 29 12月, 2015 1 次提交
    • D
      RDMA/be2net: Remove open and close entry points · f41647ef
      Devesh Sharma 提交于
      Recently Dough Ledford reported a deadlock happening
      between ocrdma-load sequence and NetworkManager service
      issueing "open" on be2net interface.
      
      The deadlock happens when any be2net hook (e.g. open/close) is called
      in parallel to insmod ocrdma.ko.
      
      A. be2net is sending administrative open/close event to ocrdma holding
         device_list_mutex. It does this from ndo_open/ndo_stop hooks of be2net.
         So sequence of locks is rtnl_lock---> device_list lock
      
      B.  When new ocrdma roce device gets registered, infiniband stack now
          takes rtnl_lock in ib_register_device() in GID initialization routines.
          So sequence of locks in this path is device_list lock ---> rtnl_lock.
      
      This improper locking sequence causes deadlock.
      
      In order to resolve the above deadlock condition, ocrdma intorduced a
      patch to stop listening to administrative open/close events generated from
      be2net driver. It now depends on link-state-change async-event generated from
      CNA. This change leaves behind dead code which used to generate administrative
      open/close events. This patch cleans-up all that dead code from be2net.
      Reported-by: NDoug Ledford <dledford@redhat.com>
      CC: Sathya Perla <sathya.perla@avagotech.com>
      Signed-off-by: NPadmanabh Ratnakar <padmanabh.ratnakar@avagotech.com>
      Signed-off-by: NSelvin Xavier <selvin.xavier@avagotech.com>
      Signed-off-by: NDevesh Sharma <devesh.sharma@avagotech.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      f41647ef
  8. 19 12月, 2015 1 次提交
  9. 16 12月, 2015 1 次提交
    • T
      net: Rename NETIF_F_ALL_CSUM to NETIF_F_CSUM_MASK · a188222b
      Tom Herbert 提交于
      The name NETIF_F_ALL_CSUM is a misnomer. This does not correspond to the
      set of features for offloading all checksums. This is a mask of the
      checksum offload related features bits. It is incorrect to set both
      NETIF_F_HW_CSUM and NETIF_F_IP_CSUM or NETIF_F_IPV6 at the same time for
      features of a device.
      
      This patch:
        - Changes instances of NETIF_F_ALL_CSUM to NETIF_F_CSUM_MASK (where
          NETIF_F_ALL_CSUM is being used as a mask).
        - Changes bonding, sfc/efx, ipvlan, macvlan, vlan, and team drivers to
          use NEITF_F_HW_CSUM in features list instead of NETIF_F_ALL_CSUM.
      Signed-off-by: NTom Herbert <tom@herbertland.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a188222b
  10. 19 11月, 2015 2 次提交
    • E
      net: provide generic busy polling to all NAPI drivers · 93d05d4a
      Eric Dumazet 提交于
      NAPI drivers no longer need to observe a particular protocol
      to benefit from busy polling (CONFIG_NET_RX_BUSY_POLL=y)
      
      napi_hash_add() and napi_hash_del() are automatically called
      from core networking stack, respectively from
      netif_napi_add() and netif_napi_del()
      
      This patch depends on free_netdev() and netif_napi_del() being
      called from process context, which seems to be the norm.
      
      Drivers might still prefer to call napi_hash_del() on their
      own, since they might combine all the rcu grace periods into
      a single one, knowing their NAPI structures lifetime, while
      core networking stack has no idea of a possible combining.
      
      Once this patch proves to not bring serious regressions,
      we will cleanup drivers to either remove napi_hash_del()
      or provide appropriate rcu grace periods combining.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      93d05d4a
    • E
      net: move skb_mark_napi_id() into core networking stack · 93f93a44
      Eric Dumazet 提交于
      We would like to automatically provide busy polling support
      to all NAPI drivers, without them having to implement anything.
      
      skb_mark_napi_id() can be called from napi_gro_receive() and
      napi_get_frags().
      
      Few drivers are still calling skb_mark_napi_id() because
      they use netif_receive_skb(). They should eventually call
      napi_gro_receive() instead. I will leave this to drivers
      maintainers.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      93f93a44
  11. 17 11月, 2015 1 次提交
  12. 13 10月, 2015 3 次提交
  13. 18 9月, 2015 1 次提交
  14. 18 8月, 2015 1 次提交
    • I
      be2net: avoid vxlan offloading on multichannel configs · af19e686
      Ivan Vecera 提交于
      VxLAN offloading is not functional if the NIC is running in multichannel
      mode (UMC, FLEX-10, VNIC...). Enabling this additionally kills whole
      connectivity through the NIC and the device needs to be down and up to
      restore it. The firmware should take care about it and does not allow
      the conversion of interface to tunnel type (be_cmd_manage_iface) or should
      support VxLAN offloading if multichannel config is enabled.
      I have tested this on the latest available firmware (10.6.144.21).
      
      Result:
      [root@sm-04 ~]# ip link set enp5s0f0 up[root@sm-04 ~]# ip addr add 172.30.10.50/24 dev enp5s0f0
      [root@sm-04 ~]# ping -c 3 172.30.10.254PING 172.30.10.254 (172.30.10.254) 56(84) bytes of data.
      64 bytes from 172.30.10.254: icmp_seq=1 ttl=64 time=0.317 ms
      64 bytes from 172.30.10.254: icmp_seq=2 ttl=64 time=0.187 ms
      64 bytes from 172.30.10.254: icmp_seq=3 ttl=64 time=0.188 ms
      
       --- 172.30.10.254 ping statistics ---
      3 packets transmitted, 3 received, 0% packet loss, time 2000ms
      rtt min/avg/max/mdev = 0.187/0.230/0.317/0.063 ms
      [root@sm-04 ~]# ip link add link enp5s0f0 vxlan10 type vxlan id 10 remote 172.30.10.60 dstport 4789
      [root@sm-04 ~]# ip link set vxlan10 up
      [ 7900.442811] be2net 0000:05:00.0: Enabled VxLAN offloads for UDP port 4789
      [ 7900.455722] be2net 0000:05:00.1: Enabled VxLAN offloads for UDP port 4789
      [ 7900.468635] be2net 0000:05:00.2: Enabled VxLAN offloads for UDP port 4789
      [ 7900.481553] be2net 0000:05:00.3: Enabled VxLAN offloads for UDP port 4789
      [root@sm-04 ~]# ping -c 3 172.30.10.254
      PING 172.30.10.254 (172.30.10.254) 56(84) bytes of data.
      
       --- 172.30.10.254 ping statistics ---
      3 packets transmitted, 0 received, 100% packet loss, time 1999ms
      
      [root@sm-04 ~]# ip link set vxlan10 down
      [ 7959.434093] be2net 0000:05:00.0: Disabled VxLAN offloads for UDP port 4789
      [ 7959.444792] be2net 0000:05:00.1: Disabled VxLAN offloads for UDP port 4789
      [ 7959.455592] be2net 0000:05:00.2: Disabled VxLAN offloads for UDP port 4789
      [ 7959.466416] be2net 0000:05:00.3: Disabled VxLAN offloads for UDP port 4789
      [root@sm-04 ~]# ip link del vxlan10
      [root@sm-04 ~]# ping -c 3 172.30.10.254
      PING 172.30.10.254 (172.30.10.254) 56(84) bytes of data.
      
       --- 172.30.10.254 ping statistics ---
      3 packets transmitted, 0 received, 100% packet loss, time 1999ms
      
      [root@sm-04 ~]# ip link set enp5s0f0 down
      [root@sm-04 ~]# ip link set enp5s0f0 up
      [ 8071.019003] be2net 0000:05:00.0 enp5s0f0: Link is Up
      [root@sm-04 ~]# ping -c 3 172.30.10.254
      PING 172.30.10.254 (172.30.10.254) 56(84) bytes of data.
      64 bytes from 172.30.10.254: icmp_seq=1 ttl=64 time=0.318 ms
      64 bytes from 172.30.10.254: icmp_seq=2 ttl=64 time=0.196 ms
      64 bytes from 172.30.10.254: icmp_seq=3 ttl=64 time=0.194 ms
      
       --- 172.30.10.254 ping statistics ---
      3 packets transmitted, 3 received, 0% packet loss, time 2000ms
      rtt min/avg/max/mdev = 0.194/0.236/0.318/0.057 ms
      
      Cc: Sathya Perla <sathya.perla@avagotech.com>
      Cc: Ajit Khaparde <ajit.khaparde@avagotech.com>
      Cc: Padmanabh Ratnakar <padmanabh.ratnakar@avagotech.com>
      Cc: Sriharsha Basavapatna <sriharsha.basavapatna@avagotech.com>
      Signed-off-by: NIvan Vecera <ivecera@redhat.com>
      Acked-by: NAjit Khaparde <ajit.khaparde@avagotech.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      af19e686
  15. 08 8月, 2015 3 次提交
  16. 30 7月, 2015 1 次提交
  17. 25 7月, 2015 1 次提交
  18. 11 7月, 2015 5 次提交
  19. 23 6月, 2015 1 次提交
    • S
      switchdev; add VLAN support for port's bridge_getlink · 7d4f8d87
      Scott Feldman 提交于
      One more missing piece of the puzzle.  Add vlan dump support to switchdev
      port's bridge_getlink.  iproute2 "bridge vlan show" cmd already knows how
      to show the vlans installed on the bridge and the device , but (until now)
      no one implemented the port vlan part of the netlink PF_BRIDGE:RTM_GETLINK
      msg.  Before this patch, "bridge vlan show":
      
      	$ bridge -c vlan show
      	port    vlan ids
      	sw1p1    30-34			<< bridge side vlans
      		 57
      
      	sw1p1				<< device side vlans (missing)
      
      	sw1p2    57
      
      	sw1p2
      
      	sw1p3
      
      	sw1p4
      
      	br0     None
      
      (When the port is bridged, the output repeats the vlan list for the vlans
      on the bridge side of the port and the vlans on the device side of the
      port.  The listing above show no vlans for the device side even though they
      are installed).
      
      After this patch:
      
      	$ bridge -c vlan show
      	port    vlan ids
      	sw1p1    30-34			<< bridge side vlan
      		 57
      
      	sw1p1    30-34			<< device side vlans
      		 57
      		 3840 PVID
      
      	sw1p2    57
      
      	sw1p2    57
      		 3840 PVID
      
      	sw1p3    3842 PVID
      
      	sw1p4    3843 PVID
      
      	br0     None
      
      I re-used ndo_dflt_bridge_getlink to add vlan fill call-back func.
      switchdev support adds an obj dump for VLAN objects, using the same
      call-back scheme as FDB dump.  Support included for both compressed and
      un-compressed vlan dumps.
      Signed-off-by: NScott Feldman <sfeldma@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7d4f8d87
  20. 08 6月, 2015 1 次提交
  21. 28 5月, 2015 1 次提交
    • R
      cpumask_set_cpu_local_first => cpumask_local_spread, lament · f36963c9
      Rusty Russell 提交于
      da91309e (cpumask: Utility function to set n'th cpu...) created a
      genuinely weird function.  I never saw it before, it went through DaveM.
      (He only does this to make us other maintainers feel better about our own
      mistakes.)
      
      cpumask_set_cpu_local_first's purpose is say "I need to spread things
      across N online cpus, choose the ones on this numa node first"; you call
      it in a loop.
      
      It can fail.  One of the two callers ignores this, the other aborts and
      fails the device open.
      
      It can fail in two ways: allocating the off-stack cpumask, or through a
      convoluted codepath which AFAICT can only occur if cpu_online_mask
      changes.  Which shouldn't happen, because if cpu_online_mask can change
      while you call this, it could return a now-offline cpu anyway.
      
      It contains a nonsensical test "!cpumask_of_node(numa_node)".  This was
      drawn to my attention by Geert, who said this causes a warning on Sparc.
      It sets a single bit in a cpumask instead of returning a cpu number,
      because that's what the callers want.
      
      It could be made more efficient by passing the previous cpu rather than
      an index, but that would be more invasive to the callers.
      
      Fixes: da91309e
      Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (then rebased)
      Tested-by: NAmir Vadai <amirv@mellanox.com>
      Acked-by: NAmir Vadai <amirv@mellanox.com>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      f36963c9