This change cleans up several situations in which we were either stepping
over possible errors, or calling initialization routines multiple times.
Also includes whitespace fixes where applicable.
Signed-off-by: NEmil Tantilov <emil.s.tantilov@intel.com>
Tested-by: NStephen Ko <stephen.s.ko@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Add support to the ndo_fcoe_ddp_target() to allow the Intel 82599 device to
also provide DDP offload capability when the upper FCoE protocol stack is
operating as a target.
Signed-off-by: NYi Zou <yi.zou@intel.com>
Signed-off-by: NKiran Patil <kiran.patil@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Add the new target ddp offload support ndo_fcoe_ddp_target().
Signed-off-by: NYi Zou <yi.zou@intel.com>
Signed-off-by: NKiran Patil <kiran.patil@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

The Fiber Channel over Ethernet (FCoE) Direct Data Placement (DDP) can also be
used for FCoE target, where the DDP used for read I/O on an initiator can be
used on an FCoE target to speed up the write I/O to the target from the initiator.
The added ndo_fcoe_ddp_target() works in the similar way as the existing
ndo_fcoe_ddp_setup() to allow the underlying hardware set up the DDP context
accordingly when it gets called from the FCoE target implementation on top
the existing Open-FCoE fcoe/libfc protocol stack so without losing the ability
to provide DDP for read I/O as an initiator, it can also provide DDP offload
to the write I/O coming from the initiator as a target.
Signed-off-by: NYi Zou <yi.zou@intel.com>
Signed-off-by: NKiran Patil <kiran.patil@intel.com>
Tested-by: NKavindya Deegala <kavindya.s.deegala@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

In the previous commit:
  commit 5e655105
  Author: Don Skidmore <donald.c.skidmore@intel.com>
  Date:   Fri Feb 25 01:58:04 2011 +0000

  ixgbe: add function pointer for semaphore function

there was one release of the semaphore function call which
did not get converted to a function pointer.
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

This patch adds statistics output for OS2BMC feature which is configured
by eeprom on capable devices.
Signed-off-by: NCarolyn Wyborny <carolyn.wyborny@intel.com>
Tested-by: NAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

kernel build fails with:

drivers/built-in.o: In function `e1000_lv_jumbo_workaround_ich8lan':
(.text+0x3e7a8): undefined reference to `crc32_le'

when CONFIG_CRC32 is not set or does not match the CONFIG_E1000E
selection.
Signed-off-by: NEmil Tantilov <emil.s.tantilov@intel.com>
Reviewed-by: NBruce Allan <bruce.w.allan@intel.com>
Tested-by: NJeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

When there is a ptype handler holding a clone of this skb, whose
destination MAC addresse is overwritten, the owner of this handler may
get a corrupted packet.
Signed-off-by: NChangli Gao <xiaosuo@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

These two functions are only used when net poll controller is enabled.
Signed-off-by: NChangli Gao <xiaosuo@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This was there before, I forgot about this. Allows deliveries to
ptype_base handlers registered for orig_dev. I presume this is still
desired.
Signed-off-by: NJiri Pirko <jpirko@redhat.com>
Reviewed-by: NNicolas de Pesloüan <nicolas.2p.debian@free.fr>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Lancer requires multicast capability flag set during IFACE_CREATE
for adding multicast filters.
Signed-off-by: NPadmanabh Ratnakar <padmanabh.ratnakar@emulex.com>
Signed-off-by: NSathya Perla <sathya.perla@emulex.com>
Signed-off-by: NSubramanian Seetharaman <subbu.seetharaman@emulex.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

For Lancer disable interrupts in close by disarming CQs and EQs.
Change the order of calls in be_close to achieve the correct result.
Signed-off-by: NPadmanabh Ratnakar <padmanabh.ratnakar@emulex.com>
Signed-off-by: NSathya Perla <sathya.perla@emulex.com>
Signed-off-by: NSubramanian Seetharaman <subbu.seetharaman@emulex.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Remove TX Queue stop in close
Signed-off-by: NPadmanabh Ratnakar <padmanabh.ratnakar@emulex.com>
Signed-off-by: NSathya Perla <sathya.perla@emulex.com>
Signed-off-by: NSubramanian Seetharaman <subbu.seetharaman@emulex.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Change f/w command versions for Lancer
Signed-off-by: NPadmanabh Ratnakar <padmanabh.ratnakar@emulex.com>
Signed-off-by: NSathya Perla <sathya.perla@emulex.com>
Signed-off-by: NSubramanian Seetharaman <subbu.seetharaman@emulex.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add error recovery during load for Lancer
Signed-off-by: NPadmanabh Ratnakar <padmanabh.ratnakar@emulex.com>
Signed-off-by: NSathya Perla <sathya.perla@emulex.com>
Signed-off-by: NSubramanian Seetharaman <subbu.seetharaman@emulex.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

L4 checksum field is valid only for TCP/UDP packets in Lancer
Signed-off-by: NPadmanabh Ratnakar <padmanabh.ratnakar@emulex.com>
Signed-off-by: NSathya Perla <sathya.perla@emulex.com>
Signed-off-by: NSubramanian Seetharaman <subbu.seetharaman@emulex.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Workaround added for Lancer in handling RX ERR completion received
when no RX buffers are posted is not needed.
Signed-off-by: NPadmanabh Ratnakar <padmanabh.ratnakar@emulex.com>
Signed-off-by: NSathya Perla <sathya.perla@emulex.com>
Signed-off-by: NSubramanian Seetharaman <subbu.seetharaman@emulex.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This elimiates a lot of pure overhead due to parameter
passing.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

