commit 3da68493fb66f25179fb9468994e32050a9f91ae
Author: Chris Wright <chrisw@osdl.org>
Date: Mon Oct 3 16:27:35 2005 -0700
Linux 2.6.13.3
commit 27489ba07fb2336c9ce616f4e118a81afa78e550
Author: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Date: Thu Sep 29 17:19:42 2005 -0700
[PATCH] Don't over-clamp window in tcp_clamp_window()
Handle better the case where the sender sends full sized
frames initially, then moves to a mode where it trickles
out small amounts of data at a time.
This known problem is even mentioned in the comments
above tcp_grow_window() in tcp_input.c, specifically:
...
* The scheme does not work when sender sends good segments opening
* window and then starts to feed us spagetti. But it should work
* in common situations. Otherwise, we have to rely on queue collapsing.
...
When the sender gives full sized frames, the "struct sk_buff" overhead
from each packet is small. So we'll advertize a larger window.
If the sender moves to a mode where small segments are sent, this
ratio becomes tilted to the other extreme and we start overrunning
the socket buffer space.
tcp_clamp_window() tries to address this, but it's clamping of
tp->window_clamp is a wee bit too aggressive for this particular case.
Fix confirmed by Ion Badulescu.
Signed-off-by: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@osdl.org>
commit fd3fb3e1109b3c0ba63358a17d1ebd845ceebdb0
Author: Stephen Hemminger <shemminger@osdl.org>
Date: Tue Sep 20 13:39:47 2005 -0700
[PATCH] tcp: set default congestion control correctly for incoming connections
Patch from Joel Sing to fix the default congestion control algorithm for incoming connections. If a new congestion control handler is added (via module),
it should become the default for new connections. Instead, the incoming
connections use reno. The cause is incorrect
initialisation causes the tcp_init_congestion_control() function to return
after the initial if test fails.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Acked-by: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@osdl.org>
commit 7d9e68d3ec0b72a77c6ce6a272f83844fa4f8e3e
Author: Stephen Hemminger <shemminger@osdl.org>
Date: Tue Sep 20 09:59:25 2005 -0700
[PATCH] skge: set mac address oops with bonding
Here is the patch (fuzz removed) for 2.6.13.2 that fixes
OOPs when using bonding with skge.
Skge driver was bringing link up/down when changing mac
address. This doesn't work in the bonding environment, and is
more effort than needed.
Fixes-bug: http://bugzilla.kernel.org/show_bug.cgi?id=5271
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Sigend-off-by: Chris Wright <chrisw@osdl.org>
commit 38e00d341514cce58a4514904fc6562d586ec4dc
Author: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Date: Mon Sep 19 20:02:32 2005 +0200
[PATCH] uml - Fix x86_64 page leak
We were leaking pmd pages when 3_LEVEL_PGTABLES was enabled. This fixes that,
has been well tested and is included in mainline tree. Please include in -stable
as well.
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Chris Wright <chrisw@osdl.org>
commit 17d6b7c89bee5d10632bd9d05cd79b943f5794a4
Author: Julian Anastasov <ja@ssi.bg>
Date: Mon Oct 3 16:27:18 2005 -0700
[PATCH] ipvs: ip_vs_ftp breaks connections using persistence
ip_vs_ftp when loaded can create NAT connections with unknown
client port for passive FTP. For such expectations we lookup with
cport=0 on incoming packet but it matches the format of the persistence
templates causing packets to other persistent virtual servers to be
forwarded to real server without creating connection. Later the
reply packets are treated as foreign and not SNAT-ed.
If the IPVS box serves both FTP and other services (eg. HTTP)
for the time we wait for first packet for the FTP data connections with
unknown client port (there can be many), other HTTP connections
that have nothing common to the FTP conn break, i.e. HTTP client
sends SYN to the virtual IP but the SYN+ACK is not NAT-ed properly
in IPVS box and the client box returns RST to real server IP. I.e.
the result can be 10% broken HTTP traffic if 10% of the time
there are passive FTP connections in connecting state. It hurts
only IPVS connections.
This patch changes the connection lookup for packets from
clients:
* introduce IP_VS_CONN_F_TEMPLATE connection flag to mark the
connection as template
* create new connection lookup function just for templates - ip_vs_ct_in_get
* make sure ip_vs_conn_in_get hits only connections with
IP_VS_CONN_F_NO_CPORT flag set when s_port is 0. By this way
we avoid returning template when looking for cport=0 (ftp)
Signed-off-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Chris Wright <chrisw@osdl.org>
commit 6ce0c8dfdfdacc4d370ccd51fa5d4cd28118a9cf
Author: David Stevens <dlstevens@us.ibm.com>
Date: Thu Sep 15 13:46:06 2005 -0600
[PATCH] fix IPv6 per-socket multicast filtering in exact-match case
per-socket multicast filters were not being applied to all sockets
in the case of an exact-match bound address, due to an over-exuberant
"return" in the look-up code. Fix below. IPv4 does not have this problem.
Thanks to Hoerdt Mickael for reporting the bug.
Signed-off-by: David L Stevens <dlstevens@us.ibm.com>
Signed-off-by: Chris Wright <chrisw@osdl.org>
commit 99e56fc6ee51c66c0d248c6dea7a45d70e15604e
Author: Alexander Nyberg <alexn@telia.com>
Date: Wed Sep 14 18:54:06 2005 +0200
[PATCH] Fix fs/exec.c:788 (de_thread()) BUG_ON
It turns out that the BUG_ON() in fs/exec.c: de_thread() is unreliable
and can trigger due to the test itself being racy.
de_thread() does
while (atomic_read(&sig->count) > count) {
}
.....
.....
BUG_ON(!thread_group_empty(current));
but release_task does
write_lock_irq(&tasklist_lock)
__exit_signal
(this is where atomic_dec(&sig->count) is run)
__exit_sighand
__unhash_process
takes write lock on tasklist_lock
remove itself out of PIDTYPE_TGID list
write_unlock_irq(&tasklist_lock)
so there's a clear (although small) window between the
atomic_dec(&sig->count) and the actual PIDTYPE_TGID unhashing of the
thread.
And actually there is no need for all threads to have exited at this
point, so we simply kill the BUG_ON.
Big thanks to Marc Lehmann who provided the test-case.
Fixes Bug 5170 (http://bugme.osdl.org/show_bug.cgi?id=5170)
Signed-off-by: Alexander Nyberg <alexn@telia.com>
Cc: Roland McGrath <roland@redhat.com>
Cc: Andrew Morton <akpm@osdl.org>
Cc: Ingo Molnar <mingo@elte.hu>
Acked-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Chris Wright <chrisw@osdl.org>
commit ef1b2a3b4cd1addfe039a4bb8105098d83bd6503
Author: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Date: Wed Sep 14 23:05:30 2005 +0400
[PATCH] yenta oops fix
In some cases, especially on modern laptops with a lot of PCI and
cardbus bridges, we're unable to assign correct secondary/subordinate
bus numbers to all cardbus bridges due to BIOS limitations unless
we are using "pci=assign-busses" boot option.
So some cardbus controllers may not have attached subordinate pci_bus
structure, and yenta driver must cope with it - just ignore such cardbus
bridges.
For example, see https://bugzilla.novell.com/show_bug.cgi?id=113778
Signed-off-by: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Chris Wright <chrisw@osdl.org>
www.fiveanddime.net
