- 08 Mar, 2011 8 commits
-
-
Emil Tantilov authored
The 82599 was not correctly having some of it's counters cleared for flow control. This change corrects that. Signed-off-by:
Emil Tantilov <emil.s.tantilov@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Emil Tantilov authored
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:
Stephen Ko <stephen.s.ko@intel.com> Signed-off-by:
-
Yi Zou authored
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:
Yi Zou <yi.zou@intel.com> Signed-off-by:
Kiran Patil <kiran.patil@intel.com> Signed-off-by:
-
Yi Zou authored
Add the new target ddp offload support ndo_fcoe_ddp_target(). Signed-off-by:
-
Yi Zou authored
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:
Kavindya Deegala <kavindya.s.deegala@intel.com> Signed-off-by:
-
Don Skidmore authored
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:
-
Carolyn Wyborny authored
This patch adds statistics output for OS2BMC feature which is configured by eeprom on capable devices. Signed-off-by:
Carolyn Wyborny <carolyn.wyborny@intel.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
-
Emil Tantilov authored
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:
Bruce Allan <bruce.w.allan@intel.com> Tested-by:
Jeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by:
-
- 07 Mar, 2011 15 commits
-
-
Changli Gao authored
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:
Changli Gao <xiaosuo@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Changli Gao authored
These two functions are only used when net poll controller is enabled. Signed-off-by:
-
-
Jiri Pirko authored
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:
Jiri Pirko <jpirko@redhat.com> Reviewed-by:
Nicolas de Pesloüan <nicolas.2p.debian@free.fr> Signed-off-by:
-
Padmanabh Ratnakar authored
Lancer requires multicast capability flag set during IFACE_CREATE for adding multicast filters. Signed-off-by:
Padmanabh Ratnakar <padmanabh.ratnakar@emulex.com> Signed-off-by:
Sathya Perla <sathya.perla@emulex.com> Signed-off-by:
Subramanian Seetharaman <subbu.seetharaman@emulex.com> Signed-off-by:
-
Padmanabh Ratnakar authored
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:
-
Padmanabh Ratnakar authored
Remove TX Queue stop in close Signed-off-by:
-
Padmanabh Ratnakar authored
Change f/w command versions for Lancer Signed-off-by:
-
Padmanabh Ratnakar authored
Add error recovery during load for Lancer Signed-off-by:
-
Padmanabh Ratnakar authored
L4 checksum field is valid only for TCP/UDP packets in Lancer Signed-off-by:
-
Padmanabh Ratnakar authored
Workaround added for Lancer in handling RX ERR completion received when no RX buffers are posted is not needed. Signed-off-by:
-
David S. Miller authored
This elimiates a lot of pure overhead due to parameter passing. Signed-off-by: -
David S. Miller authored
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: -
Joe Perches authored
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:
Joe Perches <joe@perches.com> Signed-off-by:
-
-
- 05 Mar, 2011 17 commits
-
-
Sven Eckelmann authored
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:
Linus Lüssing <linus.luessing@ascom.ch> Signed-off-by:
Marek Lindner <lindner_marek@yahoo.de>
-
Linus Lüssing authored
Signed-off-by:
-
Marek Lindner authored
Signed-off-by: -
Marek Lindner authored
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: -
Marek Lindner authored
Signed-off-by: -
Marek Lindner authored
Signed-off-by: -
Marek Lindner authored
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:
Sven Eckelmann <sven@narfation.org> Signed-off-by:
-
Marek Lindner authored
Signed-off-by: -
Marek Lindner authored
Note: The function compare_ether_addr() provided by the Linux kernel requires aligned memory. Signed-off-by: -
Linus Lüssing authored
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:
-
Linus Lüssing authored
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:
-
Linus Lüssing authored
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:
-
Marek Lindner authored
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:
Linus Lüssing <linus.luessing@web.de> Signed-off-by:
-
Marek Lindner authored
Reported-by:
Linus Lüssing <linus.luessing@saxnet.de> Signed-off-by:
-
Marek Lindner authored
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:
-
Marek Lindner authored
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:
-
Marek Lindner authored
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:
-
