1. 11 5月, 2015 3 次提交
    • M
      bonding: Implement user key part of port_key in an AD system. · d22a5fc0
      Mahesh Bandewar 提交于
      The port key has three components - user-key, speed-part, and duplex-part.
      The LSBit is for the duplex-part, next 5 bits are for the speed while the
      remaining 10 bits are the user defined key bits. Get these 10 bits
      from the user-space (through the SysFs interface) and use it to form the
      admin port-key. Allowed range for the user-key is 0 - 1023 (10 bits). If
      it is not provided then use zero for the user-key-bits (default).
      
      It can set using following example code -
      
         # modprobe bonding mode=4
         # usr_port_key=$(( RANDOM & 0x3FF ))
         # echo $usr_port_key > /sys/class/net/bond0/bonding/ad_user_port_key
         # echo +eth1 > /sys/class/net/bond0/bonding/slaves
         ...
         # ip link set bond0 up
      Signed-off-by: NMahesh Bandewar <maheshb@google.com>
      Reviewed-by: NNikolay Aleksandrov <nikolay@redhat.com>
      [jt: * fixed up style issues reported by checkpatch
           * fixed up context from change in ad_actor_sys_prio patch]
      Signed-off-by: NJonathan Toppins <jtoppins@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d22a5fc0
    • M
      bonding: Allow userspace to set actors' macaddr in an AD-system. · 74514957
      Mahesh Bandewar 提交于
      In an AD system, the communication between actor and partner is the
      business between these two entities. In the current setup anyone on the
      same L2 can "guess" the LACPDU contents and then possibly send the
      spoofed LACPDUs and trick the partner causing connectivity issues for
      the AD system. This patch allows to use a random mac-address obscuring
      it's identity making it harder for someone in the L2 is do the same thing.
      
      This patch allows user-space to choose the mac-address for the AD-system.
      This mac-address can not be NULL or a Multicast. If the mac-address is set
      from user-space; kernel will honor it and will not overwrite it. In the
      absence (value from user space); the logic will default to using the
      masters' mac as the mac-address for the AD-system.
      
      It can be set using example code below -
      
         # modprobe bonding mode=4
         # sys_mac_addr=$(printf '%02x:%02x:%02x:%02x:%02x:%02x' \
                          $(( (RANDOM & 0xFE) | 0x02 )) \
                          $(( RANDOM & 0xFF )) \
                          $(( RANDOM & 0xFF )) \
                          $(( RANDOM & 0xFF )) \
                          $(( RANDOM & 0xFF )) \
                          $(( RANDOM & 0xFF )))
         # echo $sys_mac_addr > /sys/class/net/bond0/bonding/ad_actor_system
         # echo +eth1 > /sys/class/net/bond0/bonding/slaves
         ...
         # ip link set bond0 up
      Signed-off-by: NMahesh Bandewar <maheshb@google.com>
      Reviewed-by: NNikolay Aleksandrov <nikolay@redhat.com>
      [jt: fixed up style issues reported by checkpatch]
      Signed-off-by: NJonathan Toppins <jtoppins@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      74514957
    • M
      bonding: Allow userspace to set actors' system_priority in AD system · 6791e466
      Mahesh Bandewar 提交于
      This patch allows user to randomize the system-priority in an ad-system.
      The allowed range is 1 - 0xFFFF while default value is 0xFFFF. If user
      does not specify this value, the system defaults to 0xFFFF, which is
      what it was before this patch.
      
      Following example code could set the value -
          # modprobe bonding mode=4
          # sys_prio=$(( 1 + RANDOM + RANDOM ))
          # echo $sys_prio > /sys/class/net/bond0/bonding/ad_actor_sys_prio
          # echo +eth1 > /sys/class/net/bond0/bonding/slaves
          ...
          # ip link set bond0 up
      Signed-off-by: NMahesh Bandewar <maheshb@google.com>
      Reviewed-by: NNikolay Aleksandrov <nikolay@redhat.com>
      [jt: * fixed up style issues reported by checkpatch
           * changed how the default value is set in bond_check_params(), this
             makes the default consistent between what gets set for a new bond
             and what the default is claimed to be in the bonding options.]
      Signed-off-by: NJonathan Toppins <jtoppins@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6791e466
  2. 30 4月, 2015 1 次提交
  3. 27 4月, 2015 1 次提交
  4. 01 4月, 2015 1 次提交
  5. 30 3月, 2015 1 次提交
  6. 07 3月, 2015 1 次提交
  7. 21 2月, 2015 1 次提交
  8. 10 2月, 2015 1 次提交
  9. 05 2月, 2015 2 次提交
  10. 02 2月, 2015 1 次提交
  11. 28 1月, 2015 3 次提交
  12. 26 1月, 2015 1 次提交
    • E
      bonding: handle more gso types · 24f87d4c
      Eric Dumazet 提交于
      In commit 5a7baa78 ("bonding: Advertize vxlan offload features when
      supported"), Or Gerlitz added support conditional vxlan offload.
      
      In this patch I also add support for all kind of tunnels,
      but we allow a bonding device to not require segmentation,
      as it is always better to make this segmentation at the very last stage,
      if a particular slave device requires it.
      
      Tested:
      
       Setup a GRE tunnel,
       on a physical NIC not having tx-gre-segmentation.
       Results on bnx2x are even better, as we no longer have to segment
       in software.
      
      ethtool -K bond0 tx-gre-segmentation off
      
      super_netperf 50 --google-pacing-rate 30000000 -H 10.7.8.152 -l 15
      7538.32
      
      ethtool -K bond0 tx-gre-segmentation on
      
      super_netperf 50 --google-pacing-rate 30000000 -H 10.7.8.152 -l 15
      10200.5
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Or Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      24f87d4c
  13. 27 12月, 2014 1 次提交
  14. 22 11月, 2014 2 次提交
  15. 20 11月, 2014 1 次提交
    • N
      bonding: fix curr_active_slave/carrier with loadbalance arp monitoring · b8e4500f
      Nikolay Aleksandrov 提交于
      Since commit 6fde8f03 ("bonding: fix locking in
      bond_loadbalance_arp_mon()") we can have a stale bond carrier state and
      stale curr_active_slave when using arp monitoring in loadbalance modes. The
      reason is that in bond_loadbalance_arp_mon() we can't have
      do_failover == true but slave_state_changed == false, whenever do_failover
      is true then slave_state_changed is also true. Then the following piece
      from bond_loadbalance_arp_mon():
                      if (slave_state_changed) {
                              bond_slave_state_change(bond);
                              if (BOND_MODE(bond) == BOND_MODE_XOR)
                                      bond_update_slave_arr(bond, NULL);
                      } else if (do_failover) {
                              block_netpoll_tx();
                              bond_select_active_slave(bond);
                              unblock_netpoll_tx();
                      }
      
      will execute only the first branch, always and regardless of do_failover.
      Since these two events aren't related in such way, we need to decouple and
      consider them separately.
      
      For example this issue could lead to the following result:
      Bonding Mode: load balancing (round-robin)
      *MII Status: down*
      MII Polling Interval (ms): 0
      Up Delay (ms): 0
      Down Delay (ms): 0
      ARP Polling Interval (ms): 100
      ARP IP target/s (n.n.n.n form): 192.168.9.2
      
      Slave Interface: ens12
      *MII Status: up*
      Speed: 10000 Mbps
      Duplex: full
      Link Failure Count: 2
      Permanent HW addr: 00:0f:53:01:42:2c
      Slave queue ID: 0
      
      Slave Interface: eth1
      *MII Status: up*
      Speed: Unknown
      Duplex: Unknown
      Link Failure Count: 70
      Permanent HW addr: 52:54:00:2f:0f:8e
      Slave queue ID: 0
      
      Since some interfaces are up, then the status of the bond should also be
      up, but it will never change unless something invokes bond_set_carrier()
      (i.e. enslave, bond_select_active_slave etc). Now, if I force the
      calling of bond_select_active_slave via for example changing
      primary_reselect (it can change in any mode), then the MII status goes to
      "up" because it calls bond_select_active_slave() which should've been done
      from bond_loadbalance_arp_mon() itself.
      
      CC: Veaceslav Falico <vfalico@gmail.com>
      CC: Jay Vosburgh <j.vosburgh@gmail.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: Ding Tianhong <dingtianhong@huawei.com>
      
      Fixes: 6fde8f03 ("bonding: fix locking in bond_loadbalance_arp_mon()")
      Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Acked-by: NVeaceslav Falico <vfalico@gmail.com>
      Acked-by: NAndy Gospodarek <gospo@cumulusnetworks.com>
      Acked-by: NDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b8e4500f
  16. 14 11月, 2014 1 次提交
    • M
      net: generic dev_disable_lro() stacked device handling · fbe168ba
      Michal Kubeček 提交于
      Large receive offloading is known to cause problems if received packets
      are passed to other host. Therefore the kernel disables it by calling
      dev_disable_lro() whenever a network device is enslaved in a bridge or
      forwarding is enabled for it (or globally). For virtual devices we need
      to disable LRO on the underlying physical device (which is actually
      receiving the packets).
      
      Current dev_disable_lro() code handles this  propagation for a vlan
      (including 802.1ad nested vlan), macvlan or a vlan on top of a macvlan.
      It doesn't handle other stacked devices and their combinations, in
      particular propagation from a bond to its slaves which often causes
      problems in virtualization setups.
      
      As we now have generic data structures describing the upper-lower device
      relationship, dev_disable_lro() can be generalized to disable LRO also
      for all lower devices (if any) once it is disabled for the device
      itself.
      
      For bonding and teaming devices, it is necessary to disable LRO not only
      on current slaves at the moment when dev_disable_lro() is called but
      also on any slave (port) added later.
      
      v2: use lower device links for all devices (including vlan and macvlan)
      Signed-off-by: NMichal Kubecek <mkubecek@suse.cz>
      Acked-by: NVeaceslav Falico <vfalico@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fbe168ba
  17. 11 11月, 2014 1 次提交
  18. 01 11月, 2014 1 次提交
  19. 08 10月, 2014 1 次提交
    • E
      net: better IFF_XMIT_DST_RELEASE support · 02875878
      Eric Dumazet 提交于
      Testing xmit_more support with netperf and connected UDP sockets,
      I found strange dst refcount false sharing.
      
      Current handling of IFF_XMIT_DST_RELEASE is not optimal.
      
      Dropping dst in validate_xmit_skb() is certainly too late in case
      packet was queued by cpu X but dequeued by cpu Y
      
      The logical point to take care of drop/force is in __dev_queue_xmit()
      before even taking qdisc lock.
      
      As Julian Anastasov pointed out, need for skb_dst() might come from some
      packet schedulers or classifiers.
      
      This patch adds new helper to cleanly express needs of various drivers
      or qdiscs/classifiers.
      
      Drivers that need skb_dst() in their ndo_start_xmit() should call
      following helper in their setup instead of the prior :
      
      	dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
      ->
      	netif_keep_dst(dev);
      
      Instead of using a single bit, we use two bits, one being
      eventually rebuilt in bonding/team drivers.
      
      The other one, is permanent and blocks IFF_XMIT_DST_RELEASE being
      rebuilt in bonding/team. Eventually, we could add something
      smarter later.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Julian Anastasov <ja@ssi.bg>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      02875878
  20. 07 10月, 2014 1 次提交
    • M
      bonding: Simplify the xmit function for modes that use xmit_hash · ee637714
      Mahesh Bandewar 提交于
      Earlier change to use usable slave array for TLB mode had an additional
      performance advantage. So extending the same logic to all other modes
      that use xmit-hash for slave selection (viz 802.3AD, and XOR modes).
      Also consolidating this with the earlier TLB change.
      
      The main idea is to build the usable slaves array in the control path
      and use that array for slave selection during xmit operation.
      
      Measured performance in a setup with a bond of 4x1G NICs with 200
      instances of netperf for the modes involved (3ad, xor, tlb)
      cmd: netperf -t TCP_RR -H <TargetHost> -l 60 -s 5
      
      Mode        TPS-Before   TPS-After
      
      802.3ad   : 468,694      493,101
      TLB (lb=0): 392,583      392,965
      XOR       : 475,696      484,517
      Signed-off-by: NMahesh Bandewar <maheshb@google.com>
      Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ee637714
  21. 30 9月, 2014 1 次提交
    • A
      bonding: make global bonding stats more reliable · 5f0c5f73
      Andy Gospodarek 提交于
      As the code stands today, bonding stats are based simply on the stats
      from the member interfaces.  If a member was to be removed from a bond,
      the stats would instantly drop.  This would be confusing to an admin
      would would suddonly see interface stats drop while traffic is still
      flowing.
      
      In addition to preventing the stats drops mentioned above, new members
      will now be added to the bond and only traffic received after the member
      was added to the bond will be counted as part of bonding stats.  Bonding
      counters will also be updated when any slaves are dropped to make sure
      the reported stats are reliable.
      
      v2: Changes suggested by Nik to properly allocate/free stats memory.
      v3: Properly destroy workqueue and fix netlink configuration path.
      v4: Moved cached stats into bonding and slave structs as there does not
      seem to be a complexity/performance benefit to using alloc'd memory vs
      in-struct memory.
      Signed-off-by: NAndy Gospodarek <gospo@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5f0c5f73
  22. 23 9月, 2014 2 次提交
  23. 16 9月, 2014 2 次提交
  24. 14 9月, 2014 6 次提交
    • N
      bonding: fix div by zero while enslaving and transmitting · 9a72c2da
      Nikolay Aleksandrov 提交于
      The problem is that the slave is first linked and slave_cnt is
      incremented afterwards leading to a div by zero in the modes that use it
      as a modulus. What happens is that in bond_start_xmit()
      bond_has_slaves() is used to evaluate further transmission and it becomes
      true after the slave is linked in, but when slave_cnt is used in the xmit
      path it is still 0, so fetch it once and transmit based on that. Since
      it is used only in round-robin and XOR modes, the fix is only for them.
      Thanks to Eric Dumazet for pointing out the fault in my first try to fix
      this.
      
      Call trace (took it out of net-next kernel, but it's the same with net):
      [46934.330038] divide error: 0000 [#1] SMP
      [46934.330041] Modules linked in: bonding(O) 9p fscache
      snd_hda_codec_generic crct10dif_pclmul
      [46934.330041] bond0: Enslaving eth1 as an active interface with an up
      link
      [46934.330051]  ppdev joydev crc32_pclmul crc32c_intel 9pnet_virtio
      ghash_clmulni_intel snd_hda_intel 9pnet snd_hda_controller parport_pc
      serio_raw pcspkr snd_hda_codec parport virtio_balloon virtio_console
      snd_hwdep snd_pcm pvpanic i2c_piix4 snd_timer i2ccore snd soundcore
      virtio_blk virtio_net virtio_pci virtio_ring virtio ata_generic
      pata_acpi floppy [last unloaded: bonding]
      [46934.330053] CPU: 1 PID: 3382 Comm: ping Tainted: G           O
      3.17.0-rc4+ #27
      [46934.330053] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
      [46934.330054] task: ffff88005aebf2c0 ti: ffff88005b728000 task.ti:
      ffff88005b728000
      [46934.330059] RIP: 0010:[<ffffffffa0198c33>]  [<ffffffffa0198c33>]
      bond_start_xmit+0x1c3/0x450 [bonding]
      [46934.330060] RSP: 0018:ffff88005b72b7f8  EFLAGS: 00010246
      [46934.330060] RAX: 0000000000000679 RBX: ffff88004b077000 RCX:
      000000000000002a
      [46934.330061] RDX: 0000000000000000 RSI: ffff88004b3f0500 RDI:
      ffff88004b077940
      [46934.330061] RBP: ffff88005b72b830 R08: 00000000000000c0 R09:
      ffff88004a83e000
      [46934.330062] R10: 000000000000ffff R11: ffff88004b1f12c0 R12:
      ffff88004b3f0500
      [46934.330062] R13: ffff88004b3f0500 R14: 000000000000002a R15:
      ffff88004b077940
      [46934.330063] FS:  00007fbd91a4c740(0000) GS:ffff88005f080000(0000)
      knlGS:0000000000000000
      [46934.330064] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [46934.330064] CR2: 00007f803a8bb000 CR3: 000000004b2c9000 CR4:
      00000000000406e0
      [46934.330069] Stack:
      [46934.330071]  ffffffff811e6169 00000000e772fa05 ffff88004b077000
      ffff88004b3f0500
      [46934.330072]  ffffffff81d17d18 000000000000002a 0000000000000000
      ffff88005b72b8a0
      [46934.330073]  ffffffff81620108 ffffffff8161fe0e ffff88005b72b8c4
      ffff88005b302000
      [46934.330073] Call Trace:
      [46934.330077]  [<ffffffff811e6169>] ?
      __kmalloc_node_track_caller+0x119/0x300
      [46934.330084]  [<ffffffff81620108>] dev_hard_start_xmit+0x188/0x410
      [46934.330086]  [<ffffffff8161fe0e>] ? harmonize_features+0x2e/0x90
      [46934.330088]  [<ffffffff81620b06>] __dev_queue_xmit+0x456/0x590
      [46934.330089]  [<ffffffff81620c50>] dev_queue_xmit+0x10/0x20
      [46934.330090]  [<ffffffff8168f022>] arp_xmit+0x22/0x60
      [46934.330091]  [<ffffffff8168f090>] arp_send.part.16+0x30/0x40
      [46934.330092]  [<ffffffff8168f1e5>] arp_solicit+0x115/0x2b0
      [46934.330094]  [<ffffffff8160b5d7>] ? copy_skb_header+0x17/0xa0
      [46934.330096]  [<ffffffff8162875a>] neigh_probe+0x4a/0x70
      [46934.330097]  [<ffffffff8162979c>] __neigh_event_send+0xac/0x230
      [46934.330098]  [<ffffffff8162a00b>] neigh_resolve_output+0x13b/0x220
      [46934.330100]  [<ffffffff8165f120>] ? ip_forward_options+0x1c0/0x1c0
      [46934.330101]  [<ffffffff81660478>] ip_finish_output+0x1f8/0x860
      [46934.330102]  [<ffffffff81661f08>] ip_output+0x58/0x90
      [46934.330103]  [<ffffffff81661602>] ? __ip_local_out+0xa2/0xb0
      [46934.330104]  [<ffffffff81661640>] ip_local_out_sk+0x30/0x40
      [46934.330105]  [<ffffffff81662a66>] ip_send_skb+0x16/0x50
      [46934.330106]  [<ffffffff81662ad3>] ip_push_pending_frames+0x33/0x40
      [46934.330107]  [<ffffffff8168854c>] raw_sendmsg+0x88c/0xa30
      [46934.330110]  [<ffffffff81612b31>] ? skb_recv_datagram+0x41/0x60
      [46934.330111]  [<ffffffff816875a9>] ? raw_recvmsg+0xa9/0x1f0
      [46934.330113]  [<ffffffff816978d4>] inet_sendmsg+0x74/0xc0
      [46934.330114]  [<ffffffff81697a9b>] ? inet_recvmsg+0x8b/0xb0
      [46934.330115] bond0: Adding slave eth2
      [46934.330116]  [<ffffffff8160357c>] sock_sendmsg+0x9c/0xe0
      [46934.330118]  [<ffffffff81603248>] ?
      move_addr_to_kernel.part.20+0x28/0x80
      [46934.330121]  [<ffffffff811b4477>] ? might_fault+0x47/0x50
      [46934.330122]  [<ffffffff816039b9>] ___sys_sendmsg+0x3a9/0x3c0
      [46934.330125]  [<ffffffff8144a14a>] ? n_tty_write+0x3aa/0x530
      [46934.330127]  [<ffffffff810d1ae4>] ? __wake_up+0x44/0x50
      [46934.330129]  [<ffffffff81242b38>] ? fsnotify+0x238/0x310
      [46934.330130]  [<ffffffff816048a1>] __sys_sendmsg+0x51/0x90
      [46934.330131]  [<ffffffff816048f2>] SyS_sendmsg+0x12/0x20
      [46934.330134]  [<ffffffff81738b29>] system_call_fastpath+0x16/0x1b
      [46934.330144] Code: 48 8b 10 4c 89 ee 4c 89 ff e8 aa bc ff ff 31 c0 e9
      1a ff ff ff 0f 1f 00 4c 89 ee 4c 89 ff e8 65 fb ff ff 31 d2 4c 89 ee 4c
      89 ff <f7> b3 64 09 00 00 e8 02 bd ff ff 31 c0 e9 f2 fe ff ff 0f 1f 00
      [46934.330146] RIP  [<ffffffffa0198c33>] bond_start_xmit+0x1c3/0x450
      [bonding]
      [46934.330146]  RSP <ffff88005b72b7f8>
      
      CC: Eric Dumazet <eric.dumazet@gmail.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: Jay Vosburgh <j.vosburgh@gmail.com>
      CC: Veaceslav Falico <vfalico@gmail.com>
      Fixes: 278b2083 ("bonding: initial RCU conversion")
      Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9a72c2da
    • N
      bonding: adjust locking comments · 8c0bc550
      Nikolay Aleksandrov 提交于
      Now that locks have been removed, remove some unnecessary comments and
      adjust others to reflect reality. Also add a comment to "mode_lock" to
      describe its current users and give a brief summary why they need it.
      Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8c0bc550
    • N
      bonding: 3ad: convert to bond->mode_lock · e470259f
      Nikolay Aleksandrov 提交于
      Now that we have bond->mode_lock, we can remove the state_machine_lock
      and use it in its place. There're no fast paths requiring the per-port
      spinlocks so it should be okay to consolidate them into mode_lock.
      Also move it inside the unbinding function as we don't want to expose
      mode_lock outside of the specific modes.
      Suggested-by: NJay Vosburgh <jay.vosburgh@canonical.com>
      Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e470259f
    • N
      bonding: alb: convert to bond->mode_lock · 4bab16d7
      Nikolay Aleksandrov 提交于
      The ALB/TLB specific spinlocks are no longer necessary as we now have
      bond->mode_lock for this purpose, so convert them and remove them from
      struct alb_bond_info.
      Also remove the unneeded lock/unlock functions and use spin_lock/unlock
      directly.
      Suggested-by: NJay Vosburgh <jay.vosburgh@canonical.com>
      Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4bab16d7
    • N
      bonding: convert curr_slave_lock to a spinlock and rename it · b7435628
      Nikolay Aleksandrov 提交于
      curr_slave_lock is now a misleading name, a much better name is
      mode_lock as it'll be used for each mode's purposes and it's no longer
      necessary to use a rwlock, a simple spinlock is enough.
      Suggested-by: NJay Vosburgh <jay.vosburgh@canonical.com>
      Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b7435628
    • N
      bonding: clean curr_slave_lock use · 1c72cfdc
      Nikolay Aleksandrov 提交于
      Mostly all users of curr_slave_lock already have RTNL as we've discussed
      previously so there's no point in using it, the one case where the lock
      must stay is the 3ad code, in fact it's the only one.
      It's okay to remove it from bond_do_fail_over_mac() as it's called with
      RTNL and drops the curr_slave_lock anyway.
      bond_change_active_slave() is one of the main places where
      curr_slave_lock was used, it's okay to remove it as all callers use RTNL
      these days before calling it, that's why we move the ASSERT_RTNL() in
      the beginning to catch any potential offenders to this rule.
      The RTNL argument actually applies to all of the places where
      curr_slave_lock has been removed from in this patch.
      Also remove the unnecessary bond_deref_active_protected() macro and use
      rtnl_dereference() instead.
      Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1c72cfdc
  25. 10 9月, 2014 3 次提交