linux-stable.git/drivers/net, branch linux-2.6.29.y

bonding: fix multiple module load problem

2009-07-02T23:40:39+00:00

[ Upstream commit 130aa61a77b8518f1ea618e1b7d214d60b405f10 ]

Some users still load bond module multiple times to create bonding
devices.  This accidentally was broken by a later patch about
the time sysfs was fixed.  According to Jay, it was broken
by:
   commit b8a9787eddb0e4665f31dd1d64584732b2b5d051
   Author: Jay Vosburgh 
   Date:   Fri Jun 13 18:12:04 2008 -0700

     bonding: Allow setting max_bonds to zero

Note: sysfs and procfs still produce WARN() messages when this is done
so the sysfs method is the recommended API.

Signed-off-by: Stephen Hemminger 
Signed-off-by: Jay Vosburgh 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

r8169: fix crash when large packets are received

2009-07-02T23:40:33+00:00

commit fdd7b4c3302c93f6833e338903ea77245eb510b4 upstream.

Michael Tokarev reported receiving a large packet could crash
a machine with RTL8169 NIC.
( original thread at http://lkml.org/lkml/2009/6/8/192 )

Problem is this driver tells that NIC frames up to 16383 bytes
can be received but provides skb to rx ring allocated with
smaller sizes (1536 bytes in case standard 1500 bytes MTU is used)

When a frame larger than what was allocated by driver is received,
dma transfert can occurs past the end of buffer and corrupt
kernel memory.

Fix is to tell to NIC what is the maximum size a frame can be.

This bug is very old, (before git introduction, linux-2.6.10), and
should be backported to stable versions.

Reported-by: Michael Tokarev 
Signed-off-by: Eric Dumazet 
Tested-by: Michael Tokarev 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

bnx2: Fix panic in bnx2_poll_work().

2009-06-15T16:40:13+00:00

commit 581daf7e00c5e766f26aff80a61a860a17b0d75a upstream.

Add barrier() to bnx2_get_hw_{tx|rx}_cons() to fix this issue:

http://bugzilla.kernel.org/show_bug.cgi?id=12698

This issue was reported by multiple i386 users.  Without barrier(),
the compiled code looks like the following where %eax contains the
address of the tx_cons or rx_cons in the DMA status block.  The
status block contents can change between the cmpb and the movzwl
instruction.  The driver would crash if the value was not 0xff during
the cmpb instruction, but changed to 0xff during the movzwl
instruction.

6828:	80 38 ff             	cmpb   $0xff,(%eax)
682b:	0f b7 10             	movzwl (%eax),%edx

With the added barrier(), the compiled code now looks correct:

683d:	0f b7 10             	movzwl (%eax),%edx
6840:	0f b6 c2             	movzbl %dl,%eax
6843:	3d ff 00 00 00       	cmp    $0xff,%eax

Thanks to Pascal de Bruijn  for reporting the
problem and Holger Noefer  for patiently
testing test patches for us.

[greg - took out version change]

Signed-off-by: Michael Chan 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: update key flags at time key is set

2009-06-15T16:40:11+00:00

commit 299f5462087f3bc2141e6bc83ba7e2b15d8a07d2 upstream.

We need to be symmetrical in what is done when key is set and cleared.
This is important wrt the key flags as they are used during key
clearing and if they are not set when the key is set the key cannot be
cleared completely.

This addresses the many occurences of the WARN found in
iwl_set_tkip_dynamic_key_info() and tracked in
http://www.kerneloops.org/searchweek.php?search=iwl_set_dynamic_key

If calling iwl_set_tkip_dynamic_key_info()/iwl_remove_dynamic_key()
pair a few times in a row will cause that we run out of key space.
This is because the index stored in the key flags is used by
iwl_remove_dynamic_key() to decide if it should remove the key.
Unfortunately the key flags, and hence the key index is currently only
set at the time the key is written to the device (in
iwl_update_tkip_key()) and _not_ in iwl_set_tkip_dynamic_key_info().
Fix this by setting flags in iwl_set_tkip_dynamic_key_info().

Signed-off-by: Reinette Chatre 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

igb: fix LRO warning

2009-06-15T16:40:11+00:00

This fix is only needed for 2.6.29.y tree, since in 2.6.30 and later IGB
has moved to using GRO instead of LRO.

igb supports LRO, but was not setting any hooks to the ->set_flags
ethtool_ops function.  This would trigger warnings if the user tried
to enable or disable LRO.

Based on the patch provided by Stephen Hemminger 

Reported-by: Sergey Kononenko 
Signed-off-by: Jeff Kirsher 
CC: Stephen Hemminger 
Signed-off-by: Greg Kroah-Hartman

e1000: add missing length check to e1000 receive routine

2009-06-15T16:40:10+00:00

commit ea30e11970a96cfe5e32c03a29332554573b4a10 upstream.

	Patch to fix bad length checking in e1000.  E1000 by default does two
things:

1) Spans rx descriptors for packets that don't fit into 1 skb on recieve
2) Strips the crc from a frame by subtracting 4 bytes from the length prior to
doing an skb_put

