From: Greg Kroah-Hartman Date: Thu, 7 Feb 2008 07:34:37 +0000 (-0800) Subject: more .24 patches X-Git-Tag: v2.6.22.19~32 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=c9ae500472627bb7b729eff0180c90d1827b5590;p=thirdparty%2Fkernel%2Fstable-queue.git more .24 patches --- diff --git a/queue-2.6.24/b43-reject-new-firmware-early.patch b/queue-2.6.24/b43-reject-new-firmware-early.patch new file mode 100644 index 00000000000..79b6196ee19 --- /dev/null +++ b/queue-2.6.24/b43-reject-new-firmware-early.patch @@ -0,0 +1,48 @@ +From stable-bounces@linux.kernel.org Sat Jan 26 04:57:05 2008 +From: Michael Buesch +Date: Sat, 26 Jan 2008 13:54:52 +0100 +Subject: b43: Reject new firmware early +To: stable@kernel.org +Cc: linux-wireless@vger.kernel.org, Bcm43xx-dev@lists.berlios.de +Message-ID: <200801261354.52659.mb@bu3sch.de> +Content-Disposition: inline + +From: Michael Buesch + +(not in mainline, as it is not applicable.) + +We must reject new incompatible firmware early to avoid +running into strange transmission failures. + +The current development tree supports newer firmware revisions. +These revisions cause strange failures on the stable 2.6.24 kernel. +Add a check to avoid confusing users a lot. + +Signed-off-by: Michael Buesch +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/b43/main.c | 12 ++++++++++++ + 1 file changed, 12 insertions(+) + +--- a/drivers/net/wireless/b43/main.c ++++ b/drivers/net/wireless/b43/main.c +@@ -1800,6 +1800,18 @@ static int b43_upload_microcode(struct b + err = -EOPNOTSUPP; + goto out; + } ++ if (fwrev > 351) { ++ b43err(dev->wl, "YOUR FIRMWARE IS TOO NEW. Please downgrade your " ++ "firmware.\n"); ++ b43err(dev->wl, "Use this firmware tarball: " ++ "http://downloads.openwrt.org/sources/broadcom-wl-4.80.53.0.tar.bz2\n"); ++ b43err(dev->wl, "Use this b43-fwcutter tarball: " ++ "http://bu3sch.de/b43/fwcutter/b43-fwcutter-009.tar.bz2\n"); ++ b43err(dev->wl, "Read, understand and _do_ what this message says, please.\n"); ++ b43_write32(dev, B43_MMIO_MACCTL, 0); ++ err = -EOPNOTSUPP; ++ goto out; ++ } + b43dbg(dev->wl, "Loading firmware version %u.%u " + "(20%.2i-%.2i-%.2i %.2i:%.2i:%.2i)\n", + fwrev, fwpatch, diff --git a/queue-2.6.24/fix-writev-regression-pan-hanging-unkillable-and-un-straceable.patch b/queue-2.6.24/fix-writev-regression-pan-hanging-unkillable-and-un-straceable.patch new file mode 100644 index 00000000000..ddb5d7b7360 --- /dev/null +++ b/queue-2.6.24/fix-writev-regression-pan-hanging-unkillable-and-un-straceable.patch @@ -0,0 +1,70 @@ +From mingo@elte.hu Sat Feb 2 06:01:49 2008 +From: Nick Piggin +Date: Sat, 2 Feb 2008 15:01:17 +0100 +Subject: fix writev regression: pan hanging unkillable and un-straceable +To: Linus Torvalds +Cc: Andrew Morton , Nick Piggin , "Rafael J. Wysocki" , Greg Kroah-Hartman , stable@kernel.org +Message-ID: <20080202140117.GA4038@elte.hu> +Content-Disposition: inline + +From: Nick Piggin + +patch 124d3b7041f9a0ca7c43a6293e1cae4576c32fd5 in mainline. + +Frederik Himpe reported an unkillable and un-straceable pan process. + +Zero length iovecs can go into an infinite loop in writev, because the +iovec iterator does not always advance over them. + +The sequence required to trigger this is not trivial. I think it +requires that a zero-length iovec be followed by a non-zero-length iovec +which causes a pagefault in the atomic usercopy. This causes the writev +code to drop back into single-segment copy mode, which then tries to +copy the 0 bytes of the zero-length iovec; a zero length copy looks like +a failure though, so it loops. + +Put a test into iov_iter_advance to catch zero-length iovecs. We could +just put the test in the fallback path, but I feel it is more robust to +skip over zero-length iovecs throughout the code (iovec iterator may be +used in filesystems too, so it should be robust). + +Signed-off-by: Nick Piggin +Signed-off-by: Ingo Molnar +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/filemap.c | 8 ++++++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +--- a/mm/filemap.c ++++ b/mm/filemap.c +@@ -1733,7 +1733,11 @@ static void __iov_iter_advance_iov(struc + const struct iovec *iov = i->iov; + size_t base = i->iov_offset; + +- while (bytes) { ++ /* ++ * The !iov->iov_len check ensures we skip over unlikely ++ * zero-length segments. ++ */ ++ while (bytes || !iov->iov_len) { + int copy = min(bytes, iov->iov_len - base); + + bytes -= copy; +@@ -2251,6 +2255,7 @@ again: + + cond_resched(); + ++ iov_iter_advance(i, copied); + if (unlikely(copied == 0)) { + /* + * If we were unable to copy any data at all, we must +@@ -2264,7 +2269,6 @@ again: + iov_iter_single_seg_count(i)); + goto again; + } +- iov_iter_advance(i, copied); + pos += copied; + written += copied; + diff --git a/queue-2.6.24/sched-fix-high-wake-up-latencies-with-fair_user_sched.patch b/queue-2.6.24/sched-fix-high-wake-up-latencies-with-fair_user_sched.patch new file mode 100644 index 00000000000..4fb1c41e4d0 --- /dev/null +++ b/queue-2.6.24/sched-fix-high-wake-up-latencies-with-fair_user_sched.patch @@ -0,0 +1,45 @@ +From 296825cbe14d4c95ee9c41ca5824f7487bfb4d9d Mon Sep 17 00:00:00 2001 +From: Srivatsa Vaddagiri +Date: Thu, 31 Jan 2008 22:45:22 +0100 +Subject: sched: fix high wake up latencies with FAIR_USER_SCHED + +From: Srivatsa Vaddagiri + +patch 296825cbe14d4c95ee9c41ca5824f7487bfb4d9d in mainline. + +The reason why we are getting better wakeup latencies for +!FAIR_USER_SCHED is because of this snippet of code in place_entity(): + + if (!initial) { + /* sleeps upto a single latency don't count. */ + if (sched_feat(NEW_FAIR_SLEEPERS) && entity_is_task(se)) + ^^^^^^^^^^^^^^^^^^ + vruntime -= sysctl_sched_latency; + + /* ensure we never gain time by being placed backwards. */ + vruntime = max_vruntime(se->vruntime, vruntime); + } + +NEW_FAIR_SLEEPERS feature gives credit for sleeping only to tasks and +not group-level entities. With the patch attached, I could see that +wakeup latencies with FAIR_USER_SCHED are restored to the same level as +!FAIR_USER_SCHED. + +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/sched_fair.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/kernel/sched_fair.c ++++ b/kernel/sched_fair.c +@@ -511,7 +511,7 @@ place_entity(struct cfs_rq *cfs_rq, stru + + if (!initial) { + /* sleeps upto a single latency don't count. */ +- if (sched_feat(NEW_FAIR_SLEEPERS) && entity_is_task(se)) ++ if (sched_feat(NEW_FAIR_SLEEPERS)) + vruntime -= sysctl_sched_latency; + + /* ensure we never gain time by being placed backwards. */ diff --git a/queue-2.6.24/sched-let-nice-tasks-have-smaller-impact.patch b/queue-2.6.24/sched-let-nice-tasks-have-smaller-impact.patch new file mode 100644 index 00000000000..fa8e10c0546 --- /dev/null +++ b/queue-2.6.24/sched-let-nice-tasks-have-smaller-impact.patch @@ -0,0 +1,51 @@ +From ef9884e6f29bbe1075204f962a00f7533bf7e8f3 Mon Sep 17 00:00:00 2001 +From: Peter Zijlstra +Date: Thu, 31 Jan 2008 22:45:22 +0100 +Subject: sched: let +nice tasks have smaller impact +MIME-Version: 1.0 +Content-Type: text/plain; charset=utf-8 +Content-Transfer-Encoding: 8bit + +From: Peter Zijlstra + +patch ef9884e6f29bbe1075204f962a00f7533bf7e8f3 in mainline. + +Michel Dänzr has bisected an interactivity problem with +plus-reniced tasks back to this commit: + + 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8 is first bad commit + commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8 + Author: Peter Zijlstra + Date: Mon Oct 15 17:00:14 2007 +0200 + + sched: another wakeup_granularity fix + + unit mis-match: wakeup_gran was used against a vruntime + +fix this by assymetrically scaling the vtime of positive reniced +tasks. + +Bisected-by: Michel Dänzer +Signed-off-by: Peter Zijlstra +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/sched_fair.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/kernel/sched_fair.c ++++ b/kernel/sched_fair.c +@@ -867,7 +867,11 @@ static void check_preempt_wakeup(struct + } + + gran = sysctl_sched_wakeup_granularity; +- if (unlikely(se->load.weight != NICE_0_LOAD)) ++ /* ++ * More easily preempt - nice tasks, while not making ++ * it harder for + nice tasks. ++ */ ++ if (unlikely(se->load.weight > NICE_0_LOAD)) + gran = calc_delta_fair(gran, &se->load); + + if (pse->vruntime + gran < se->vruntime) diff --git a/queue-2.6.24/series b/queue-2.6.24/series index d4c74af3199..e7a463b3f78 100644 --- a/queue-2.6.24/series +++ b/queue-2.6.24/series @@ -36,3 +36,7 @@ b43legacy-fix-suspend-resume.patch b43legacy-drop-packets-we-are-not-able-to-encrypt.patch b43legacy-fix-dma-slot-resource-leakage.patch selinux-fix-labeling-of-proc-net-inodes.patch +b43-reject-new-firmware-early.patch +sched-let-nice-tasks-have-smaller-impact.patch +sched-fix-high-wake-up-latencies-with-fair_user_sched.patch +fix-writev-regression-pan-hanging-unkillable-and-un-straceable.patch