1. 14 4月, 2017 1 次提交
  2. 09 3月, 2017 1 次提交
    • J
      team: use ETH_MAX_MTU as max mtu · 3331aa37
      Jarod Wilson 提交于
      This restores the ability to set a team device's mtu to anything higher
      than 1500. Similar to the reported issue with bonding, the team driver
      calls ether_setup(), which sets an initial max_mtu of 1500, while the
      underlying hardware can handle something much larger. Just set it to
      ETH_MAX_MTU to support all possible values, and the limitations of the
      underlying devices will prevent setting anything too large.
      
      Fixes: 91572088 ("net: use core MTU range checking in core net infra")
      CC: Cong Wang <xiyou.wangcong@gmail.com>
      CC: Jiri Pirko <jiri@resnulli.us>
      CC: netdev@vger.kernel.org
      Signed-off-by: NJarod Wilson <jarod@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3331aa37
  3. 07 2月, 2017 1 次提交
  4. 09 1月, 2017 1 次提交
  5. 28 10月, 2016 3 次提交
    • J
      genetlink: mark families as __ro_after_init · 56989f6d
      Johannes Berg 提交于
      Now genl_register_family() is the only thing (other than the
      users themselves, perhaps, but I didn't find any doing that)
      writing to the family struct.
      
      In all families that I found, genl_register_family() is only
      called from __init functions (some indirectly, in which case
      I've add __init annotations to clarifly things), so all can
      actually be marked __ro_after_init.
      
      This protects the data structure from accidental corruption.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      56989f6d
    • J
      genetlink: statically initialize families · 489111e5
      Johannes Berg 提交于
      Instead of providing macros/inline functions to initialize
      the families, make all users initialize them statically and
      get rid of the macros.
      
      This reduces the kernel code size by about 1.6k on x86-64
      (with allyesconfig).
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      489111e5
    • J
      genetlink: no longer support using static family IDs · a07ea4d9
      Johannes Berg 提交于
      Static family IDs have never really been used, the only
      use case was the workaround I introduced for those users
      that assumed their family ID was also their multicast
      group ID.
      
      Additionally, because static family IDs would never be
      reserved by the generic netlink code, using a relatively
      low ID would only work for built-in families that can be
      registered immediately after generic netlink is started,
      which is basically only the control family (apart from
      the workaround code, which I also had to add code for so
      it would reserve those IDs)
      
      Thus, anything other than GENL_ID_GENERATE is flawed and
      luckily not used except in the cases I mentioned. Move
      those workarounds into a few lines of code, and then get
      rid of GENL_ID_GENERATE entirely, making it more robust.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a07ea4d9
  6. 06 7月, 2016 1 次提交
  7. 23 6月, 2016 1 次提交
  8. 10 6月, 2016 1 次提交
  9. 08 6月, 2016 1 次提交
  10. 26 5月, 2016 1 次提交
    • I
      team: don't call netdev_change_features under team->lock · f6988cb6
      Ivan Vecera 提交于
      The team_device_event() notifier calls team_compute_features() to fix
      vlan_features under team->lock to protect team->port_list. The problem is
      that subsequent __team_compute_features() calls netdev_change_features()
      to propagate vlan_features to upper vlan devices while team->lock is still
      taken. This can lead to deadlock when NETIF_F_LRO is modified on lower
      devices or team device itself.
      
      Example:
      The team0 as active backup with eth0 and eth1 NICs. Both eth0 & eth1 are
      LRO capable and LRO is enabled. Thus LRO is also enabled on team0.
      
      The command 'ethtool -K team0 lro off' now hangs due to this deadlock:
      
      dev_ethtool()
      -> ethtool_set_features()
       -> __netdev_update_features(team)
        -> netdev_sync_lower_features()
         -> netdev_update_features(lower_1)
          -> __netdev_update_features(lower_1)
          -> netdev_features_change(lower_1)
           -> call_netdevice_notifiers(...)
            -> team_device_event(lower_1)
             -> team_compute_features(team) [TAKES team->lock]
              -> netdev_change_features(team)
               -> __netdev_update_features(team)
                -> netdev_sync_lower_features()
                 -> netdev_update_features(lower_2)
                  -> __netdev_update_features(lower_2)
                  -> netdev_features_change(lower_2)
                   -> call_netdevice_notifiers(...)
                    -> team_device_event(lower_2)
                     -> team_compute_features(team) [DEADLOCK]
      
      The bug is present in team from the beginning but it appeared after the commit
      fd867d51 (net/core: generic support for disabling netdev features down stack)
      that adds synchronization of features with lower devices.
      
      Fixes: fd867d51 (net/core: generic support for disabling netdev features down stack)
      Cc: Jiri Pirko <jiri@resnulli.us>
      Signed-off-by: NIvan Vecera <ivecera@redhat.com>
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f6988cb6
  11. 31 3月, 2016 1 次提交
  12. 19 3月, 2016 1 次提交
  13. 26 2月, 2016 1 次提交
  14. 06 2月, 2016 1 次提交
  15. 19 1月, 2016 1 次提交
  16. 18 12月, 2015 1 次提交
  17. 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
  18. 04 12月, 2015 6 次提交
  19. 19 8月, 2015 1 次提交
  20. 18 5月, 2015 1 次提交
  21. 13 5月, 2015 5 次提交
  22. 30 3月, 2015 1 次提交
  23. 05 3月, 2015 1 次提交
  24. 28 2月, 2015 1 次提交
  25. 24 2月, 2015 1 次提交
    • J
      team: fix possible null pointer dereference in team_handle_frame · 57e59563
      Jiri Pirko 提交于
      Currently following race is possible in team:
      
      CPU0                                        CPU1
                                                  team_port_del
                                                    team_upper_dev_unlink
                                                      priv_flags &= ~IFF_TEAM_PORT
      team_handle_frame
        team_port_get_rcu
          team_port_exists
            priv_flags & IFF_TEAM_PORT == 0
          return NULL (instead of port got
                       from rx_handler_data)
                                                    netdev_rx_handler_unregister
      
      The thing is that the flag is removed before rx_handler is unregistered.
      If team_handle_frame is called in between, team_port_exists returns 0
      and team_port_get_rcu will return NULL.
      So do not check the flag here. It is guaranteed by netdev_rx_handler_unregister
      that team_handle_frame will always see valid rx_handler_data pointer.
      Signed-off-by: NJiri Pirko <jiri@resnulli.us>
      Fixes: 3d249d4c ("net: introduce ethernet teaming device")
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      57e59563
  26. 02 2月, 2015 1 次提交
  27. 15 1月, 2015 1 次提交
    • J
      team: avoid possible underflow of count_pending value for notify_peers and mcast_rejoin · b0d11b42
      Jiri Pirko 提交于
      This patch is fixing a race condition that may cause setting
      count_pending to -1, which results in unwanted big bulk of arp messages
      (in case of "notify peers").
      
      Consider following scenario:
      
      count_pending == 2
         CPU0                                           CPU1
      					team_notify_peers_work
      					  atomic_dec_and_test (dec count_pending to 1)
      					  schedule_delayed_work
       team_notify_peers
         atomic_add (adding 1 to count_pending)
      					team_notify_peers_work
      					  atomic_dec_and_test (dec count_pending to 1)
      					  schedule_delayed_work
      					team_notify_peers_work
      					  atomic_dec_and_test (dec count_pending to 0)
         schedule_delayed_work
      					team_notify_peers_work
      					  atomic_dec_and_test (dec count_pending to -1)
      
      Fix this race by using atomic_dec_if_positive - that will prevent
      count_pending running under 0.
      
      Fixes: fc423ff0 ("team: add peer notification")
      Fixes: 492b200e  ("team: add support for sending multicast rejoins")
      Signed-off-by: NJiri Pirko <jiri@resnulli.us>
      Signed-off-by: NJiri Benc <jbenc@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b0d11b42
  28. 13 1月, 2015 1 次提交
  29. 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