r4333 - in
dists/sarge/kernel/source/kernel-source-2.6.8-2.6.8/debian: .
patches patches/series
Simon Horman
horms at costa.debian.org
Thu Oct 6 15:49:48 UTC 2005
Author: horms
Date: 2005-10-06 15:49:46 +0000 (Thu, 06 Oct 2005)
New Revision: 4333
Added:
dists/sarge/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/fix-de_thread-BUG_ON.dpatch
dists/sarge/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/ipv6-fix-per-socket-multicast-filtering.dpatch
dists/sarge/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/ipvs-ip_vs_ftp-breaks-connections.dpatch
dists/sarge/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/tcp-dont-over-clamp-window-in-tcp_clamp_window.dpatch
dists/sarge/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/yenta-oops-fix.dpatch
Modified:
dists/sarge/kernel/source/kernel-source-2.6.8-2.6.8/debian/changelog
dists/sarge/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/series/2.6.8-17
Log:
* yenta-oops-fix.patch
yenta oops fix
From 2.6.13.3
* fix-de_thread-BUG_ON.patch
Fix fs/exec.c:788 (de_thread()) BUG_ON
From 2.6.13.3
* ipv6-fix-per-socket-multicast-filtering.patch
fix IPv6 per-socket multicast filtering in exact-match case
From 2.6.13.3
* ipvs-ip_vs_ftp-breaks-connections.patch
ipvs: ip_vs_ftp breaks connections using persistence
From 2.6.13.3
* tcp-dont-over-clamp-window-in-tcp_clamp_window.patch
TCP: Don't over-clamp window in tcp_clamp_window()
From 2.6.13.3
Modified: dists/sarge/kernel/source/kernel-source-2.6.8-2.6.8/debian/changelog
===================================================================
--- dists/sarge/kernel/source/kernel-source-2.6.8-2.6.8/debian/changelog 2005-10-06 15:48:08 UTC (rev 4332)
+++ dists/sarge/kernel/source/kernel-source-2.6.8-2.6.8/debian/changelog 2005-10-06 15:49:46 UTC (rev 4333)
@@ -288,12 +288,32 @@
USB: ftdi_sio: custom baud rate fix
From 2.6.13.2
+ * yenta-oops-fix.patch
+ yenta oops fix
+ From 2.6.13.3
+
+ * fix-de_thread-BUG_ON.patch
+ Fix fs/exec.c:788 (de_thread()) BUG_ON
+ From 2.6.13.3
+
+ * ipv6-fix-per-socket-multicast-filtering.patch
+ fix IPv6 per-socket multicast filtering in exact-match case
+ From 2.6.13.3
+
+ * ipvs-ip_vs_ftp-breaks-connections.patch
+ ipvs: ip_vs_ftp breaks connections using persistence
+ From 2.6.13.3
+
+ * tcp-dont-over-clamp-window-in-tcp_clamp_window.patch
+ TCP: Don't over-clamp window in tcp_clamp_window()
+ From 2.6.13.3
+
[ dann frazier ]
* mempolicy-check-mode.dpatch
[SECURITY] Input validation in sys_set_mempolicy(); local DoS.
See CAN-2005-3053
- -- Simon Horman <horms at debian.org> Thu, 6 Oct 2005 18:18:56 +0900
+ -- Simon Horman <horms at debian.org> Thu, 6 Oct 2005 19:18:25 +0900
kernel-source-2.6.8 (2.6.8-16) unstable; urgency=low
Added: dists/sarge/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/fix-de_thread-BUG_ON.dpatch
===================================================================
--- dists/sarge/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/fix-de_thread-BUG_ON.dpatch 2005-10-06 15:48:08 UTC (rev 4332)
+++ dists/sarge/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/fix-de_thread-BUG_ON.dpatch 2005-10-06 15:49:46 UTC (rev 4333)
@@ -0,0 +1,71 @@
+From nobody Mon Sep 17 00:00:00 2001
+Subject: [PATCH] Fix fs/exec.c:788 (de_thread()) BUG_ON
+From: Alexander Nyberg <alexn at telia.com>
+Date: Wed Sep 14 18:54:06 2005 +0200
+
+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 at telia.com>
+Cc: Roland McGrath <roland at redhat.com>
+Cc: Andrew Morton <akpm at osdl.org>
+Cc: Ingo Molnar <mingo at elte.hu>
+Acked-by: Andi Kleen <ak at suse.de>
+Signed-off-by: Linus Torvalds <torvalds at osdl.org>
+Signed-off-by: Chris Wright <chrisw at osdl.org>
+---
+ fs/exec.c | 5 ++---
+ 1 files changed, 2 insertions(+), 3 deletions(-)
+
+Backported to Debian's 2.6.8 by Horms
+
+--- from-0001/fs/exec.c
++++ to-work/fs/exec.c 2005-10-06 19:05:35.000000000 +0900
+@@ -716,8 +716,8 @@ static inline int de_thread(struct task_
+ }
+
+ /*
+- * Now there are really no other threads at all,
+- * so it's safe to stop telling them to kill themselves.
++ * There may be one thread left which is just exiting,
++ * but it's safe to stop telling the group to kill themselves.
+ */
+ sig->group_exit = 0;
+
+@@ -756,8 +756,6 @@ no_thread_group:
+ kmem_cache_free(sighand_cachep, oldsighand);
+ }
+
+- if (!thread_group_empty(current))
+- BUG();
+ if (current->tgid != current->pid)
+ BUG();
+ return 0;
Added: dists/sarge/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/ipv6-fix-per-socket-multicast-filtering.dpatch
===================================================================
--- dists/sarge/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/ipv6-fix-per-socket-multicast-filtering.dpatch 2005-10-06 15:48:08 UTC (rev 4332)
+++ dists/sarge/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/ipv6-fix-per-socket-multicast-filtering.dpatch 2005-10-06 15:49:46 UTC (rev 4333)
@@ -0,0 +1,32 @@
+From stable-bounces at linux.kernel.org Thu Sep 15 12:46:31 2005
+To: stable at kernel.org
+From: David Stevens <dlstevens at us.ibm.com>
+Date: Thu, 15 Sep 2005 13:46:06 -0600
+Subject: [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 at us.ibm.com>
+Signed-off-by: Chris Wright <chrisw at osdl.org>
+---
+ net/ipv6/udp.c | 5 ++---
+ 1 files changed, 2 insertions(+), 3 deletions(-)
+
+Backported to Debian's 2.6.8 by Horms
+
+--- from-0001/net/ipv6/udp.c
++++ to-work/net/ipv6/udp.c 2005-10-06 19:09:07.000000000 +0900
+@@ -403,8 +403,7 @@ static struct sock *udp_v6_mcast_next(st
+
+ if (!ipv6_addr_any(&np->rcv_saddr)) {
+ if (!ipv6_addr_cmp(&np->rcv_saddr, loc_addr))
+- return s;
+- continue;
++ continue;
+ }
+ if(!inet6_mc_check(s, loc_addr, rmt_addr))
+ continue;
Added: dists/sarge/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/ipvs-ip_vs_ftp-breaks-connections.dpatch
===================================================================
--- dists/sarge/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/ipvs-ip_vs_ftp-breaks-connections.dpatch 2005-10-06 15:48:08 UTC (rev 4332)
+++ dists/sarge/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/ipvs-ip_vs_ftp-breaks-connections.dpatch 2005-10-06 15:49:46 UTC (rev 4333)
@@ -0,0 +1,253 @@
+From stable-bounces at linux.kernel.org Thu Sep 15 14:13:43 2005
+From: Julian Anastasov <ja at ssi.bg>
+To: stable at kernel.org
+Subject: [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 at ssi.bg>
+Signed-off-by: Chris Wright <chrisw at osdl.org>
+---
+ include/net/ip_vs.h | 3 +++
+ net/ipv4/ipvs/ip_vs_conn.c | 41 ++++++++++++++++++++++++++++++++++++++---
+ net/ipv4/ipvs/ip_vs_core.c | 16 ++++++++--------
+ net/ipv4/ipvs/ip_vs_sync.c | 20 ++++++++++++++------
+ 4 files changed, 63 insertions(+), 17 deletions(-)
+
+Index: linux-2.6.13.y/include/net/ip_vs.h
+===================================================================
+--- linux-2.6.13.y.orig/include/net/ip_vs.h
++++ linux-2.6.13.y/include/net/ip_vs.h
+@@ -84,6 +84,7 @@
+ #define IP_VS_CONN_F_IN_SEQ 0x0400 /* must do input seq adjust */
+ #define IP_VS_CONN_F_SEQ_MASK 0x0600 /* in/out sequence mask */
+ #define IP_VS_CONN_F_NO_CPORT 0x0800 /* no client port set yet */
++#define IP_VS_CONN_F_TEMPLATE 0x1000 /* template, not connection */
+
+ /* Move it to better place one day, for now keep it unique */
+ #define NFC_IPVS_PROPERTY 0x10000
+@@ -740,6 +741,8 @@ enum {
+
+ extern struct ip_vs_conn *ip_vs_conn_in_get
+ (int protocol, __u32 s_addr, __u16 s_port, __u32 d_addr, __u16 d_port);
++extern struct ip_vs_conn *ip_vs_ct_in_get
++(int protocol, __u32 s_addr, __u16 s_port, __u32 d_addr, __u16 d_port);
+ extern struct ip_vs_conn *ip_vs_conn_out_get
+ (int protocol, __u32 s_addr, __u16 s_port, __u32 d_addr, __u16 d_port);
+
+Index: linux-2.6.13.y/net/ipv4/ipvs/ip_vs_conn.c
+===================================================================
+--- linux-2.6.13.y.orig/net/ipv4/ipvs/ip_vs_conn.c
++++ linux-2.6.13.y/net/ipv4/ipvs/ip_vs_conn.c
+@@ -196,6 +196,7 @@ static inline struct ip_vs_conn *__ip_vs
+ list_for_each_entry(cp, &ip_vs_conn_tab[hash], c_list) {
+ if (s_addr==cp->caddr && s_port==cp->cport &&
+ d_port==cp->vport && d_addr==cp->vaddr &&
++ ((!s_port) ^ (!(cp->flags & IP_VS_CONN_F_NO_CPORT))) &&
+ protocol==cp->protocol) {
+ /* HIT */
+ atomic_inc(&cp->refcnt);
+@@ -227,6 +228,40 @@ struct ip_vs_conn *ip_vs_conn_in_get
+ return cp;
+ }
+
++/* Get reference to connection template */
++struct ip_vs_conn *ip_vs_ct_in_get
++(int protocol, __u32 s_addr, __u16 s_port, __u32 d_addr, __u16 d_port)
++{
++ unsigned hash;
++ struct ip_vs_conn *cp;
++
++ hash = ip_vs_conn_hashkey(protocol, s_addr, s_port);
++
++ ct_read_lock(hash);
++
++ list_for_each_entry(cp, &ip_vs_conn_tab[hash], c_list) {
++ if (s_addr==cp->caddr && s_port==cp->cport &&
++ d_port==cp->vport && d_addr==cp->vaddr &&
++ cp->flags & IP_VS_CONN_F_TEMPLATE &&
++ protocol==cp->protocol) {
++ /* HIT */
++ atomic_inc(&cp->refcnt);
++ goto out;
++ }
++ }
++ cp = NULL;
++
++ out:
++ ct_read_unlock(hash);
++
++ IP_VS_DBG(7, "template lookup/in %s %u.%u.%u.%u:%d->%u.%u.%u.%u:%d %s\n",
++ ip_vs_proto_name(protocol),
++ NIPQUAD(s_addr), ntohs(s_port),
++ NIPQUAD(d_addr), ntohs(d_port),
++ cp?"hit":"not hit");
++
++ return cp;
++}
+
+ /*
+ * Gets ip_vs_conn associated with supplied parameters in the ip_vs_conn_tab.
+@@ -367,7 +402,7 @@ ip_vs_bind_dest(struct ip_vs_conn *cp, s
+ atomic_read(&dest->refcnt));
+
+ /* Update the connection counters */
+- if (cp->cport || (cp->flags & IP_VS_CONN_F_NO_CPORT)) {
++ if (!(cp->flags & IP_VS_CONN_F_TEMPLATE)) {
+ /* It is a normal connection, so increase the inactive
+ connection counter because it is in TCP SYNRECV
+ state (inactive) or other protocol inacive state */
+@@ -406,7 +441,7 @@ static inline void ip_vs_unbind_dest(str
+ atomic_read(&dest->refcnt));
+
+ /* Update the connection counters */
+- if (cp->cport || (cp->flags & IP_VS_CONN_F_NO_CPORT)) {
++ if (!(cp->flags & IP_VS_CONN_F_TEMPLATE)) {
+ /* It is a normal connection, so decrease the inactconns
+ or activeconns counter */
+ if (cp->flags & IP_VS_CONN_F_INACTIVE) {
+@@ -776,7 +811,7 @@ void ip_vs_random_dropentry(void)
+ ct_write_lock_bh(hash);
+
+ list_for_each_entry(cp, &ip_vs_conn_tab[hash], c_list) {
+- if (!cp->cport && !(cp->flags & IP_VS_CONN_F_NO_CPORT))
++ if (cp->flags & IP_VS_CONN_F_TEMPLATE)
+ /* connection template */
+ continue;
+
+Index: linux-2.6.13.y/net/ipv4/ipvs/ip_vs_core.c
+===================================================================
+--- linux-2.6.13.y.orig/net/ipv4/ipvs/ip_vs_core.c
++++ linux-2.6.13.y/net/ipv4/ipvs/ip_vs_core.c
+@@ -242,10 +242,10 @@ ip_vs_sched_persist(struct ip_vs_service
+ if (ports[1] == svc->port) {
+ /* Check if a template already exists */
+ if (svc->port != FTPPORT)
+- ct = ip_vs_conn_in_get(iph->protocol, snet, 0,
++ ct = ip_vs_ct_in_get(iph->protocol, snet, 0,
+ iph->daddr, ports[1]);
+ else
+- ct = ip_vs_conn_in_get(iph->protocol, snet, 0,
++ ct = ip_vs_ct_in_get(iph->protocol, snet, 0,
+ iph->daddr, 0);
+
+ if (!ct || !ip_vs_check_template(ct)) {
+@@ -271,14 +271,14 @@ ip_vs_sched_persist(struct ip_vs_service
+ iph->daddr,
+ ports[1],
+ dest->addr, dest->port,
+- 0,
++ IP_VS_CONN_F_TEMPLATE,
+ dest);
+ else
+ ct = ip_vs_conn_new(iph->protocol,
+ snet, 0,
+ iph->daddr, 0,
+ dest->addr, 0,
+- 0,
++ IP_VS_CONN_F_TEMPLATE,
+ dest);
+ if (ct == NULL)
+ return NULL;
+@@ -297,10 +297,10 @@ ip_vs_sched_persist(struct ip_vs_service
+ * port zero template: <protocol,caddr,0,vaddr,0,daddr,0>
+ */
+ if (svc->fwmark)
+- ct = ip_vs_conn_in_get(IPPROTO_IP, snet, 0,
++ ct = ip_vs_ct_in_get(IPPROTO_IP, snet, 0,
+ htonl(svc->fwmark), 0);
+ else
+- ct = ip_vs_conn_in_get(iph->protocol, snet, 0,
++ ct = ip_vs_ct_in_get(iph->protocol, snet, 0,
+ iph->daddr, 0);
+
+ if (!ct || !ip_vs_check_template(ct)) {
+@@ -325,14 +325,14 @@ ip_vs_sched_persist(struct ip_vs_service
+ snet, 0,
+ htonl(svc->fwmark), 0,
+ dest->addr, 0,
+- 0,
++ IP_VS_CONN_F_TEMPLATE,
+ dest);
+ else
+ ct = ip_vs_conn_new(iph->protocol,
+ snet, 0,
+ iph->daddr, 0,
+ dest->addr, 0,
+- 0,
++ IP_VS_CONN_F_TEMPLATE,
+ dest);
+ if (ct == NULL)
+ return NULL;
+Index: linux-2.6.13.y/net/ipv4/ipvs/ip_vs_sync.c
+===================================================================
+--- linux-2.6.13.y.orig/net/ipv4/ipvs/ip_vs_sync.c
++++ linux-2.6.13.y/net/ipv4/ipvs/ip_vs_sync.c
+@@ -297,16 +297,24 @@ static void ip_vs_process_message(const
+
+ p = (char *)buffer + sizeof(struct ip_vs_sync_mesg);
+ for (i=0; i<m->nr_conns; i++) {
++ unsigned flags;
++
+ s = (struct ip_vs_sync_conn *)p;
+- cp = ip_vs_conn_in_get(s->protocol,
+- s->caddr, s->cport,
+- s->vaddr, s->vport);
++ flags = ntohs(s->flags);
++ if (!(flags & IP_VS_CONN_F_TEMPLATE))
++ cp = ip_vs_conn_in_get(s->protocol,
++ s->caddr, s->cport,
++ s->vaddr, s->vport);
++ else
++ cp = ip_vs_ct_in_get(s->protocol,
++ s->caddr, s->cport,
++ s->vaddr, s->vport);
+ if (!cp) {
+ cp = ip_vs_conn_new(s->protocol,
+ s->caddr, s->cport,
+ s->vaddr, s->vport,
+ s->daddr, s->dport,
+- ntohs(s->flags), NULL);
++ flags, NULL);
+ if (!cp) {
+ IP_VS_ERR("ip_vs_conn_new failed\n");
+ return;
+@@ -315,11 +323,11 @@ static void ip_vs_process_message(const
+ } else if (!cp->dest) {
+ /* it is an entry created by the synchronization */
+ cp->state = ntohs(s->state);
+- cp->flags = ntohs(s->flags) | IP_VS_CONN_F_HASHED;
++ cp->flags = flags | IP_VS_CONN_F_HASHED;
+ } /* Note that we don't touch its state and flags
+ if it is a normal entry. */
+
+- if (ntohs(s->flags) & IP_VS_CONN_F_SEQ_MASK) {
++ if (flags & IP_VS_CONN_F_SEQ_MASK) {
+ opt = (struct ip_vs_sync_conn_options *)&s[1];
+ memcpy(&cp->in_seq, opt, sizeof(*opt));
+ p += FULL_CONN_SIZE;
Modified: dists/sarge/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/series/2.6.8-17
===================================================================
--- dists/sarge/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/series/2.6.8-17 2005-10-06 15:48:08 UTC (rev 4332)
+++ dists/sarge/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/series/2.6.8-17 2005-10-06 15:49:46 UTC (rev 4333)
@@ -73,4 +73,9 @@
+ lost-sockfd_put-in-32bit-compat-routing_ioctl.dpatch
+ sungem-enable-and-map-pci-rom-properly.dpatch
+ sunhme-enable-and-map-pci-rom-properly.dpatch
++ fix-de_thread-BUG_ON.dpatch
++ ipv6-fix-per-socket-multicast-filtering.dpatch
++ ipvs-ip_vs_ftp-breaks-connections.dpatch
++ tcp-dont-over-clamp-window-in-tcp_clamp_window.dpatch
++ yenta-oops-fix.dpatch
Added: dists/sarge/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/tcp-dont-over-clamp-window-in-tcp_clamp_window.dpatch
===================================================================
--- dists/sarge/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/tcp-dont-over-clamp-window-in-tcp_clamp_window.dpatch 2005-10-06 15:48:08 UTC (rev 4332)
+++ dists/sarge/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/tcp-dont-over-clamp-window-in-tcp_clamp_window.dpatch 2005-10-06 15:49:46 UTC (rev 4333)
@@ -0,0 +1,51 @@
+From stable-bounces at linux.kernel.org Thu Sep 29 17:19:58 2005
+Date: Thu, 29 Sep 2005 17:19:42 -0700 (PDT)
+To: stable at kernel.org
+From: "David S. Miller" <davem at davemloft.net>
+Subject: [TCP]: Don't over-clamp window in tcp_clamp_window()
+
+From: Alexey Kuznetsov <kuznet at ms2.inr.ac.ru>
+
+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 at davemloft.net>
+Signed-off-by: Chris Wright <chrisw at osdl.org>
+---
+ net/ipv4/tcp_input.c | 2 --
+ 1 files changed, 2 deletions(-)
+
+Index: linux-2.6.13.y/net/ipv4/tcp_input.c
+===================================================================
+--- linux-2.6.13.y.orig/net/ipv4/tcp_input.c
++++ linux-2.6.13.y/net/ipv4/tcp_input.c
+@@ -350,8 +350,6 @@ static void tcp_clamp_window(struct sock
+ app_win -= tp->ack.rcv_mss;
+ app_win = max(app_win, 2U*tp->advmss);
+
+- if (!ofo_win)
+- tp->window_clamp = min(tp->window_clamp, app_win);
+ tp->rcv_ssthresh = min(tp->window_clamp, 2U*tp->advmss);
+ }
+ }
Added: dists/sarge/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/yenta-oops-fix.dpatch
===================================================================
--- dists/sarge/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/yenta-oops-fix.dpatch 2005-10-06 15:48:08 UTC (rev 4332)
+++ dists/sarge/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/yenta-oops-fix.dpatch 2005-10-06 15:49:46 UTC (rev 4333)
@@ -0,0 +1,48 @@
+From nobody Mon Sep 17 00:00:00 2001
+Subject: [PATCH] yenta oops fix
+From: Ivan Kokshaysky <ink at jurassic.park.msu.ru>
+To: Olaf Hering <olh at suse.de>
+Cc: Andreas Koch <koch at esa.informatik.tu-darmstadt.de>, Marcus Wegner <wegner3000 at hotmail.com>
+Date: Wed Sep 14 23:05:30 2005 +0400
+
+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 at jurassic.park.msu.ru>
+Signed-off-by: Linus Torvalds <torvalds at osdl.org>
+Signed-off-by: Chris Wright <chrisw at osdl.org>
+---
+ drivers/pcmcia/yenta_socket.c | 13 ++++++++++++-
+ 1 files changed, 12 insertions(+), 1 deletion(-)
+
+Index: linux-2.6.13.y/drivers/pcmcia/yenta_socket.c
+===================================================================
+--- linux-2.6.13.y.orig/drivers/pcmcia/yenta_socket.c
++++ linux-2.6.13.y/drivers/pcmcia/yenta_socket.c
+@@ -976,7 +976,18 @@ static int __devinit yenta_probe (struct
+ {
+ struct yenta_socket *socket;
+ int ret;
+-
++
++ /*
++ * If we failed to assign proper bus numbers for this cardbus
++ * controller during PCI probe, its subordinate pci_bus is NULL.
++ * Bail out if so.
++ */
++ if (!dev->subordinate) {
++ printk(KERN_ERR "Yenta: no bus associated with %s! "
++ "(try 'pci=assign-busses')\n", pci_name(dev));
++ return -ENODEV;
++ }
++
+ socket = kmalloc(sizeof(struct yenta_socket), GFP_KERNEL);
+ if (!socket)
+ return -ENOMEM;
More information about the Kernel-svn-changes
mailing list