--- /dev/null
+From b7fcb5c4a4c27da2f6d86cb03d18687e537442cf Mon Sep 17 00:00:00 2001
+From: Bob Copeland <me@bobcopeland.com>
+Date: Mon, 27 Apr 2009 22:12:43 -0400
+Subject: ath5k: fix buffer overrun in rate debug code
+
+From: Bob Copeland <me@bobcopeland.com>
+
+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 <legovini@spiro.fisica.unipd.it>
+Signed-off-by: Bob Copeland <me@bobcopeland.com>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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");
--- /dev/null
+From sshtylyov@ru.mvista.com Tue May 5 09:23:41 2009
+From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
+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 <sshtylyov@ru.mvista.com>
+
+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 <sshtylyov@ru.mvista.com>
+Reported-by: Arnd Hannemann <hannemann@nets.rwth-aachen.de>
+Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+
+---
+ 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 = {
--- /dev/null
+From dwmw2@infradead.org Tue May 5 09:26:07 2009
+From: David Woodhouse <dwmw2@infradead.org>
+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 <dwmw2@infradead.org>
+
+(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 <David.Woodhouse@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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 */
+
--- /dev/null
+From dwmw2@infradead.org Tue May 5 09:25:25 2009
+From: David Woodhouse <dwmw2@infradead.org>
+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 <dwmw2@infradead.org>
+
+(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 <David.Woodhouse@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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;
--- /dev/null
+From dwmw2@infradead.org Tue May 5 09:25:45 2009
+From: David Woodhouse <dwmw2@infradead.org>
+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 <dwmw2@infradead.org>
+
+(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 <David.Woodhouse@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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;
--- /dev/null
+From 93af7aca44f0e82e67bda10a0fb73d383edcc8bd Mon Sep 17 00:00:00 2001
+From: Lennert Buytenhek <buytenh@wantstofly.org>
+Date: Wed, 29 Apr 2009 11:58:18 +0000
+Subject: mv643xx_eth: 64bit mib counter read fix
+
+From: Lennert Buytenhek <buytenh@wantstofly.org>
+
+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 <buytenh@marvell.com>
+Cc: stable@kernel.org
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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);
--- /dev/null
+From 1319ebadf185933e6b7ff95211d3cef9004e9754 Mon Sep 17 00:00:00 2001
+From: Lennert Buytenhek <buytenh@wantstofly.org>
+Date: Wed, 29 Apr 2009 11:57:34 +0000
+Subject: mv643xx_eth: OOM handling fixes
+
+From: Lennert Buytenhek <buytenh@wantstofly.org>
+
+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 <buytenh@marvell.com>
+Cc: stable@kernel.org
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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);
+ }
--- /dev/null
+From f83ce3e6b02d5e48b3a43b001390e2b58820389d Mon Sep 17 00:00:00 2001
+From: Jake Edge <jake@lwn.net>
+Date: Mon, 4 May 2009 12:51:14 -0600
+Subject: proc: avoid information leaks to non-privileged processes
+
+From: Jake Edge <jake@lwn.net>
+
+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 <stable@kernel.org>
+Signed-off-by: Jake Edge <jake@lwn.net>
+Acked-by: Arjan van de Ven <arjan@linux.intel.com>
+Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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 <linux/delayacct.h>
+ #include <linux/seq_file.h>
+ #include <linux/pid_namespace.h>
++#include <linux/ptrace.h>
+ #include <linux/tracehook.h>
+
+ #include <asm/pgtable.h>
+@@ -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);
+ }
To: jejb@kernel.org, stable@kernel.org
Subject: ALSA: us122l: add snd_us122l_free()
+From: Karsten Wiese <fzu@wemgehoertderstaat.de>
+
upstream commit: 5d4af1be06affa2b42cdf59cd376752be1f934b3
Use it to clean up snd_us122l_card_used[].
--- /dev/null
+From b7fcb5c4a4c27da2f6d86cb03d18687e537442cf Mon Sep 17 00:00:00 2001
+From: Bob Copeland <me@bobcopeland.com>
+Date: Mon, 27 Apr 2009 22:12:43 -0400
+Subject: ath5k: fix buffer overrun in rate debug code
+
+From: Bob Copeland <me@bobcopeland.com>
+
+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 <legovini@spiro.fisica.unipd.it>
+Signed-off-by: Bob Copeland <me@bobcopeland.com>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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");
To: jejb@kernel.org, stable@kernel.org
Subject: b43: Poison RX buffers
+From: Michael Buesch <mb@bu3sch.de>
+
upstream commit: ec9a1d8c13e36440eda0f3c79b8149080e3ab5ba
This patch adds poisoning and sanity checking to the RX DMA buffers.
To: jejb@kernel.org, stable@kernel.org
Subject: b43: Refresh RX poison on buffer recycling
+From: Michael Buesch <mb@bu3sch.de>
+
upstream commit: cf68636a9773aa97915497fe54fa4a51e3f08f3a
The RX buffer poison needs to be refreshed, if we recycle an RX buffer,
--- /dev/null
+From sshtylyov@ru.mvista.com Tue May 5 09:23:41 2009
+From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
+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 <sshtylyov@ru.mvista.com>
+
+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 <sshtylyov@ru.mvista.com>
+Reported-by: Arnd Hannemann <hannemann@nets.rwth-aachen.de>
+Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+
+---
+ 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 = {
Date: Mon, 6 Apr 2009 17:49:12 -0700
Subject: forcedeth: Fix resume from hibernation regression.
+From: Ed Swierk <eswierk@aristanetworks.com>
+
upstream commit: 35a7433c789ba6df6d96b70fa745ae9e6cac0038
Reset phy state on resume, fixing a regression caused by powering down
--- /dev/null
+From dwmw2@infradead.org Tue May 5 09:26:07 2009
+From: David Woodhouse <dwmw2@infradead.org>
+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 <dwmw2@infradead.org>
+
+(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 <David.Woodhouse@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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 */
+
--- /dev/null
+From dwmw2@infradead.org Tue May 5 09:25:25 2009
+From: David Woodhouse <dwmw2@infradead.org>
+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 <dwmw2@infradead.org>
+
+(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 <David.Woodhouse@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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;
--- /dev/null
+From dwmw2@infradead.org Tue May 5 09:25:45 2009
+From: David Woodhouse <dwmw2@infradead.org>
+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 <dwmw2@infradead.org>
+
+(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 <David.Woodhouse@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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;
To: jejb@kernel.org, stable@kernel.org
Subject: KVM: Fix overlapping check for memory slots
+From: Jan Kiszka <jan.kiszka@web.de>
+
upstream commit: 4cd481f68dde99ac416003b825c835f71e364393
When checking for overlapping slots on registration of a new one, kvm
Subject: KVM: MMU: disable global page optimization
Message-ID: <20090424211827.GA13223@amt.cnet>
+From: Marcelo Tosatti <mtosatti@redhat.com>
+
upstream commit: bf47a760f66add7870fba33ab50f58b550d6bbd1
Complexity to fix it not worthwhile the gains, as discussed
To: jejb@kernel.org, stable@kernel.org
Subject: KVM: MMU: Fix off-by-one calculating large page count
+From: Avi Kivity <avi@redhat.com>
+
upstream commit: 99894a799f09cf9e28296bb16e75bd5830fd2c4e
The large page initialization code concludes there are two large pages spanned
To: jejb@kernel.org, stable@kernel.org
Subject: KVM: x86: release time_page on vcpu destruction
+From: Joerg Roedel <joerg.roedel@amd.com>
+
upstream commit: 7f1ea208968f021943d4103ba59e06bb6d8239cb
Not releasing the time_page causes a leak of that page or the compound
To: jejb@kernel.org, stable@kernel.org
Subject: mac80211: fix basic rate bitmap calculation
+From: Johannes Berg <johannes@sipsolutions.net>
+
upstream commit: 7e0986c17f695952ce5d61ed793ce048ba90a661
"mac80211: fix basic rates setting from association response"
driver combinations.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
-Cc: stable@kernel.org [2.6.29]
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
To: jejb@kernel.org, stable@kernel.org
Subject: mac80211: Fix bug in getting rx status for frames pending in reorder buffer
+From: Vasanthakumar Thiagarajan <vasanth@atheros.com>
+
upstream commit: b3631286aca3f54427ca0eb950981e9753866f6c
Currently rx status for frames which are completed from reorder buffer
--- /dev/null
+From 93af7aca44f0e82e67bda10a0fb73d383edcc8bd Mon Sep 17 00:00:00 2001
+From: Lennert Buytenhek <buytenh@wantstofly.org>
+Date: Wed, 29 Apr 2009 11:58:18 +0000
+Subject: mv643xx_eth: 64bit mib counter read fix
+
+From: Lennert Buytenhek <buytenh@wantstofly.org>
+
+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 <buytenh@marvell.com>
+Cc: stable@kernel.org
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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);
--- /dev/null
+From 1319ebadf185933e6b7ff95211d3cef9004e9754 Mon Sep 17 00:00:00 2001
+From: Lennert Buytenhek <buytenh@wantstofly.org>
+Date: Wed, 29 Apr 2009 11:57:34 +0000
+Subject: mv643xx_eth: OOM handling fixes
+
+From: Lennert Buytenhek <buytenh@wantstofly.org>
+
+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 <buytenh@marvell.com>
+Cc: stable@kernel.org
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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);
+ }
--- /dev/null
+From f83ce3e6b02d5e48b3a43b001390e2b58820389d Mon Sep 17 00:00:00 2001
+From: Jake Edge <jake@lwn.net>
+Date: Mon, 4 May 2009 12:51:14 -0600
+Subject: proc: avoid information leaks to non-privileged processes
+
+From: Jake Edge <jake@lwn.net>
+
+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 <stable@kernel.org>
+Signed-off-by: Jake Edge <jake@lwn.net>
+Acked-by: Arjan van de Ven <arjan@linux.intel.com>
+Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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 <linux/delayacct.h>
+ #include <linux/seq_file.h>
+ #include <linux/pid_namespace.h>
++#include <linux/ptrace.h>
+ #include <linux/tracehook.h>
+
+ #include <asm/pgtable.h>
+@@ -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);
+ }
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
To: jejb@kernel.org, stable@kernel.org
Subject: thinkpad-acpi: fix LED blinking through timer trigger
+From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
+
upstream commit: 75bd3bf2ade9d548be0d2bde60b5ee0fdce0b127
The set_blink hook code in the LED subdriver would never manage to get
To: jejb@kernel.org, stable@kernel.org
Subject: USB: Unusual Device support for Gold MP3 Player Energy
+From: Chuck Short <zulcss@ubuntu.com>
+
upstream commit: 46c6e93faa85d1362e1d127dc28cf9d0b304a6f1
Reported by Alessio Treglia on
To: jejb@kernel.org, stable@kernel.org
Subject: virtio-rng: Remove false BUG for spurious callbacks
+From: Christian Borntraeger <borntraeger@de.ibm.com>
+
upstream commit: e5b89542ea18020961882228c26db3ba87f6e608
The virtio-rng drivers checks for spurious callbacks. Since
projects / thirdparty / kernel / stable-queue.git / commitdiff
