From: Greg Kroah-Hartman Date: Tue, 5 May 2009 16:43:39 +0000 (-0700) Subject: .29 patches added and others cleaned up X-Git-Tag: v2.6.27.23~7 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=1c318a60da38a448b26a0cb9ad87820c4146c0b0;p=thirdparty%2Fkernel%2Fstable-queue.git .29 patches added and others cleaned up --- diff --git a/ath5k-fix-buffer-overrun-in-rate-debug-code.patch b/ath5k-fix-buffer-overrun-in-rate-debug-code.patch new file mode 100644 index 00000000000..e1d3664b847 --- /dev/null +++ b/ath5k-fix-buffer-overrun-in-rate-debug-code.patch @@ -0,0 +1,34 @@ +From b7fcb5c4a4c27da2f6d86cb03d18687e537442cf Mon Sep 17 00:00:00 2001 +From: Bob Copeland +Date: Mon, 27 Apr 2009 22:12:43 -0400 +Subject: ath5k: fix buffer overrun in rate debug code + +From: Bob Copeland + +commit b7fcb5c4a4c27da2f6d86cb03d18687e537442cf upstream. + +char bname[5] is too small for the string "X GHz" when the null +terminator is taken into account. Thus, turning on rate debugging +can crash unless we have lucky stack alignment. + +Cc: stable@kernel.org +Reported-by: Paride Legovini +Signed-off-by: Bob Copeland +Signed-off-by: John W. Linville +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/ath5k/debug.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/wireless/ath5k/debug.c ++++ b/drivers/net/wireless/ath5k/debug.c +@@ -465,7 +465,7 @@ ath5k_debug_dump_bands(struct ath5k_soft + + for (b = 0; b < IEEE80211_NUM_BANDS; b++) { + struct ieee80211_supported_band *band = &sc->sbands[b]; +- char bname[5]; ++ char bname[6]; + switch (band->band) { + case IEEE80211_BAND_2GHZ: + strcpy(bname, "2 GHz"); diff --git a/cs5536-define-dma_sff_read_status-method.patch b/cs5536-define-dma_sff_read_status-method.patch new file mode 100644 index 00000000000..2493d93ebd1 --- /dev/null +++ b/cs5536-define-dma_sff_read_status-method.patch @@ -0,0 +1,36 @@ +From sshtylyov@ru.mvista.com Tue May 5 09:23:41 2009 +From: Sergei Shtylyov +Date: Tue, 5 May 2009 15:34:34 +0400 +Subject: cs5536: define dma_sff_read_status() method +To: stable@kernel.org +Message-ID: <200905051534.34672.sshtylyov@ru.mvista.com> + +From: Sergei Shtylyov + +commit 15da90b516e9da92cc1d90001e640fd6707d0e27 upstream. + +The driver somehow got merged with the initializer for the dma_sff_read_status() +method missing which caused kernel panic on bootup. + +This should fix the kernel.org bug #13026... + +Signed-off-by: Sergei Shtylyov +Reported-by: Arnd Hannemann +Signed-off-by: Bartlomiej Zolnierkiewicz +Signed-off-by: Greg Kroah-Hartman + + +--- + drivers/ide/cs5536.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/ide/cs5536.c ++++ b/drivers/ide/cs5536.c +@@ -237,6 +237,7 @@ static const struct ide_dma_ops cs5536_d + .dma_test_irq = ide_dma_test_irq, + .dma_lost_irq = ide_dma_lost_irq, + .dma_timeout = ide_dma_timeout, ++ .dma_sff_read_status = ide_dma_sff_read_status, + }; + + static const struct ide_port_info cs5536_info = { diff --git a/intel-iommu-avoid-panic-for-drhd-at-address-zero.patch b/intel-iommu-avoid-panic-for-drhd-at-address-zero.patch new file mode 100644 index 00000000000..d599cc2fa12 --- /dev/null +++ b/intel-iommu-avoid-panic-for-drhd-at-address-zero.patch @@ -0,0 +1,51 @@ +From dwmw2@infradead.org Tue May 5 09:26:07 2009 +From: David Woodhouse +Date: Tue, 05 May 2009 09:25:28 +0100 +Subject: intel-iommu: Avoid panic() for DRHD at address zero. +To: stable@kernel.org +Message-ID: <1241511928.6126.189.camel@macbook.infradead.org> + +From: David Woodhouse + +(cherry picked from commit e523b38e2f568af58baa13120a994cbf24e6dee0) + +If the BIOS does something obviously stupid, like claiming that the +registers for the IOMMU are at physical address zero, then print a nasty +message and abort, rather than trying to set up the IOMMU and then later +panicking. + +It's becoming more and more obvious that trusting this stuff to the BIOS +was a mistake. + +Signed-off-by: David Woodhouse +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/pci/dmar.c | 11 ++++++++++- + 1 file changed, 10 insertions(+), 1 deletion(-) + +--- a/drivers/pci/dmar.c ++++ b/drivers/pci/dmar.c +@@ -170,12 +170,21 @@ dmar_parse_one_drhd(struct acpi_dmar_hea + struct dmar_drhd_unit *dmaru; + int ret = 0; + ++ drhd = (struct acpi_dmar_hardware_unit *)header; ++ if (!drhd->address) { ++ /* Promote an attitude of violence to a BIOS engineer today */ ++ WARN(1, "Your BIOS is broken; DMAR reported at address zero!\n" ++ "BIOS vendor: %s; Ver: %s; Product Version: %s\n", ++ dmi_get_system_info(DMI_BIOS_VENDOR), ++ dmi_get_system_info(DMI_BIOS_VERSION), ++ dmi_get_system_info(DMI_PRODUCT_VERSION)); ++ return -ENODEV; ++ } + dmaru = kzalloc(sizeof(*dmaru), GFP_KERNEL); + if (!dmaru) + return -ENOMEM; + + dmaru->hdr = header; +- drhd = (struct acpi_dmar_hardware_unit *)header; + dmaru->reg_base_addr = drhd->address; + dmaru->include_all = drhd->flags & 0x1; /* BIT0: INCLUDE_ALL */ + diff --git a/intel-iommu-fix-device-to-iommu-mapping-for-pci-pci-bridges.patch b/intel-iommu-fix-device-to-iommu-mapping-for-pci-pci-bridges.patch new file mode 100644 index 00000000000..73fc7aa0562 --- /dev/null +++ b/intel-iommu-fix-device-to-iommu-mapping-for-pci-pci-bridges.patch @@ -0,0 +1,48 @@ +From dwmw2@infradead.org Tue May 5 09:25:25 2009 +From: David Woodhouse +Date: Tue, 05 May 2009 09:25:23 +0100 +Subject: intel-iommu: Fix device-to-iommu mapping for PCI-PCI bridges. +To: stable@kernel.org +Message-ID: <1241511923.6126.187.camel@macbook.infradead.org> + +From: David Woodhouse + +(cherry picked from commit 924b6231edfaf1e764ffb4f97ea382bf4facff58) + +When the DMAR table identifies that a PCI-PCI bridge belongs to a given +IOMMU, that means that the bridge and all devices behind it should be +associated with the IOMMU. Not just the bridge itself. + +This fixes the device_to_iommu() function accordingly. + +(It's broken if you have the same PCI bus numbers in multiple domains, +but this function was always broken in that way; I'll be dealing with +that later). + +Signed-off-by: David Woodhouse +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/pci/intel-iommu.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +--- a/drivers/pci/intel-iommu.c ++++ b/drivers/pci/intel-iommu.c +@@ -447,11 +447,16 @@ static struct intel_iommu *device_to_iom + if (drhd->ignored) + continue; + +- for (i = 0; i < drhd->devices_cnt; i++) ++ for (i = 0; i < drhd->devices_cnt; i++) { + if (drhd->devices[i] && + drhd->devices[i]->bus->number == bus && + drhd->devices[i]->devfn == devfn) + return drhd->iommu; ++ if (drhd->devices[i]->subordinate && ++ drhd->devices[i]->subordinate->number <= bus && ++ drhd->devices[i]->subordinate->subordinate >= bus) ++ return drhd->iommu; ++ } + + if (drhd->include_all) + return drhd->iommu; diff --git a/intel-iommu-fix-oops-in-device_to_iommu-when-devices-not-found.patch b/intel-iommu-fix-oops-in-device_to_iommu-when-devices-not-found.patch new file mode 100644 index 00000000000..9b01db5414a --- /dev/null +++ b/intel-iommu-fix-oops-in-device_to_iommu-when-devices-not-found.patch @@ -0,0 +1,34 @@ +From dwmw2@infradead.org Tue May 5 09:25:45 2009 +From: David Woodhouse +Date: Tue, 05 May 2009 09:25:26 +0100 +Subject: intel-iommu: Fix oops in device_to_iommu() when devices not found. +To: stable@kernel.org +Message-ID: <1241511926.6126.188.camel@macbook.infradead.org> + +From: David Woodhouse + +(cherry picked from commit 4958c5dc7bcb2e42d985cd26aeafd8a7eca9ab1e) + +It's possible for a device in the drhd->devices[] array to be NULL if +it wasn't found at boot time, which means we have to check for that +case. + +Signed-off-by: David Woodhouse +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/pci/intel-iommu.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/pci/intel-iommu.c ++++ b/drivers/pci/intel-iommu.c +@@ -452,7 +452,8 @@ static struct intel_iommu *device_to_iom + drhd->devices[i]->bus->number == bus && + drhd->devices[i]->devfn == devfn) + return drhd->iommu; +- if (drhd->devices[i]->subordinate && ++ if (drhd->devices[i] && ++ drhd->devices[i]->subordinate && + drhd->devices[i]->subordinate->number <= bus && + drhd->devices[i]->subordinate->subordinate >= bus) + return drhd->iommu; diff --git a/mv643xx_eth-64bit-mib-counter-read-fix.patch b/mv643xx_eth-64bit-mib-counter-read-fix.patch new file mode 100644 index 00000000000..d39fce35f71 --- /dev/null +++ b/mv643xx_eth-64bit-mib-counter-read-fix.patch @@ -0,0 +1,48 @@ +From 93af7aca44f0e82e67bda10a0fb73d383edcc8bd Mon Sep 17 00:00:00 2001 +From: Lennert Buytenhek +Date: Wed, 29 Apr 2009 11:58:18 +0000 +Subject: mv643xx_eth: 64bit mib counter read fix + +From: Lennert Buytenhek + +commit 93af7aca44f0e82e67bda10a0fb73d383edcc8bd upstream. + +On several mv643xx_eth hardware versions, the two 64bit mib counters +for 'good octets received' and 'good octets sent' are actually 32bit +counters, and reading from the upper half of the register has the same +effect as reading from the lower half of the register: an atomic +read-and-clear of the entire 32bit counter value. This can under heavy +traffic occasionally lead to small numbers being added to the upper +half of the 64bit mib counter even though no 32bit wrap has occured. + +Since we poll the mib counters at least every 30 seconds anyway, we +might as well just skip the reads of the upper halves of the hardware +counters without breaking the stats, which this patch does. + +Signed-off-by: Lennert Buytenhek +Cc: stable@kernel.org +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/mv643xx_eth.c | 2 -- + 1 file changed, 2 deletions(-) + +--- a/drivers/net/mv643xx_eth.c ++++ b/drivers/net/mv643xx_eth.c +@@ -1177,7 +1177,6 @@ static void mib_counters_update(struct m + + spin_lock_bh(&mp->mib_counters_lock); + p->good_octets_received += mib_read(mp, 0x00); +- p->good_octets_received += (u64)mib_read(mp, 0x04) << 32; + p->bad_octets_received += mib_read(mp, 0x08); + p->internal_mac_transmit_err += mib_read(mp, 0x0c); + p->good_frames_received += mib_read(mp, 0x10); +@@ -1191,7 +1190,6 @@ static void mib_counters_update(struct m + p->frames_512_to_1023_octets += mib_read(mp, 0x30); + p->frames_1024_to_max_octets += mib_read(mp, 0x34); + p->good_octets_sent += mib_read(mp, 0x38); +- p->good_octets_sent += (u64)mib_read(mp, 0x3c) << 32; + p->good_frames_sent += mib_read(mp, 0x40); + p->excessive_collision += mib_read(mp, 0x44); + p->multicast_frames_sent += mib_read(mp, 0x48); diff --git a/mv643xx_eth-oom-handling-fixes.patch b/mv643xx_eth-oom-handling-fixes.patch new file mode 100644 index 00000000000..c6b45401cb8 --- /dev/null +++ b/mv643xx_eth-oom-handling-fixes.patch @@ -0,0 +1,114 @@ +From 1319ebadf185933e6b7ff95211d3cef9004e9754 Mon Sep 17 00:00:00 2001 +From: Lennert Buytenhek +Date: Wed, 29 Apr 2009 11:57:34 +0000 +Subject: mv643xx_eth: OOM handling fixes + +From: Lennert Buytenhek + +commit 1319ebadf185933e6b7ff95211d3cef9004e9754 upstream. + +Currently, when OOM occurs during rx ring refill, mv643xx_eth will get +into an infinite loop, due to the refill function setting the OOM bit +but not clearing the 'rx refill needed' bit for this queue, while the +calling function (the NAPI poll handler) will call the refill function +in a loop until the 'rx refill needed' bit goes off, without checking +the OOM bit. + +This patch fixes this by checking the OOM bit in the NAPI poll handler +before attempting to do rx refill. This means that once OOM occurs, +we won't try to do any memory allocations again until the next invocation +of the poll handler. + +While we're at it, change the OOM flag to be a single bit instead of +one bit per receive queue since OOM is a system state rather than a +per-queue state, and cancel the OOM timer on entry to the NAPI poll +handler if it's running to prevent it from firing when we've already +come out of OOM. + +Signed-off-by: Lennert Buytenhek +Cc: stable@kernel.org +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/mv643xx_eth.c | 22 +++++++++++++--------- + 1 file changed, 13 insertions(+), 9 deletions(-) + +--- a/drivers/net/mv643xx_eth.c ++++ b/drivers/net/mv643xx_eth.c +@@ -372,12 +372,12 @@ struct mv643xx_eth_private { + struct work_struct tx_timeout_task; + + struct napi_struct napi; ++ u8 oom; + u8 work_link; + u8 work_tx; + u8 work_tx_end; + u8 work_rx; + u8 work_rx_refill; +- u8 work_rx_oom; + + int skb_size; + struct sk_buff_head rx_recycle; +@@ -603,7 +603,7 @@ static int rxq_refill(struct rx_queue *r + dma_get_cache_alignment() - 1); + + if (skb == NULL) { +- mp->work_rx_oom |= 1 << rxq->index; ++ mp->oom = 1; + goto oom; + } + +@@ -1906,8 +1906,10 @@ static int mv643xx_eth_poll(struct napi_ + + mp = container_of(napi, struct mv643xx_eth_private, napi); + +- mp->work_rx_refill |= mp->work_rx_oom; +- mp->work_rx_oom = 0; ++ if (unlikely(mp->oom)) { ++ mp->oom = 0; ++ del_timer(&mp->rx_oom); ++ } + + work_done = 0; + while (work_done < budget) { +@@ -1921,8 +1923,10 @@ static int mv643xx_eth_poll(struct napi_ + continue; + } + +- queue_mask = mp->work_tx | mp->work_tx_end | +- mp->work_rx | mp->work_rx_refill; ++ queue_mask = mp->work_tx | mp->work_tx_end | mp->work_rx; ++ if (likely(!mp->oom)) ++ queue_mask |= mp->work_rx_refill; ++ + if (!queue_mask) { + if (mv643xx_eth_collect_events(mp)) + continue; +@@ -1943,7 +1947,7 @@ static int mv643xx_eth_poll(struct napi_ + txq_maybe_wake(mp->txq + queue); + } else if (mp->work_rx & queue_mask) { + work_done += rxq_process(mp->rxq + queue, work_tbd); +- } else if (mp->work_rx_refill & queue_mask) { ++ } else if (!mp->oom && (mp->work_rx_refill & queue_mask)) { + work_done += rxq_refill(mp->rxq + queue, work_tbd); + } else { + BUG(); +@@ -1951,7 +1955,7 @@ static int mv643xx_eth_poll(struct napi_ + } + + if (work_done < budget) { +- if (mp->work_rx_oom) ++ if (mp->oom) + mod_timer(&mp->rx_oom, jiffies + (HZ / 10)); + napi_complete(napi); + wrlp(mp, INT_MASK, INT_TX_END | INT_RX | INT_EXT); +@@ -2143,7 +2147,7 @@ static int mv643xx_eth_open(struct net_d + rxq_refill(mp->rxq + i, INT_MAX); + } + +- if (mp->work_rx_oom) { ++ if (mp->oom) { + mp->rx_oom.expires = jiffies + (HZ / 10); + add_timer(&mp->rx_oom); + } diff --git a/proc-avoid-information-leaks-to-non-privileged-processes.patch b/proc-avoid-information-leaks-to-non-privileged-processes.patch new file mode 100644 index 00000000000..b0484f0399e --- /dev/null +++ b/proc-avoid-information-leaks-to-non-privileged-processes.patch @@ -0,0 +1,100 @@ +From f83ce3e6b02d5e48b3a43b001390e2b58820389d Mon Sep 17 00:00:00 2001 +From: Jake Edge +Date: Mon, 4 May 2009 12:51:14 -0600 +Subject: proc: avoid information leaks to non-privileged processes + +From: Jake Edge + +commit f83ce3e6b02d5e48b3a43b001390e2b58820389d upstream. + +By using the same test as is used for /proc/pid/maps and /proc/pid/smaps, +only allow processes that can ptrace() a given process to see information +that might be used to bypass address space layout randomization (ASLR). +These include eip, esp, wchan, and start_stack in /proc/pid/stat as well +as the non-symbolic output from /proc/pid/wchan. + +ASLR can be bypassed by sampling eip as shown by the proof-of-concept +code at http://code.google.com/p/fuzzyaslr/ As part of a presentation +(http://www.cr0.org/paper/to-jt-linux-alsr-leak.pdf) esp and wchan were +also noted as possibly usable information leaks as well. The +start_stack address also leaks potentially useful information. + +Cc: Stable Team +Signed-off-by: Jake Edge +Acked-by: Arjan van de Ven +Acked-by: "Eric W. Biederman" +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + fs/proc/array.c | 13 +++++++++---- + fs/proc/base.c | 5 ++++- + 2 files changed, 13 insertions(+), 5 deletions(-) + +--- a/fs/proc/array.c ++++ b/fs/proc/array.c +@@ -80,6 +80,7 @@ + #include + #include + #include ++#include + #include + + #include +@@ -352,6 +353,7 @@ static int do_task_stat(struct seq_file + char state; + pid_t ppid = 0, pgid = -1, sid = -1; + int num_threads = 0; ++ int permitted; + struct mm_struct *mm; + unsigned long long start_time; + unsigned long cmin_flt = 0, cmaj_flt = 0; +@@ -364,11 +366,14 @@ static int do_task_stat(struct seq_file + + state = *get_task_state(task); + vsize = eip = esp = 0; ++ permitted = ptrace_may_access(task, PTRACE_MODE_READ); + mm = get_task_mm(task); + if (mm) { + vsize = task_vsize(mm); +- eip = KSTK_EIP(task); +- esp = KSTK_ESP(task); ++ if (permitted) { ++ eip = KSTK_EIP(task); ++ esp = KSTK_ESP(task); ++ } + } + + get_task_comm(tcomm, task); +@@ -424,7 +429,7 @@ static int do_task_stat(struct seq_file + unlock_task_sighand(task, &flags); + } + +- if (!whole || num_threads < 2) ++ if (permitted && (!whole || num_threads < 2)) + wchan = get_wchan(task); + if (!whole) { + min_flt = task->min_flt; +@@ -476,7 +481,7 @@ static int do_task_stat(struct seq_file + rsslim, + mm ? mm->start_code : 0, + mm ? mm->end_code : 0, +- mm ? mm->start_stack : 0, ++ (permitted && mm) ? mm->start_stack : 0, + esp, + eip, + /* The signal information here is obsolete. +--- a/fs/proc/base.c ++++ b/fs/proc/base.c +@@ -321,7 +321,10 @@ static int proc_pid_wchan(struct task_st + wchan = get_wchan(task); + + if (lookup_symbol_name(wchan, symname) < 0) +- return sprintf(buffer, "%lu", wchan); ++ if (!ptrace_may_access(task, PTRACE_MODE_READ)) ++ return 0; ++ else ++ return sprintf(buffer, "%lu", wchan); + else + return sprintf(buffer, "%s", symname); + } diff --git a/queue-2.6.29/alsa-us122l-add-snd_us122l_free.patch b/queue-2.6.29/alsa-us122l-add-snd_us122l_free.patch index 769c56e5f40..e37feb072b0 100644 --- a/queue-2.6.29/alsa-us122l-add-snd_us122l_free.patch +++ b/queue-2.6.29/alsa-us122l-add-snd_us122l_free.patch @@ -5,6 +5,8 @@ From: Karsten Wiese To: jejb@kernel.org, stable@kernel.org Subject: ALSA: us122l: add snd_us122l_free() +From: Karsten Wiese + upstream commit: 5d4af1be06affa2b42cdf59cd376752be1f934b3 Use it to clean up snd_us122l_card_used[]. diff --git a/queue-2.6.29/ath5k-fix-buffer-overrun-in-rate-debug-code.patch b/queue-2.6.29/ath5k-fix-buffer-overrun-in-rate-debug-code.patch new file mode 100644 index 00000000000..e1d3664b847 --- /dev/null +++ b/queue-2.6.29/ath5k-fix-buffer-overrun-in-rate-debug-code.patch @@ -0,0 +1,34 @@ +From b7fcb5c4a4c27da2f6d86cb03d18687e537442cf Mon Sep 17 00:00:00 2001 +From: Bob Copeland +Date: Mon, 27 Apr 2009 22:12:43 -0400 +Subject: ath5k: fix buffer overrun in rate debug code + +From: Bob Copeland + +commit b7fcb5c4a4c27da2f6d86cb03d18687e537442cf upstream. + +char bname[5] is too small for the string "X GHz" when the null +terminator is taken into account. Thus, turning on rate debugging +can crash unless we have lucky stack alignment. + +Cc: stable@kernel.org +Reported-by: Paride Legovini +Signed-off-by: Bob Copeland +Signed-off-by: John W. Linville +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/ath5k/debug.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/wireless/ath5k/debug.c ++++ b/drivers/net/wireless/ath5k/debug.c +@@ -465,7 +465,7 @@ ath5k_debug_dump_bands(struct ath5k_soft + + for (b = 0; b < IEEE80211_NUM_BANDS; b++) { + struct ieee80211_supported_band *band = &sc->sbands[b]; +- char bname[5]; ++ char bname[6]; + switch (band->band) { + case IEEE80211_BAND_2GHZ: + strcpy(bname, "2 GHz"); diff --git a/queue-2.6.29/b43-poison-rx-buffers.patch b/queue-2.6.29/b43-poison-rx-buffers.patch index 3f0311d9a42..a3691f011d6 100644 --- a/queue-2.6.29/b43-poison-rx-buffers.patch +++ b/queue-2.6.29/b43-poison-rx-buffers.patch @@ -5,6 +5,8 @@ From: Michael Buesch To: jejb@kernel.org, stable@kernel.org Subject: b43: Poison RX buffers +From: Michael Buesch + upstream commit: ec9a1d8c13e36440eda0f3c79b8149080e3ab5ba This patch adds poisoning and sanity checking to the RX DMA buffers. diff --git a/queue-2.6.29/b43-refresh-rx-poison-on-buffer-recycling.patch b/queue-2.6.29/b43-refresh-rx-poison-on-buffer-recycling.patch index 62f29594a44..e249783e975 100644 --- a/queue-2.6.29/b43-refresh-rx-poison-on-buffer-recycling.patch +++ b/queue-2.6.29/b43-refresh-rx-poison-on-buffer-recycling.patch @@ -5,6 +5,8 @@ From: Michael Buesch To: jejb@kernel.org, stable@kernel.org Subject: b43: Refresh RX poison on buffer recycling +From: Michael Buesch + upstream commit: cf68636a9773aa97915497fe54fa4a51e3f08f3a The RX buffer poison needs to be refreshed, if we recycle an RX buffer, diff --git a/queue-2.6.29/cs5536-define-dma_sff_read_status-method.patch b/queue-2.6.29/cs5536-define-dma_sff_read_status-method.patch new file mode 100644 index 00000000000..2493d93ebd1 --- /dev/null +++ b/queue-2.6.29/cs5536-define-dma_sff_read_status-method.patch @@ -0,0 +1,36 @@ +From sshtylyov@ru.mvista.com Tue May 5 09:23:41 2009 +From: Sergei Shtylyov +Date: Tue, 5 May 2009 15:34:34 +0400 +Subject: cs5536: define dma_sff_read_status() method +To: stable@kernel.org +Message-ID: <200905051534.34672.sshtylyov@ru.mvista.com> + +From: Sergei Shtylyov + +commit 15da90b516e9da92cc1d90001e640fd6707d0e27 upstream. + +The driver somehow got merged with the initializer for the dma_sff_read_status() +method missing which caused kernel panic on bootup. + +This should fix the kernel.org bug #13026... + +Signed-off-by: Sergei Shtylyov +Reported-by: Arnd Hannemann +Signed-off-by: Bartlomiej Zolnierkiewicz +Signed-off-by: Greg Kroah-Hartman + + +--- + drivers/ide/cs5536.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/ide/cs5536.c ++++ b/drivers/ide/cs5536.c +@@ -237,6 +237,7 @@ static const struct ide_dma_ops cs5536_d + .dma_test_irq = ide_dma_test_irq, + .dma_lost_irq = ide_dma_lost_irq, + .dma_timeout = ide_dma_timeout, ++ .dma_sff_read_status = ide_dma_sff_read_status, + }; + + static const struct ide_port_info cs5536_info = { diff --git a/queue-2.6.29/forcedeth-fix-resume-from-hibernation-regression.patch b/queue-2.6.29/forcedeth-fix-resume-from-hibernation-regression.patch index 2432b411aaa..160cf0c69fa 100644 --- a/queue-2.6.29/forcedeth-fix-resume-from-hibernation-regression.patch +++ b/queue-2.6.29/forcedeth-fix-resume-from-hibernation-regression.patch @@ -3,6 +3,8 @@ From: Ed Swierk Date: Mon, 6 Apr 2009 17:49:12 -0700 Subject: forcedeth: Fix resume from hibernation regression. +From: Ed Swierk + upstream commit: 35a7433c789ba6df6d96b70fa745ae9e6cac0038 Reset phy state on resume, fixing a regression caused by powering down diff --git a/queue-2.6.29/intel-iommu-avoid-panic-for-drhd-at-address-zero.patch b/queue-2.6.29/intel-iommu-avoid-panic-for-drhd-at-address-zero.patch new file mode 100644 index 00000000000..d599cc2fa12 --- /dev/null +++ b/queue-2.6.29/intel-iommu-avoid-panic-for-drhd-at-address-zero.patch @@ -0,0 +1,51 @@ +From dwmw2@infradead.org Tue May 5 09:26:07 2009 +From: David Woodhouse +Date: Tue, 05 May 2009 09:25:28 +0100 +Subject: intel-iommu: Avoid panic() for DRHD at address zero. +To: stable@kernel.org +Message-ID: <1241511928.6126.189.camel@macbook.infradead.org> + +From: David Woodhouse + +(cherry picked from commit e523b38e2f568af58baa13120a994cbf24e6dee0) + +If the BIOS does something obviously stupid, like claiming that the +registers for the IOMMU are at physical address zero, then print a nasty +message and abort, rather than trying to set up the IOMMU and then later +panicking. + +It's becoming more and more obvious that trusting this stuff to the BIOS +was a mistake. + +Signed-off-by: David Woodhouse +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/pci/dmar.c | 11 ++++++++++- + 1 file changed, 10 insertions(+), 1 deletion(-) + +--- a/drivers/pci/dmar.c ++++ b/drivers/pci/dmar.c +@@ -170,12 +170,21 @@ dmar_parse_one_drhd(struct acpi_dmar_hea + struct dmar_drhd_unit *dmaru; + int ret = 0; + ++ drhd = (struct acpi_dmar_hardware_unit *)header; ++ if (!drhd->address) { ++ /* Promote an attitude of violence to a BIOS engineer today */ ++ WARN(1, "Your BIOS is broken; DMAR reported at address zero!\n" ++ "BIOS vendor: %s; Ver: %s; Product Version: %s\n", ++ dmi_get_system_info(DMI_BIOS_VENDOR), ++ dmi_get_system_info(DMI_BIOS_VERSION), ++ dmi_get_system_info(DMI_PRODUCT_VERSION)); ++ return -ENODEV; ++ } + dmaru = kzalloc(sizeof(*dmaru), GFP_KERNEL); + if (!dmaru) + return -ENOMEM; + + dmaru->hdr = header; +- drhd = (struct acpi_dmar_hardware_unit *)header; + dmaru->reg_base_addr = drhd->address; + dmaru->include_all = drhd->flags & 0x1; /* BIT0: INCLUDE_ALL */ + diff --git a/queue-2.6.29/intel-iommu-fix-device-to-iommu-mapping-for-pci-pci-bridges.patch b/queue-2.6.29/intel-iommu-fix-device-to-iommu-mapping-for-pci-pci-bridges.patch new file mode 100644 index 00000000000..73fc7aa0562 --- /dev/null +++ b/queue-2.6.29/intel-iommu-fix-device-to-iommu-mapping-for-pci-pci-bridges.patch @@ -0,0 +1,48 @@ +From dwmw2@infradead.org Tue May 5 09:25:25 2009 +From: David Woodhouse +Date: Tue, 05 May 2009 09:25:23 +0100 +Subject: intel-iommu: Fix device-to-iommu mapping for PCI-PCI bridges. +To: stable@kernel.org +Message-ID: <1241511923.6126.187.camel@macbook.infradead.org> + +From: David Woodhouse + +(cherry picked from commit 924b6231edfaf1e764ffb4f97ea382bf4facff58) + +When the DMAR table identifies that a PCI-PCI bridge belongs to a given +IOMMU, that means that the bridge and all devices behind it should be +associated with the IOMMU. Not just the bridge itself. + +This fixes the device_to_iommu() function accordingly. + +(It's broken if you have the same PCI bus numbers in multiple domains, +but this function was always broken in that way; I'll be dealing with +that later). + +Signed-off-by: David Woodhouse +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/pci/intel-iommu.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +--- a/drivers/pci/intel-iommu.c ++++ b/drivers/pci/intel-iommu.c +@@ -447,11 +447,16 @@ static struct intel_iommu *device_to_iom + if (drhd->ignored) + continue; + +- for (i = 0; i < drhd->devices_cnt; i++) ++ for (i = 0; i < drhd->devices_cnt; i++) { + if (drhd->devices[i] && + drhd->devices[i]->bus->number == bus && + drhd->devices[i]->devfn == devfn) + return drhd->iommu; ++ if (drhd->devices[i]->subordinate && ++ drhd->devices[i]->subordinate->number <= bus && ++ drhd->devices[i]->subordinate->subordinate >= bus) ++ return drhd->iommu; ++ } + + if (drhd->include_all) + return drhd->iommu; diff --git a/queue-2.6.29/intel-iommu-fix-oops-in-device_to_iommu-when-devices-not-found.patch b/queue-2.6.29/intel-iommu-fix-oops-in-device_to_iommu-when-devices-not-found.patch new file mode 100644 index 00000000000..9b01db5414a --- /dev/null +++ b/queue-2.6.29/intel-iommu-fix-oops-in-device_to_iommu-when-devices-not-found.patch @@ -0,0 +1,34 @@ +From dwmw2@infradead.org Tue May 5 09:25:45 2009 +From: David Woodhouse +Date: Tue, 05 May 2009 09:25:26 +0100 +Subject: intel-iommu: Fix oops in device_to_iommu() when devices not found. +To: stable@kernel.org +Message-ID: <1241511926.6126.188.camel@macbook.infradead.org> + +From: David Woodhouse + +(cherry picked from commit 4958c5dc7bcb2e42d985cd26aeafd8a7eca9ab1e) + +It's possible for a device in the drhd->devices[] array to be NULL if +it wasn't found at boot time, which means we have to check for that +case. + +Signed-off-by: David Woodhouse +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/pci/intel-iommu.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/pci/intel-iommu.c ++++ b/drivers/pci/intel-iommu.c +@@ -452,7 +452,8 @@ static struct intel_iommu *device_to_iom + drhd->devices[i]->bus->number == bus && + drhd->devices[i]->devfn == devfn) + return drhd->iommu; +- if (drhd->devices[i]->subordinate && ++ if (drhd->devices[i] && ++ drhd->devices[i]->subordinate && + drhd->devices[i]->subordinate->number <= bus && + drhd->devices[i]->subordinate->subordinate >= bus) + return drhd->iommu; diff --git a/queue-2.6.29/kvm-fix-overlapping-check-for-memory-slots.patch b/queue-2.6.29/kvm-fix-overlapping-check-for-memory-slots.patch index 0e821e47fdd..1418a176753 100644 --- a/queue-2.6.29/kvm-fix-overlapping-check-for-memory-slots.patch +++ b/queue-2.6.29/kvm-fix-overlapping-check-for-memory-slots.patch @@ -5,6 +5,8 @@ From: Jan Kiszka To: jejb@kernel.org, stable@kernel.org Subject: KVM: Fix overlapping check for memory slots +From: Jan Kiszka + upstream commit: 4cd481f68dde99ac416003b825c835f71e364393 When checking for overlapping slots on registration of a new one, kvm diff --git a/queue-2.6.29/kvm-mmu-disable-global-page-optimization.patch b/queue-2.6.29/kvm-mmu-disable-global-page-optimization.patch index a8ba5ae396d..45f415b87c2 100644 --- a/queue-2.6.29/kvm-mmu-disable-global-page-optimization.patch +++ b/queue-2.6.29/kvm-mmu-disable-global-page-optimization.patch @@ -5,6 +5,8 @@ To: Chris Wright Subject: KVM: MMU: disable global page optimization Message-ID: <20090424211827.GA13223@amt.cnet> +From: Marcelo Tosatti + upstream commit: bf47a760f66add7870fba33ab50f58b550d6bbd1 Complexity to fix it not worthwhile the gains, as discussed diff --git a/queue-2.6.29/kvm-mmu-fix-off-by-one-calculating-large-page-count.patch b/queue-2.6.29/kvm-mmu-fix-off-by-one-calculating-large-page-count.patch index 56eb04f9da3..338dfd06eb6 100644 --- a/queue-2.6.29/kvm-mmu-fix-off-by-one-calculating-large-page-count.patch +++ b/queue-2.6.29/kvm-mmu-fix-off-by-one-calculating-large-page-count.patch @@ -5,6 +5,8 @@ From: Avi Kivity To: jejb@kernel.org, stable@kernel.org Subject: KVM: MMU: Fix off-by-one calculating large page count +From: Avi Kivity + upstream commit: 99894a799f09cf9e28296bb16e75bd5830fd2c4e The large page initialization code concludes there are two large pages spanned diff --git a/queue-2.6.29/kvm-x86-release-time_page-on-vcpu-destruction.patch b/queue-2.6.29/kvm-x86-release-time_page-on-vcpu-destruction.patch index 4ea4d52e2f7..fc29825b9de 100644 --- a/queue-2.6.29/kvm-x86-release-time_page-on-vcpu-destruction.patch +++ b/queue-2.6.29/kvm-x86-release-time_page-on-vcpu-destruction.patch @@ -5,6 +5,8 @@ From: Joerg Roedel To: jejb@kernel.org, stable@kernel.org Subject: KVM: x86: release time_page on vcpu destruction +From: Joerg Roedel + upstream commit: 7f1ea208968f021943d4103ba59e06bb6d8239cb Not releasing the time_page causes a leak of that page or the compound diff --git a/queue-2.6.29/mac80211-fix-basic-rate-bitmap-calculation.patch b/queue-2.6.29/mac80211-fix-basic-rate-bitmap-calculation.patch index 4247eaa127c..71c2c74c235 100644 --- a/queue-2.6.29/mac80211-fix-basic-rate-bitmap-calculation.patch +++ b/queue-2.6.29/mac80211-fix-basic-rate-bitmap-calculation.patch @@ -5,6 +5,8 @@ From: Johannes Berg To: jejb@kernel.org, stable@kernel.org Subject: mac80211: fix basic rate bitmap calculation +From: Johannes Berg + upstream commit: 7e0986c17f695952ce5d61ed793ce048ba90a661 "mac80211: fix basic rates setting from association response" @@ -15,7 +17,6 @@ to the driver but is remotely exploitable for some hardware or driver combinations. Signed-off-by: Johannes Berg -Cc: stable@kernel.org [2.6.29] Signed-off-by: John W. Linville Signed-off-by: Chris Wright --- diff --git a/queue-2.6.29/mac80211-fix-bug-in-getting-rx-status-for-frames-pending-in-reorder-buffer.patch b/queue-2.6.29/mac80211-fix-bug-in-getting-rx-status-for-frames-pending-in-reorder-buffer.patch index 618644e4f00..a6bfae429c1 100644 --- a/queue-2.6.29/mac80211-fix-bug-in-getting-rx-status-for-frames-pending-in-reorder-buffer.patch +++ b/queue-2.6.29/mac80211-fix-bug-in-getting-rx-status-for-frames-pending-in-reorder-buffer.patch @@ -5,6 +5,8 @@ From: Vasanthakumar Thiagarajan To: jejb@kernel.org, stable@kernel.org Subject: mac80211: Fix bug in getting rx status for frames pending in reorder buffer +From: Vasanthakumar Thiagarajan + upstream commit: b3631286aca3f54427ca0eb950981e9753866f6c Currently rx status for frames which are completed from reorder buffer diff --git a/queue-2.6.29/mv643xx_eth-64bit-mib-counter-read-fix.patch b/queue-2.6.29/mv643xx_eth-64bit-mib-counter-read-fix.patch new file mode 100644 index 00000000000..d39fce35f71 --- /dev/null +++ b/queue-2.6.29/mv643xx_eth-64bit-mib-counter-read-fix.patch @@ -0,0 +1,48 @@ +From 93af7aca44f0e82e67bda10a0fb73d383edcc8bd Mon Sep 17 00:00:00 2001 +From: Lennert Buytenhek +Date: Wed, 29 Apr 2009 11:58:18 +0000 +Subject: mv643xx_eth: 64bit mib counter read fix + +From: Lennert Buytenhek + +commit 93af7aca44f0e82e67bda10a0fb73d383edcc8bd upstream. + +On several mv643xx_eth hardware versions, the two 64bit mib counters +for 'good octets received' and 'good octets sent' are actually 32bit +counters, and reading from the upper half of the register has the same +effect as reading from the lower half of the register: an atomic +read-and-clear of the entire 32bit counter value. This can under heavy +traffic occasionally lead to small numbers being added to the upper +half of the 64bit mib counter even though no 32bit wrap has occured. + +Since we poll the mib counters at least every 30 seconds anyway, we +might as well just skip the reads of the upper halves of the hardware +counters without breaking the stats, which this patch does. + +Signed-off-by: Lennert Buytenhek +Cc: stable@kernel.org +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/mv643xx_eth.c | 2 -- + 1 file changed, 2 deletions(-) + +--- a/drivers/net/mv643xx_eth.c ++++ b/drivers/net/mv643xx_eth.c +@@ -1177,7 +1177,6 @@ static void mib_counters_update(struct m + + spin_lock_bh(&mp->mib_counters_lock); + p->good_octets_received += mib_read(mp, 0x00); +- p->good_octets_received += (u64)mib_read(mp, 0x04) << 32; + p->bad_octets_received += mib_read(mp, 0x08); + p->internal_mac_transmit_err += mib_read(mp, 0x0c); + p->good_frames_received += mib_read(mp, 0x10); +@@ -1191,7 +1190,6 @@ static void mib_counters_update(struct m + p->frames_512_to_1023_octets += mib_read(mp, 0x30); + p->frames_1024_to_max_octets += mib_read(mp, 0x34); + p->good_octets_sent += mib_read(mp, 0x38); +- p->good_octets_sent += (u64)mib_read(mp, 0x3c) << 32; + p->good_frames_sent += mib_read(mp, 0x40); + p->excessive_collision += mib_read(mp, 0x44); + p->multicast_frames_sent += mib_read(mp, 0x48); diff --git a/queue-2.6.29/mv643xx_eth-oom-handling-fixes.patch b/queue-2.6.29/mv643xx_eth-oom-handling-fixes.patch new file mode 100644 index 00000000000..c6b45401cb8 --- /dev/null +++ b/queue-2.6.29/mv643xx_eth-oom-handling-fixes.patch @@ -0,0 +1,114 @@ +From 1319ebadf185933e6b7ff95211d3cef9004e9754 Mon Sep 17 00:00:00 2001 +From: Lennert Buytenhek +Date: Wed, 29 Apr 2009 11:57:34 +0000 +Subject: mv643xx_eth: OOM handling fixes + +From: Lennert Buytenhek + +commit 1319ebadf185933e6b7ff95211d3cef9004e9754 upstream. + +Currently, when OOM occurs during rx ring refill, mv643xx_eth will get +into an infinite loop, due to the refill function setting the OOM bit +but not clearing the 'rx refill needed' bit for this queue, while the +calling function (the NAPI poll handler) will call the refill function +in a loop until the 'rx refill needed' bit goes off, without checking +the OOM bit. + +This patch fixes this by checking the OOM bit in the NAPI poll handler +before attempting to do rx refill. This means that once OOM occurs, +we won't try to do any memory allocations again until the next invocation +of the poll handler. + +While we're at it, change the OOM flag to be a single bit instead of +one bit per receive queue since OOM is a system state rather than a +per-queue state, and cancel the OOM timer on entry to the NAPI poll +handler if it's running to prevent it from firing when we've already +come out of OOM. + +Signed-off-by: Lennert Buytenhek +Cc: stable@kernel.org +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/mv643xx_eth.c | 22 +++++++++++++--------- + 1 file changed, 13 insertions(+), 9 deletions(-) + +--- a/drivers/net/mv643xx_eth.c ++++ b/drivers/net/mv643xx_eth.c +@@ -372,12 +372,12 @@ struct mv643xx_eth_private { + struct work_struct tx_timeout_task; + + struct napi_struct napi; ++ u8 oom; + u8 work_link; + u8 work_tx; + u8 work_tx_end; + u8 work_rx; + u8 work_rx_refill; +- u8 work_rx_oom; + + int skb_size; + struct sk_buff_head rx_recycle; +@@ -603,7 +603,7 @@ static int rxq_refill(struct rx_queue *r + dma_get_cache_alignment() - 1); + + if (skb == NULL) { +- mp->work_rx_oom |= 1 << rxq->index; ++ mp->oom = 1; + goto oom; + } + +@@ -1906,8 +1906,10 @@ static int mv643xx_eth_poll(struct napi_ + + mp = container_of(napi, struct mv643xx_eth_private, napi); + +- mp->work_rx_refill |= mp->work_rx_oom; +- mp->work_rx_oom = 0; ++ if (unlikely(mp->oom)) { ++ mp->oom = 0; ++ del_timer(&mp->rx_oom); ++ } + + work_done = 0; + while (work_done < budget) { +@@ -1921,8 +1923,10 @@ static int mv643xx_eth_poll(struct napi_ + continue; + } + +- queue_mask = mp->work_tx | mp->work_tx_end | +- mp->work_rx | mp->work_rx_refill; ++ queue_mask = mp->work_tx | mp->work_tx_end | mp->work_rx; ++ if (likely(!mp->oom)) ++ queue_mask |= mp->work_rx_refill; ++ + if (!queue_mask) { + if (mv643xx_eth_collect_events(mp)) + continue; +@@ -1943,7 +1947,7 @@ static int mv643xx_eth_poll(struct napi_ + txq_maybe_wake(mp->txq + queue); + } else if (mp->work_rx & queue_mask) { + work_done += rxq_process(mp->rxq + queue, work_tbd); +- } else if (mp->work_rx_refill & queue_mask) { ++ } else if (!mp->oom && (mp->work_rx_refill & queue_mask)) { + work_done += rxq_refill(mp->rxq + queue, work_tbd); + } else { + BUG(); +@@ -1951,7 +1955,7 @@ static int mv643xx_eth_poll(struct napi_ + } + + if (work_done < budget) { +- if (mp->work_rx_oom) ++ if (mp->oom) + mod_timer(&mp->rx_oom, jiffies + (HZ / 10)); + napi_complete(napi); + wrlp(mp, INT_MASK, INT_TX_END | INT_RX | INT_EXT); +@@ -2143,7 +2147,7 @@ static int mv643xx_eth_open(struct net_d + rxq_refill(mp->rxq + i, INT_MAX); + } + +- if (mp->work_rx_oom) { ++ if (mp->oom) { + mp->rx_oom.expires = jiffies + (HZ / 10); + add_timer(&mp->rx_oom); + } diff --git a/queue-2.6.29/proc-avoid-information-leaks-to-non-privileged-processes.patch b/queue-2.6.29/proc-avoid-information-leaks-to-non-privileged-processes.patch new file mode 100644 index 00000000000..b0484f0399e --- /dev/null +++ b/queue-2.6.29/proc-avoid-information-leaks-to-non-privileged-processes.patch @@ -0,0 +1,100 @@ +From f83ce3e6b02d5e48b3a43b001390e2b58820389d Mon Sep 17 00:00:00 2001 +From: Jake Edge +Date: Mon, 4 May 2009 12:51:14 -0600 +Subject: proc: avoid information leaks to non-privileged processes + +From: Jake Edge + +commit f83ce3e6b02d5e48b3a43b001390e2b58820389d upstream. + +By using the same test as is used for /proc/pid/maps and /proc/pid/smaps, +only allow processes that can ptrace() a given process to see information +that might be used to bypass address space layout randomization (ASLR). +These include eip, esp, wchan, and start_stack in /proc/pid/stat as well +as the non-symbolic output from /proc/pid/wchan. + +ASLR can be bypassed by sampling eip as shown by the proof-of-concept +code at http://code.google.com/p/fuzzyaslr/ As part of a presentation +(http://www.cr0.org/paper/to-jt-linux-alsr-leak.pdf) esp and wchan were +also noted as possibly usable information leaks as well. The +start_stack address also leaks potentially useful information. + +Cc: Stable Team +Signed-off-by: Jake Edge +Acked-by: Arjan van de Ven +Acked-by: "Eric W. Biederman" +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + fs/proc/array.c | 13 +++++++++---- + fs/proc/base.c | 5 ++++- + 2 files changed, 13 insertions(+), 5 deletions(-) + +--- a/fs/proc/array.c ++++ b/fs/proc/array.c +@@ -80,6 +80,7 @@ + #include + #include + #include ++#include + #include + + #include +@@ -352,6 +353,7 @@ static int do_task_stat(struct seq_file + char state; + pid_t ppid = 0, pgid = -1, sid = -1; + int num_threads = 0; ++ int permitted; + struct mm_struct *mm; + unsigned long long start_time; + unsigned long cmin_flt = 0, cmaj_flt = 0; +@@ -364,11 +366,14 @@ static int do_task_stat(struct seq_file + + state = *get_task_state(task); + vsize = eip = esp = 0; ++ permitted = ptrace_may_access(task, PTRACE_MODE_READ); + mm = get_task_mm(task); + if (mm) { + vsize = task_vsize(mm); +- eip = KSTK_EIP(task); +- esp = KSTK_ESP(task); ++ if (permitted) { ++ eip = KSTK_EIP(task); ++ esp = KSTK_ESP(task); ++ } + } + + get_task_comm(tcomm, task); +@@ -424,7 +429,7 @@ static int do_task_stat(struct seq_file + unlock_task_sighand(task, &flags); + } + +- if (!whole || num_threads < 2) ++ if (permitted && (!whole || num_threads < 2)) + wchan = get_wchan(task); + if (!whole) { + min_flt = task->min_flt; +@@ -476,7 +481,7 @@ static int do_task_stat(struct seq_file + rsslim, + mm ? mm->start_code : 0, + mm ? mm->end_code : 0, +- mm ? mm->start_stack : 0, ++ (permitted && mm) ? mm->start_stack : 0, + esp, + eip, + /* The signal information here is obsolete. +--- a/fs/proc/base.c ++++ b/fs/proc/base.c +@@ -321,7 +321,10 @@ static int proc_pid_wchan(struct task_st + wchan = get_wchan(task); + + if (lookup_symbol_name(wchan, symname) < 0) +- return sprintf(buffer, "%lu", wchan); ++ if (!ptrace_may_access(task, PTRACE_MODE_READ)) ++ return 0; ++ else ++ return sprintf(buffer, "%lu", wchan); + else + return sprintf(buffer, "%s", symname); + } diff --git a/queue-2.6.29/series b/queue-2.6.29/series index e8fcd40754a..0932fafef6c 100644 --- a/queue-2.6.29/series +++ b/queue-2.6.29/series @@ -42,3 +42,11 @@ new-locking-refcounting-for-fs_struct.patch check_unsafe_exec-doesn-t-care-about-signal-handlers-sharing.patch do_execve-must-not-clear-fs-in_exec-if-it-was-set-by-another-thread.patch check_unsafe_exec-s-lock_task_sighand-rcu_read_lock.patch +mv643xx_eth-64bit-mib-counter-read-fix.patch +mv643xx_eth-oom-handling-fixes.patch +ath5k-fix-buffer-overrun-in-rate-debug-code.patch +proc-avoid-information-leaks-to-non-privileged-processes.patch +cs5536-define-dma_sff_read_status-method.patch +intel-iommu-fix-device-to-iommu-mapping-for-pci-pci-bridges.patch +intel-iommu-fix-oops-in-device_to_iommu-when-devices-not-found.patch +intel-iommu-avoid-panic-for-drhd-at-address-zero.patch diff --git a/queue-2.6.29/thinkpad-acpi-fix-led-blinking-through-timer-trigger.patch b/queue-2.6.29/thinkpad-acpi-fix-led-blinking-through-timer-trigger.patch index 0be6b2b2168..c748aeaca15 100644 --- a/queue-2.6.29/thinkpad-acpi-fix-led-blinking-through-timer-trigger.patch +++ b/queue-2.6.29/thinkpad-acpi-fix-led-blinking-through-timer-trigger.patch @@ -5,6 +5,8 @@ From: Henrique de Moraes Holschuh To: jejb@kernel.org, stable@kernel.org Subject: thinkpad-acpi: fix LED blinking through timer trigger +From: Henrique de Moraes Holschuh + upstream commit: 75bd3bf2ade9d548be0d2bde60b5ee0fdce0b127 The set_blink hook code in the LED subdriver would never manage to get diff --git a/queue-2.6.29/usb-unusual-device-support-for-gold-mp3-player-energy.patch b/queue-2.6.29/usb-unusual-device-support-for-gold-mp3-player-energy.patch index 25e34e3b090..87b22b3b14d 100644 --- a/queue-2.6.29/usb-unusual-device-support-for-gold-mp3-player-energy.patch +++ b/queue-2.6.29/usb-unusual-device-support-for-gold-mp3-player-energy.patch @@ -5,6 +5,8 @@ From: Chuck Short To: jejb@kernel.org, stable@kernel.org Subject: USB: Unusual Device support for Gold MP3 Player Energy +From: Chuck Short + upstream commit: 46c6e93faa85d1362e1d127dc28cf9d0b304a6f1 Reported by Alessio Treglia on diff --git a/queue-2.6.29/virtio-rng-remove-false-bug-for-spurious-callbacks.patch b/queue-2.6.29/virtio-rng-remove-false-bug-for-spurious-callbacks.patch index df4b931c1bc..b41eb867368 100644 --- a/queue-2.6.29/virtio-rng-remove-false-bug-for-spurious-callbacks.patch +++ b/queue-2.6.29/virtio-rng-remove-false-bug-for-spurious-callbacks.patch @@ -5,6 +5,8 @@ From: Christian Borntraeger To: jejb@kernel.org, stable@kernel.org Subject: virtio-rng: Remove false BUG for spurious callbacks +From: Christian Borntraeger + upstream commit: e5b89542ea18020961882228c26db3ba87f6e608 The virtio-rng drivers checks for spurious callbacks. Since