Skip to content
  1. Jan 16, 2014
  3. Jan 15, 2014
    • David S. Miller's avatar
      Merge branch 'i40e-next' · e3e4e01c
      David S. Miller authored 
      

Aaron Brown says:

====================
Intel Wired LAN Driver Updates

This series contains updates to i40e from Greg Rose for VLAN filtering.

Greg Rose (2):
  i40e: Warn admin to reload VF driver on port VLAN configuration.
    When an administrator sets a port VLAN filters for the virtual
    function (VF) after the VF has already set its own VLAN filters a
    conflict requiring the VF be reloaded can occur.  This patch logs a
    message indicating to the system administrator that the VF driver
    must be reloaded for the new port VLAN settings to take effect

  i40e: Retain MAC filters on port VLAN deletion
    On port VLAN deletion the list of MAC filters for the virtual function
    (VF) VSI were all deleted.  Let's keep them around, they come in
    handy for keeping the VF functional.
====================

Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e3e4e01c
    • Greg Rose's avatar
      i40e: Retain MAC filters on port VLAN deletion · 8d82a7c5
      Greg Rose authored 
      

On port VLAN deletion the list of MAC filters for the virtual function (VF)
VSI were all deleted.  Let's keep them around, they come in handy for keeping
the VF functional.

Change-Id: I335e760392f274dc8b8b40efcb708f65b49d7973
Signed-off-by: default avatarGreg Rose <gregory.v.rose@intel.com>
Tested-by: default avatarSibai Li <sibai.li@intel.com>
Signed-off-by: default avatarAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8d82a7c5
    • Greg Rose's avatar
      i40e: Warn admin to reload VF driver on port VLAN configuration · 99a4973c
      Greg Rose authored 
      

The i40e Physical Function (PF) driver will allow the
 Virtual Function (VF) driver to configure its own VLAN filters if no port
 VLAN filter has been configured.  This leads to the possibility of the
 administrator setting a port VLAN filter for the VF after the VF has already
 configured its own VLAN filters.  This leads to a conflict that can only be
 resolved by reloading the VF driver.  When the conflicting administrative
 command is detected in setting the port VLAN then log a message indicating to
 the system administrator that he must now reload the VF driver for the new
 port VLAN settings to take effect.

Change-Id: I8de73b885d944a043aff32226297e4249862bcad
Signed-off-by: default avatarGreg Rose <gregory.v.rose@intel.com>
Tested-by: default avatarSibai Li <sibai.li@intel.com>
Signed-off-by: default avatarAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      99a4973c
    • David S. Miller's avatar
      Merge branch 'vxlan_lower_dev_unregister' · e07d4ca8
      David S. Miller authored 
      

Daniel Borkmann says:

====================
vxlan updates

Did the split into two patches upon request from Cong Wang.

Changelog:

 v1->v2:
  - Removed BUG_ON as it's not needed.
 v2->v3:
  - Removed dev->reg_state check for netns.
 v3->v4:
  - Removed list_del(), we seem to do it in some places and
    in some others not; we agreed it's not really necessary.
  - Split patch into 2 patches, notifier part and module
    unload cleanup part.
====================

Reviewed-by: default avatarCong Wang <cwang@twopensource.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e07d4ca8
    • Daniel Borkmann's avatar
      net: vxlan: properly cleanup devs on module unload · 8425783c
      Daniel Borkmann authored 
      

We should use vxlan_dellink() handler in vxlan_exit_net(), since
i) we're not in fast-path and we should be consistent in dismantle
just as we would remove a device through rtnl ops, and more
importantly, ii) in case future code will kfree() memory in
vxlan_dellink(), we would leak it right here unnoticed. Therefore,
do not only half of the cleanup work, but make it properly.

Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8425783c
    • Daniel Borkmann's avatar
      net: vxlan: when lower dev unregisters remove vxlan dev as well · acaf4e70
      Daniel Borkmann authored 
      

We can create a vxlan device with an explicit underlying carrier.
In that case, when the carrier link is being deleted from the
system (e.g. due to module unload) we should also clean up all
created vxlan devices on top of it since otherwise we're in an
inconsistent state in vxlan device. In that case, the user needs
to remove all such devices, while in case of other virtual devs
that sit on top of physical ones, it is usually the case that
these devices do unregister automatically as well and do not
leave the burden on the user.

