1. 23 1月, 2014 1 次提交
    • N
      bonding: add infrastructure for an option API · 09117362
      Nikolay Aleksandrov 提交于
      This patch adds the necessary basic infrastructure to support
      centralized and unified option manipulation API for the bonding. The new
      structure bond_option will be used to describe each option with its
      dependencies on modes which will be checked automatically thus removing a
      lot of duplicated code. Also automatic range checking is added for
      some options. Currently the option setting function requires RTNL to
      be acquired prior to calling it, since many options already rely on RTNL
      it seemed like the best choice to protect all against common race
      conditions.
      In order to add an option the following steps need to be done:
      1. Add an entry BOND_OPT_<option> to bond_options.h so it gets a unique id
         and a bit corresponding to the id
      2. Add a bond_option entry to the bond_opts[] array in bond_options.c which
         describes the option, its dependencies and its manipulation function
      3. Add code to export the option through sysfs and/or as a module parameter
         (the sysfs export will be made automatically in the future)
      
      The options can have different flags set, currently the following are
      supported:
      BOND_OPTFLAG_NOSLAVES - require that the bond device has no slaves prior
                              to setting the option
      BOND_OPTFLAG_IFDOWN - require that the bond device is down prior to
                            setting the option
      BOND_OPTFLAG_RAWVAL - don't parse the value but return it raw for the
                            option to parse
      
      There's a new value structure to describe different types of values
      which can have the following flags:
      BOND_VALFLAG_DEFAULT - marks the default option (permanent string alias
                             to this option is "default")
      BOND_VALFLAG_MIN - the minimum value that this option can have
      BOND_VALFLAG_MAX - the maximum value that this option can have
      
      An example would be nice here, so if we have an option which can have
      the values "off"(2), "special"(4, default) and supports a range, say
      16 - 32, it should be defined as follows:
      "off", 2,
      "special", 4, BOND_VALFLAG_DEFAULT,
      "rangemin", 16, BOND_VALFLAG_MIN,
      "rangemax", 32, BOND_VALFLAG_MAX
      So we have the valid intervals: [2, 2], [4, 4], [16, 32]
      Also the valid strings: "off" = 2, "special" and "default" = 4
                              "rangemin" = 16, "rangemax" = 32
      
      BOND_VALFLAG_(MIN|MAX) can be used to specify a valid range for an
      option, if MIN is omitted then 0 is considered as a minimum. If an
      exact match is found in the values[] table it will be returned,
      otherwise the range is tried (if available).
      
      The option parameter passing is done by using a special structure called
      bond_opt_value which can take either a string or a value to parse. One
      of the bond_opt_init(val|str) macros should be used depending on which
      one does the user want to parse (string or value). Then a call to
      __bond_opt_set should be done under RTNL.
      Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      09117362
  2. 22 1月, 2014 2 次提交
  3. 18 1月, 2014 2 次提交
  4. 17 1月, 2014 1 次提交
  5. 15 1月, 2014 1 次提交
  6. 14 1月, 2014 3 次提交
    • V
      bonding: fix __get_active_agg() RCU logic · 49b7624e
      Veaceslav Falico 提交于
      Currently, the implementation is meaningless - once again, we take the
      slave structure and use it after we've exited RCU critical section.
      
      Fix this by removing the rcu_read_lock() from __get_active_agg(), and
      ensuring that all its callers are holding RCU.
      
      Fixes: be79bd04 ("bonding: add RCU for bond_3ad_state_machine_handler()")
      CC: dingtianhong@huawei.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>
      49b7624e
    • V
      bonding: fix __get_first_agg RCU usage · 768b9549
      Veaceslav Falico 提交于
      Currently, the RCU read lock usage is just wrong - it gets the slave struct
      under RCU and continues to use it when RCU lock is released.
      
      However, it's still safe to do this cause we didn't need the
      rcu_read_lock() initially - all of the __get_first_agg() callers are either
      holding RCU read lock or the RTNL lock, so that we can't sync while in it.
      
      Fixes: be79bd04 ("bonding: add RCU for bond_3ad_state_machine_handler()")
      CC: dingtianhong@huawei.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>
      768b9549
    • V
      bonding: fix bond_3ad_set_carrier() RCU usage · c1bc9644
      Veaceslav Falico 提交于
      Currently, its usage is just plainly wrong. It first gets a slave under
      RCU, and, after releasing the RCU lock, continues to use it - whilst it can
      be freed.
      
      Fix this by ensuring that bond_3ad_set_carrier() holds RCU till it uses its
      slave (or its agg).
      
      Fixes: be79bd04 ("bonding: add RCU for bond_3ad_state_machine_handler()")
      CC: dingtianhong@huawei.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>
      c1bc9644
  7. 13 1月, 2014 3 次提交
  8. 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
  9. 07 1月, 2014 1 次提交
  10. 04 1月, 2014 5 次提交
  11. 02 1月, 2014 8 次提交
  12. 31 12月, 2013 2 次提交
  13. 30 12月, 2013 1 次提交
  14. 20 12月, 2013 5 次提交
  15. 19 12月, 2013 3 次提交
    • D
      bonding: protect port for bond_3ad_handle_link_change() · 108db736
      dingtianhong 提交于
      The bond_3ad_handle_link_change is called with RTNL only,
      and the function will modify the port's information with
      no further locking, it will not mutex against bond state
      machine and incoming LACPDU which do not hold RTNL, So I
      add __get_state_machine_lock to protect the port.
      
      But it is not a critical bug, it exist since day one, and till
      now it has never been hit and reported, because changes to
      speed is very rare, and will not occur critical problem.
      
      The comments in the function is very old, cleanup it and
      add a new pr_debug to debug the port message.
      Signed-off-by: NDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      108db736
    • D
      bonding: protect port for bond_3ad_adapter_duplex_changed() · bca44a73
      dingtianhong 提交于
      Jay Vosburgh said that the bond_3ad_adapter_duplex_changed is
      called with RTNL only, and the function will modify the port's
      information with no further locking, it will not mutex against
      bond state machine and incoming LACPDU which do not hold RTNL,
      So I add __get_state_machine_lock to protect the port.
      
      But it is not a critical bug, it exist since day one, and till
      now it has never been hit and reported, because changes to
      speed is very rare, and will not occur critical problem.
      
      The comments in the function is very old, cleanup it.
      Suggested-by: NJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: NDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bca44a73
    • D
      bonding: protect port for bond_3ad_adapter_speed_changed() · 71a06c59
      dingtianhong 提交于
      Jay Vosburgh said that the bond_3ad_adapter_speed_changed is
      called with RTNL only, and the function will modify the port's
      information with no further locking, it will not mutex against
      bond state machine and incoming LACPDU which do not hold RTNL,
      So I add __get_state_machine_lock to protect the port.
      
      But it is not a critical bug, it exist since day one, and till
      now it has never been hit and reported, because changes to
      speed is very rare, and will not occur critical problem.
      
      The comment in the function is very old, cleanup it.
      Suggested-by: NJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: NDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      71a06c59
  16. 18 12月, 2013 1 次提交