+++ /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);
- }
projects / thirdparty / kernel / stable-queue.git / commitdiff
