1. 28 10月, 2013 1 次提交
    • D
      bonding: remove bond read lock for bond_mii_monitor() · 6b6c5261
      dingtianhong 提交于
      The bond slave list may change when the monitor is running, the slave list is no longer
      protected by bond->lock, only protected by rtnl lock(), so we have 3 ways to modify it:
      1.add bond_master_upper_dev_link() and bond_upper_dev_unlink() in bond->lock, but it is unsafe
      to call call_netdevice_notifiers() in write lock.
      2.remove unused bond->lock for monitor function, only use the existing rtnl lock().
      3.use rcu_read_lock() to protect it, of course, it will transform bond_for_each_slave to
      bond_for_each_slave_rcu() and performance is better, but in slow path, it is ignored.
      so I remove the bond->lock and move the rtnl lock to protect the whole monitor function.
      Signed-off-by: NDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6b6c5261
  2. 26 10月, 2013 1 次提交
    • A
      net: fix rtnl notification in atomic context · 7f294054
      Alexei Starovoitov 提交于
      commit 991fb3f7 "dev: always advertise rx_flags changes via netlink"
      introduced rtnl notification from __dev_set_promiscuity(),
      which can be called in atomic context.
      
      Steps to reproduce:
      ip tuntap add dev tap1 mode tap
      ifconfig tap1 up
      tcpdump -nei tap1 &
      ip tuntap del dev tap1 mode tap
      
      [  271.627994] device tap1 left promiscuous mode
      [  271.639897] BUG: sleeping function called from invalid context at mm/slub.c:940
      [  271.664491] in_atomic(): 1, irqs_disabled(): 0, pid: 3394, name: ip
      [  271.677525] INFO: lockdep is turned off.
      [  271.690503] CPU: 0 PID: 3394 Comm: ip Tainted: G        W    3.12.0-rc3+ #73
      [  271.703996] Hardware name: System manufacturer System Product Name/P8Z77 WS, BIOS 3007 07/26/2012
      [  271.731254]  ffffffff81a58506 ffff8807f0d57a58 ffffffff817544e5 ffff88082fa0f428
      [  271.760261]  ffff8808071f5f40 ffff8807f0d57a88 ffffffff8108bad1 ffffffff81110ff8
      [  271.790683]  0000000000000010 00000000000000d0 00000000000000d0 ffff8807f0d57af8
      [  271.822332] Call Trace:
      [  271.838234]  [<ffffffff817544e5>] dump_stack+0x55/0x76
      [  271.854446]  [<ffffffff8108bad1>] __might_sleep+0x181/0x240
      [  271.870836]  [<ffffffff81110ff8>] ? rcu_irq_exit+0x68/0xb0
      [  271.887076]  [<ffffffff811a80be>] kmem_cache_alloc_node+0x4e/0x2a0
      [  271.903368]  [<ffffffff810b4ddc>] ? vprintk_emit+0x1dc/0x5a0
      [  271.919716]  [<ffffffff81614d67>] ? __alloc_skb+0x57/0x2a0
      [  271.936088]  [<ffffffff810b4de0>] ? vprintk_emit+0x1e0/0x5a0
      [  271.952504]  [<ffffffff81614d67>] __alloc_skb+0x57/0x2a0
      [  271.968902]  [<ffffffff8163a0b2>] rtmsg_ifinfo+0x52/0x100
      [  271.985302]  [<ffffffff8162ac6d>] __dev_notify_flags+0xad/0xc0
      [  272.001642]  [<ffffffff8162ad0c>] __dev_set_promiscuity+0x8c/0x1c0
      [  272.017917]  [<ffffffff81731ea5>] ? packet_notifier+0x5/0x380
      [  272.033961]  [<ffffffff8162b109>] dev_set_promiscuity+0x29/0x50
      [  272.049855]  [<ffffffff8172e937>] packet_dev_mc+0x87/0xc0
      [  272.065494]  [<ffffffff81732052>] packet_notifier+0x1b2/0x380
      [  272.080915]  [<ffffffff81731ea5>] ? packet_notifier+0x5/0x380
      [  272.096009]  [<ffffffff81761c66>] notifier_call_chain+0x66/0x150
      [  272.110803]  [<ffffffff8108503e>] __raw_notifier_call_chain+0xe/0x10
      [  272.125468]  [<ffffffff81085056>] raw_notifier_call_chain+0x16/0x20
      [  272.139984]  [<ffffffff81620190>] call_netdevice_notifiers_info+0x40/0x70
      [  272.154523]  [<ffffffff816201d6>] call_netdevice_notifiers+0x16/0x20
      [  272.168552]  [<ffffffff816224c5>] rollback_registered_many+0x145/0x240
      [  272.182263]  [<ffffffff81622641>] rollback_registered+0x31/0x40
      [  272.195369]  [<ffffffff816229c8>] unregister_netdevice_queue+0x58/0x90
      [  272.208230]  [<ffffffff81547ca0>] __tun_detach+0x140/0x340
      [  272.220686]  [<ffffffff81547ed6>] tun_chr_close+0x36/0x60
      Signed-off-by: NAlexei Starovoitov <ast@plumgrid.com>
      Acked-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7f294054
  3. 23 10月, 2013 1 次提交
    • V
      bonding: move bond-specific init after enslave happens · 5378c2e6
      Veaceslav Falico 提交于
      As Jiri noted, currently we first do all bonding-specific initialization
      (specifically - bond_select_active_slave(bond)) before we actually attach
      the slave (so that it becomes visible through bond_for_each_slave() and
      friends). This might result in bond_select_active_slave() not seeing the
      first/new slave and, thus, not actually selecting an active slave.
      
      Fix this by moving all the bond-related init part after we've actually
      completely initialized and linked (via bond_master_upper_dev_link()) the
      new slave.
      
      Also, remove the bond_(de/a)ttach_slave(), it's useless to have functions
      to ++/-- one int.
      
      After this we have all the initialization of the new slave *before*
      linking, and all the stuff that needs to be done on bonding *after* it. It
      has also a bonus effect - we can remove the locking on the new slave init
      completely, and only use it for bond_select_active_slave().
      Reported-by: NJiri Pirko <jiri@resnulli.us>
      CC: Jay Vosburgh <fubar@us.ibm.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      Signed-off-by: NVeaceslav Falico <vfalico@redhat.com>
      Acked-by: Ding Tianhong@huawei.com
      Reviewed-by: NJiri Pirko <jiri@resnulli.us>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5378c2e6
  4. 20 10月, 2013 8 次提交
  5. 18 10月, 2013 3 次提交
  6. 09 10月, 2013 1 次提交
  7. 04 10月, 2013 1 次提交
    • N
      bonding: modify the old and add new xmit hash policies · 32819dc1
      Nikolay Aleksandrov 提交于
      This patch adds two new hash policy modes which use skb_flow_dissect:
      3 - Encapsulated layer 2+3
      4 - Encapsulated layer 3+4
      There should be a good improvement for tunnel users in those modes.
      It also changes the old hash functions to:
      hash ^= (__force u32)flow.dst ^ (__force u32)flow.src;
      hash ^= (hash >> 16);
      hash ^= (hash >> 8);
      
      Where hash will be initialized either to L2 hash, that is
      SRCMAC[5] XOR DSTMAC[5], or to flow->ports which should be extracted
      from the upper layer. Flow's dst and src are also extracted based on the
      xmit policy either directly from the buffer or by using skb_flow_dissect,
      but in both cases if the protocol is IPv6 then dst and src are obtained by
      ipv6_addr_hash() on the real addresses. In case of a non-dissectable
      packet, the algorithms fall back to L2 hashing.
      The bond_set_mode_ops() function is now obsolete and thus deleted
      because it was used only to set the proper hash policy. Also we trim a
      pointer from struct bonding because we no longer need to keep the hash
      function, now there's only a single hash function - bond_xmit_hash that
      works based on bond->params.xmit_policy.
      
      The hash function and skb_flow_dissect were suggested by Eric Dumazet.
      The layer names were suggested by Andy Gospodarek, because I suck at
      semantics.
      Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Acked-by: NVeaceslav Falico <vfalico@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      32819dc1
  8. 01 10月, 2013 3 次提交
    • V
      bonding: RCUify bond_set_rx_mode() · b3241870
      Veaceslav Falico 提交于
      Currently we rely on rtnl locking in bond_set_rx_mode(), however it's not
      always the case:
      
      RTNL: assertion failed at drivers/net/bonding/bond_main.c (3391)
      ...
       [<ffffffff81651ca5>] dump_stack+0x54/0x74
       [<ffffffffa029e717>] bond_set_rx_mode+0xc7/0xd0 [bonding]
       [<ffffffff81553af7>] __dev_set_rx_mode+0x57/0xa0
       [<ffffffff81557ff8>] __dev_mc_add+0x58/0x70
       [<ffffffff81558020>] dev_mc_add+0x10/0x20
       [<ffffffff8161e26e>] igmp6_group_added+0x18e/0x1d0
       [<ffffffff81186f76>] ? kmem_cache_alloc_trace+0x236/0x260
       [<ffffffff8161f80f>] ipv6_dev_mc_inc+0x29f/0x320
       [<ffffffff8161f9e7>] ipv6_sock_mc_join+0x157/0x260
      ...
      
      Fix this by using RCU primitives.
      Reported-by: NJoe Lawrence <joe.lawrence@stratus.com>
      Tested-by: NJoe Lawrence <joe.lawrence@stratus.com>
      CC: Jay Vosburgh <fubar@us.ibm.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      Signed-off-by: NVeaceslav Falico <vfalico@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b3241870
    • N
      bonding: Fix broken promiscuity reference counting issue · 5a0068de
      Neil Horman 提交于
      Recently grabbed this report:
      https://bugzilla.redhat.com/show_bug.cgi?id=1005567
      
      Of an issue in which the bonding driver, with an attached vlan encountered the
      following errors when bond0 was taken down and back up:
      
      dummy1: promiscuity touches roof, set promiscuity failed. promiscuity feature of
      device might be broken.
      
      The error occurs because, during __bond_release_one, if we release our last
      slave, we take on a random mac address and issue a NETDEV_CHANGEADDR
      notification.  With an attached vlan, the vlan may see that the vlan and bond
      mac address were in sync, but no longer are.  This triggers a call to dev_uc_add
      and dev_set_rx_mode, which enables IFF_PROMISC on the bond device.  Then, when
      we complete __bond_release_one, we use the current state of the bond flags to
      determine if we should decrement the promiscuity of the releasing slave.  But
      since the bond changed promiscuity state during the release operation, we
      incorrectly decrement the slave promisc count when it wasn't in promiscuous mode
      to begin with, causing the above error
      
      Fix is pretty simple, just cache the bonding flags at the start of the function
      and use those when determining the need to set promiscuity.
      
      This is also needed for the ALLMULTI flag
      
      CC: Jay Vosburgh <fubar@us.ibm.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: Mark Wu <wudxw@linux.vnet.ibm.com>
      CC: "David S. Miller" <davem@davemloft.net>
      Reported-by: NMark Wu <wudxw@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5a0068de
    • V
      bonding: trivial: remove forgotten bond_next_vlan() · 90de527d
      Veaceslav Falico 提交于
      It's a forgotten function declaration, which was removed some time ago
      already.
      
      CC: Jay Vosburgh <fubar@us.ibm.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      Signed-off-by: NVeaceslav Falico <vfalico@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      90de527d
  9. 29 9月, 2013 11 次提交
  10. 27 9月, 2013 10 次提交