fib_semantic_match() requires that if the type doesn't signal an
automatic error, it must be of type RTN_UNICAST, RTN_LOCAL,
RTN_BROADCAST, RTN_ANYCAST, or RTN_MULTICAST.

Checking this every route lookup is pointless work.

Instead validate it during route insertion, via fib_create_info().

Also, there was nothing making sure the type value was less than
RTN_MAX, so add that missing check while we're here.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This allows any caller to be prefaced by any specific
pr_fmt to better identify which device driver is using
this function inappropriately.

Add terminating newline.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When trying to associate a net_device with another net_device which
already exists, batman-adv assumes that this interface is a fully
initialized batman mesh interface without checking it. The behaviour
when accessing data behind netdev_priv of a random net_device is
undefined and potentially dangerous.
Reported-by: NLinus Lüssing <linus.luessing@ascom.ch>
Signed-off-by: NMarek Lindner <lindner_marek@yahoo.de>

Signed-off-by: NLinus Lüssing <linus.luessing@ascom.ch>
Signed-off-by: NMarek Lindner <lindner_marek@yahoo.de>

Signed-off-by: NMarek Lindner <lindner_marek@yahoo.de>

Batman-adv works with "hard interfaces" as well as "soft interfaces".
The new name should better make clear which kind of interfaces this
list stores.
Signed-off-by: NMarek Lindner <lindner_marek@yahoo.de>

Signed-off-by: NMarek Lindner <lindner_marek@yahoo.de>

Signed-off-by: NMarek Lindner <lindner_marek@yahoo.de>

It might be possible that 2 threads access the same data in the same
rcu grace period. The first thread calls call_rcu() to decrement the
refcount and free the data while the second thread increases the
refcount to use the data. To avoid this race condition all refcount
operations have to be atomic.
Reported-by: NSven Eckelmann <sven@narfation.org>
Signed-off-by: NMarek Lindner <lindner_marek@yahoo.de>

Signed-off-by: NMarek Lindner <lindner_marek@yahoo.de>

Note: The function compare_ether_addr() provided by the Linux kernel
requires aligned memory.
Signed-off-by: NMarek Lindner <lindner_marek@yahoo.de>

When printing the soft interface table the number of entries in the
softif neigh list are first being counted and a fitting buffer
allocated. After that the softif neigh list gets locked again and
the buffer printed - which has the following two issues:

For one thing, the softif neigh list might have grown when reacquiring
the rcu lock, which results in writing outside of the allocated buffer.
Furthermore 31 Bytes are not enough for printing an entry with a vid
of more than 2 digits.

The manual buffering is unnecessary, we can safely print to the seq
directly during the rcu_read_lock().
Signed-off-by: NLinus Lüssing <linus.luessing@ascom.ch>
Signed-off-by: NMarek Lindner <lindner_marek@yahoo.de>

When unicast_send_skb() is increasing the orig_node's refcount another
thread might have been freeing this orig_node already. We need to
increase the refcount in the rcu read lock protected area to avoid that.
Signed-off-by: NLinus Lüssing <linus.luessing@ascom.ch>
Signed-off-by: NMarek Lindner <lindner_marek@yahoo.de>

The rcu protected macros rcu_dereference() and rcu_assign_pointer()
for the bat_priv->curr_gw need to be used, as well as spin/rcu locking.

Otherwise we might end up using a curr_gw pointer pointing to already
freed memory.
Reported-by: NSven Eckelmann <sven@narfation.org>
Signed-off-by: NLinus Lüssing <linus.luessing@ascom.ch>
Signed-off-by: NMarek Lindner <lindner_marek@yahoo.de>

Batman-adv could receive several payload broadcasts at the same time
that would trigger access to the broadcast seqno sliding window to
determine whether this is a new broadcast or not. If these incoming
broadcasts are accessing the sliding window simultaneously it could
be left in an inconsistent state. Therefore it is necessary to make
sure this access is atomic.
Reported-by: NLinus Lüssing <linus.luessing@web.de>
Signed-off-by: NMarek Lindner <lindner_marek@yahoo.de>

Reported-by: NLinus Lüssing <linus.luessing@saxnet.de>
Signed-off-by: NMarek Lindner <lindner_marek@yahoo.de>

It might be possible that 2 threads access the same data in the same
rcu grace period. The first thread calls call_rcu() to decrement the
refcount and free the data while the second thread increases the
refcount to use the data. To avoid this race condition all refcount
operations have to be atomic.
Reported-by: NSven Eckelmann <sven@narfation.org>
Signed-off-by: NMarek Lindner <lindner_marek@yahoo.de>

It might be possible that 2 threads access the same data in the same
rcu grace period. The first thread calls call_rcu() to decrement the
refcount and free the data while the second thread increases the
refcount to use the data. To avoid this race condition all refcount
operations have to be atomic.
Reported-by: NSven Eckelmann <sven@narfation.org>
Signed-off-by: NMarek Lindner <lindner_marek@yahoo.de>

It might be possible that 2 threads access the same data in the same
rcu grace period. The first thread calls call_rcu() to decrement the
refcount and free the data while the second thread increases the
refcount to use the data. To avoid this race condition all refcount
operations have to be atomic.
Reported-by: NSven Eckelmann <sven@narfation.org>
Signed-off-by: NMarek Lindner <lindner_marek@yahoo.de>

It might be possible that 2 threads access the same data in the same
rcu grace period. The first thread calls call_rcu() to decrement the
refcount and free the data while the second thread increases the
refcount to use the data. To avoid this race condition all refcount
operations have to be atomic.
Reported-by: NSven Eckelmann <sven@narfation.org>
Signed-off-by: NMarek Lindner <lindner_marek@yahoo.de>