Since the e1000 driver isn't written to support receiving packets that span
multiple rx buffers, it checks the End of Packet bit of every frame, and
discards it if its not set.  This places us in a situation where, if we have a
spanning packet, the first part is discarded, but the second part is not (since
it is the end of packet, and it passes the EOP bit test).  If the second part of
the frame is small (4 bytes or less), we subtract 4 from it to remove its crc,
underflow the length, and wind up in skb_over_panic, when we try to skb_put a
huge number of bytes into the skb.  This amounts to a remote DOS attack through
careful selection of frame size in relation to interface MTU.  The fix for this
is already in the e1000e driver, as well as the e1000 sourceforge driver, but no
one ever pushed it to e1000.  This is lifted straight from e1000e, and prevents
small frames from causing the underflow described above

Signed-off-by: Neil Horman 
Tested-by: Andy Gospodarek 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

r8169: avoid losing MSI interrupts

2009-06-15T16:39:56+00:00

[ Upstream commit f11a377b3f4e897d11f0e8d1fc688667e2f19708 ]

The 8169 chip only generates MSI interrupts when all enabled event
sources are quiescent and one or more sources transition to active. If
not all of the active events are acknowledged, or a new event becomes
active while the existing ones are cleared in the handler, we will not
see a new interrupt.

The current interrupt handler masks off the Rx and Tx events once the
NAPI handler has been scheduled, which opens a race window in which we
can get another Rx or Tx event and never ACK'ing it, stopping all
activity until the link is reset (ifconfig down/up). Fix this by always
ACK'ing all event sources, and loop in the handler until we have all
sources quiescent.

Signed-off-by: David Dillow 
Tested-by: Michael Buesch 
Tested-by: Michael Riepe 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

bonding: Remove debug printk

2009-06-15T16:39:55+00:00

[ Upstream commit 2690f8d62e98779c71625dba9a0fd525d8b2263d ]

	Remove debug printk I accidently left in as part of commit:

commit 6146b1a4da98377e4abddc91ba5856bef8f23f1e
Author: Jay Vosburgh 
Date:   Tue Nov 4 17:51:15 2008 -0800

    bonding: Fix ALB mode to balance traffic on VLANs

	Reported by Duncan Gibb 

Signed-off-by: Jay Vosburgh 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

bonding: fix alb mode locking regression

2009-06-15T16:39:55+00:00

[ Upstream commit 815bcc2719c12b6f5b511706e2d19728e07f0b02 ]

Fix locking issue in alb MAC address management; removed
incorrect locking and replaced with correct locking.  This bug was
introduced in commit 059fe7a578fba5bbb0fdc0365bfcf6218fa25eb0
("bonding: Convert locks to _bh, rework alb locking for new locking")

	Bug reported by Paul Smith , who also
tested the fix.

Signed-off-by: Jay Vosburgh 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

mac8390: fix regression caused during net_device_ops conversion

2009-06-15T16:39:54+00:00

[ Upstream commit 217cbfa856dc1cbc2890781626c4032d9e3ec59f ]

Changeset ca17584bf2ad1b1e37a5c0e4386728cc5fc9dabc ("mac8390: update
to net_device_ops") broke mac8390 by adding 8390.o to the link. That
meant that lib8390.c was included twice, once in mac8390.c and once in
8390.c, subject to different macros. This patch reverts that by
avoiding the wrappers in 8390.c. They seem to be of no value since
COMPAT_NET_DEV_OPS is going away soon.

Tested with a Kinetics EtherPort card.

Signed-off-by: Finn Thain 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman