kernel/linux.git, branch v2.6.13.3

Linux 2.6.13.3

2005-10-03T23:27:35+00:00

[PATCH] Don't over-clamp window in tcp_clamp_window()

2005-10-03T23:27:19+00:00

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" Signed-off-by: Chris Wright

[PATCH] tcp: set default congestion control correctly for incoming connections

2005-10-03T23:27:18+00:00

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 Acked-by: "David S. Miller" Signed-off-by: Chris Wright

[PATCH] skge: set mac address oops with bonding

2005-10-03T23:27:18+00:00

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 Sigend-off-by: Chris Wright

[PATCH] uml - Fix x86_64 page leak

2005-10-03T23:27:18+00:00

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 Signed-off-by: Paolo 'Blaisorblade' Giarrusso Signed-off-by: Chris Wright

[PATCH] ipvs: ip_vs_ftp breaks connections using persistence

2005-10-03T23:27:18+00:00

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 Signed-off-by: Chris Wright

[PATCH] fix IPv6 per-socket multicast filtering in exact-match case

2005-10-03T23:27:17+00:00

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 Signed-off-by: Chris Wright

[PATCH] Fix fs/exec.c:788 (de_thread()) BUG_ON

2005-10-03T23:27:17+00:00

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 Cc: Roland McGrath Cc: Andrew Morton Cc: Ingo Molnar Acked-by: Andi Kleen Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright

[PATCH] yenta oops fix

2005-10-03T23:27:17+00:00

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 Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright

Linux 2.6.13.2

2005-09-17T01:02:12+00:00