This work is not necessary when vxlan device was not created with
a real underlying device, as connections can resume in that case
when driver is plugged again. But at least for the other cases,
we should go ahead and do the cleanup on removal.

We don't register the notifier during vxlan_newlink() here since
I consider this event rather rare, and therefore we should not
bloat vxlan's core structure unecessary. Also, we can simply make
use of unregister_netdevice_many() to batch that. fdb is flushed
upon ndo_stop().

E.g. `ip -d link show vxlan13` after carrier removal before
this patch:

5: vxlan13: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN mode DEFAULT group default
    link/ether 1e:47:da:6d:4d:99 brd ff:ff:ff:ff:ff:ff promiscuity 0
    vxlan id 13 group 239.0.0.10 dev 2 port 32768 61000 ageing 300
                                 ^^^^^
Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      acaf4e70
    • David S. Miller's avatar
      Merge branch 'intel-next' · fb52cab5
      David S. Miller authored 
      

Aaron Brown says:

====================
Intel Wired LAN Driver Updates, ixgbe: Add LER support

The following patches add Live Error Recovery (LER) support to the
ixgbe driver. This support also improves behavior in Thunderbolt
environments. This involves checking all register reads for a
value of all ones and when that is seen, to read the status
register, which should never properly return all ones, to
confirm whether the received value was correct. When this detects
a removal, the hw_addr field is cleared to indicate the removal.
This then blocks subsequent access to the device registers.

All register access macros have been changed to static inline
functions and all register accesses now use them.· Macro versions
are temporarily provided.

The __IXGBE_DOWN bit is no longer overloaded to also mean that
device removal has been initiated. Now the bit can be used to
protect ixgbe_down from multiple entry via test_and_set_bit. A
needed smp_mb__before_clear_bit was also added.

V2 Changes:
- Use ACCESS_ONCE where needed, thanks to Ben Hutchings
- Fix crash on module removal
- Use boolean values for boolean returns instead of 0 and 1
- Reword Kconfig help text

V3 Changes:
- Drop config option, per David Miller
- Drop tail register write checks, per Alexander Duyck
- Change writeq implementation to a static inline, thanks to Joe Perches

V4 Changes:
- Change __IXGBE_REMOVE to __IXGBE_REMOVING, per Scott Feldman's comment
- Add #define writeq writeq, per Alexander Duyck
- Change static inline functions to lower case, per David Miller
- Use new lower case names in added and modified register accesses
- Provide temporary upper case macros for register access functions
- Change IXGBE_REMOVED from macro to static inline and change references
- Correct IXGBE_WRITE_FLUSH to properly enclose parameter expansion
====================

Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fb52cab5
    • Mark Rustad's avatar
      ixgbe: Additional adapter removal checks · b0483c8f
      Mark Rustad authored 
      

Additional checks are needed for a detected removal not to cause
problems. Some involve simply avoiding a lot of stuff that can't
do anything good, and also cases where the phony return value can
cause problems. In addition, down the adapter when the removal is
sensed.

Signed-off-by: default avatarMark Rustad <mark.d.rustad@intel.com>
Tested-by: default avatarPhil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: default avatarAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b0483c8f
    • Mark Rustad's avatar
      ixgbe: Check for adapter removal on register writes · b12babd4
      Mark Rustad authored 
      

Prevent writes to an adapter that has been detected as removed
by a previous failing read. This also fixes some include file
ordering confusion that this patch revealed.

Signed-off-by: default avatarMark Rustad <mark.d.rustad@intel.com>
Tested-by: default avatarPhil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: default avatarAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b12babd4
    • Mark Rustad's avatar
      ixgbe: Check register reads for adapter removal · 2a1a091c
      Mark Rustad authored 
      

Check all register reads for adapter removal by checking the status
register after any register read that returns 0xFFFFFFFF. Since the
status register will never return 0xFFFFFFFF unless the adapter is
removed, such a value from a status register read confirms the
removal.

Signed-off-by: default avatarMark Rustad <mark.d.rustad@intel.com>
Tested-by: default avatarPhil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: default avatarAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2a1a091c