Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 18 6月, 2016 1 次提交
  3. 17 6月, 2016 1 次提交
  5. 12 5月, 2016 1 次提交
  7. 25 4月, 2016 1 次提交
  9. 22 4月, 2016 1 次提交
  11. 11 3月, 2016 2 次提交
  13. 05 1月, 2016 1 次提交
  15. 28 12月, 2015 1 次提交
  17. 25 12月, 2015 1 次提交
  19. 16 12月, 2015 1 次提交
  21. 19 11月, 2015 1 次提交
  23. 08 11月, 2015 1 次提交
    • J
      net/qlcnic: fix mac address restore in bond mode 5/6 · e824de8a
      由 Jarod Wilson 提交于 
      The bonding driver saves a copy of slaves' original mac address and then
assigns whatever mac as needed to the slave, depending on mode. In at
least modes 5 and 6 (balance-tlb, balance-alb), it often ends up being the
mac address of another slave. On release from the bond, the original mac
address is supposed to get restored via a dev_set_mac_address() call in
the bonding driver's __bond_release_one() function, which calls the
slave's ndo_set_mac_address function, which for qlcnic, is
qlcnic_set_mac().

Now, this function tries to be somewhat intelligent and exit early if
you're trying to set the mac address to the same thing that is already
set. The problem here is that adapter->mac_addr isn't in sync with
netdev->dev_addr. The qlcnic driver still has the original mac stored in
adapter->mac_addr, while the bonding driver has updated netdev->dev_addr,
so qlcnic thinks we're trying to set the same address it already has.

I think the way to go here, since the function updates both netdev and
adapter's stored mac addresses, is to check if either of them doesn't
match the newly requested mac. Simply checking netdev's value only could
result in a similar mismatch and non-update, so look at both.

CC: Dept-GELinuxNICDev@qlogic.com
CC: netdev@vger.kernel.org
CC: Manish Chopra <manish.chopra@qlogic.com>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e824de8a
  25. 13 10月, 2015 1 次提交
  27. 18 9月, 2015 1 次提交
  29. 10 9月, 2015 1 次提交
  31. 11 8月, 2015 6 次提交
  33. 30 7月, 2015 1 次提交
  35. 16 7月, 2015 1 次提交
  37. 29 5月, 2015 1 次提交
  39. 30 3月, 2015 1 次提交
  41. 09 3月, 2015 1 次提交
  43. 07 3月, 2015 1 次提交
  45. 02 3月, 2015 1 次提交
  47. 12 2月, 2015 1 次提交
    • S
      qlcnic: Delete existing multicast MAC list before adding new · fe79fabb
      由 Shahed Shaikh 提交于 
      Driver keeps adding multicast addresses without deleting removed MACs and
worrying about adapters filter limit. This results into actual count of programmed
multicast addresses get accumulated over the time and overruns the adapter's
filter limit without putting device in ACCEPT_ALL_MULTI mode. This causes
newly added multicast traffic to fail after the sequence of addition - deletion
in certain pattern.

This issue is seen only when netdev's mcast list count is less than adapters
mcast filter limit.

e.g. If adapters multicast filter limit is 38 per function
     then following sequence would result in multicast traffic failure for
     newly added MACs.
     - add less than 38 multicast MACs
     - remove previously added multicast MACs
     - add new multicast MACs (less than 38)
Signed-off-by: NShahed Shaikh <shahed.shaikh@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fe79fabb
  49. 05 2月, 2015 2 次提交
  51. 14 1月, 2015 1 次提交
  53. 05 1月, 2015 1 次提交
  55. 01 1月, 2015 1 次提交
  57. 27 12月, 2014 1 次提交
    • J
      net: Generalize ndo_gso_check to ndo_features_check · 5f35227e
      由 Jesse Gross 提交于 
      GSO isn't the only offload feature with restrictions that
potentially can't be expressed with the current features mechanism.
Checksum is another although it's a general issue that could in
theory apply to anything. Even if it may be possible to
implement these restrictions in other ways, it can result in
duplicate code or inefficient per-packet behavior.

This generalizes ndo_gso_check so that drivers can remove any
features that don't make sense for a given packet, similar to
netif_skb_features(). It also converts existing driver
restrictions to the new format, completing the work that was
done to support tunnel protocols since the issues apply to
checksums as well.

By actually removing features from the set that are used to do
offloading, it solves another problem with the existing
interface. In these cases, GSO would run with the original set
of features and not do anything because it appears that
segmentation is not required.

CC: Tom Herbert <therbert@google.com>
CC: Joe Stringer <joestringer@nicira.com>
CC: Eric Dumazet <edumazet@google.com>
CC: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: NJesse Gross <jesse@nicira.com>
Acked-by: NTom Herbert <therbert@google.com>
Fixes: 04ffcb25 ("net: Add ndo_gso_check")
Tested-by: NHayes Wang <hayeswang@realtek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5f35227e
  59. 03 12月, 2014 2 次提交
  61. 15 11月, 2014 1 次提交
  63. 15 10月, 2014 1 次提交