Linux 3.3.4

This commit is contained in:
Justin M. Forbes 2012-04-30 11:17:03 -05:00
parent 9583a84612
commit 5b71df1e00
6 changed files with 6 additions and 268 deletions

View File

@ -1,92 +0,0 @@
commit 32f6daad4651a748a58a3ab6da0611862175722f
Author: Alex Williamson <alex.williamson@redhat.com>
Date: Wed Apr 11 09:51:49 2012 -0600
KVM: unmap pages from the iommu when slots are removed
We've been adding new mappings, but not destroying old mappings.
This can lead to a page leak as pages are pinned using
get_user_pages, but only unpinned with put_page if they still
exist in the memslots list on vm shutdown. A memslot that is
destroyed while an iommu domain is enabled for the guest will
therefore result in an elevated page reference count that is
never cleared.
Additionally, without this fix, the iommu is only programmed
with the first translation for a gpa. This can result in
peer-to-peer errors if a mapping is destroyed and replaced by a
new mapping at the same gpa as the iommu will still be pointing
to the original, pinned memory address.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 665a260..72cbf08 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -596,6 +596,7 @@ void kvm_free_irq_source_id(struct kvm *kvm, int irq_source_id);
#ifdef CONFIG_IOMMU_API
int kvm_iommu_map_pages(struct kvm *kvm, struct kvm_memory_slot *slot);
+void kvm_iommu_unmap_pages(struct kvm *kvm, struct kvm_memory_slot *slot);
int kvm_iommu_map_guest(struct kvm *kvm);
int kvm_iommu_unmap_guest(struct kvm *kvm);
int kvm_assign_device(struct kvm *kvm,
@@ -609,6 +610,11 @@ static inline int kvm_iommu_map_pages(struct kvm *kvm,
return 0;
}
+static inline void kvm_iommu_unmap_pages(struct kvm *kvm,
+ struct kvm_memory_slot *slot)
+{
+}
+
static inline int kvm_iommu_map_guest(struct kvm *kvm)
{
return -ENODEV;
diff --git a/virt/kvm/iommu.c b/virt/kvm/iommu.c
index a457d21..fec1723 100644
--- a/virt/kvm/iommu.c
+++ b/virt/kvm/iommu.c
@@ -310,6 +310,11 @@ static void kvm_iommu_put_pages(struct kvm *kvm,
}
}
+void kvm_iommu_unmap_pages(struct kvm *kvm, struct kvm_memory_slot *slot)
+{
+ kvm_iommu_put_pages(kvm, slot->base_gfn, slot->npages);
+}
+
static int kvm_iommu_unmap_memslots(struct kvm *kvm)
{
int idx;
@@ -320,7 +325,7 @@ static int kvm_iommu_unmap_memslots(struct kvm *kvm)
slots = kvm_memslots(kvm);
kvm_for_each_memslot(memslot, slots)
- kvm_iommu_put_pages(kvm, memslot->base_gfn, memslot->npages);
+ kvm_iommu_unmap_pages(kvm, memslot);
srcu_read_unlock(&kvm->srcu, idx);
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 42b7393..9739b53 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -808,12 +808,13 @@ int __kvm_set_memory_region(struct kvm *kvm,
if (r)
goto out_free;
- /* map the pages in iommu page table */
+ /* map/unmap the pages in iommu page table */
if (npages) {
r = kvm_iommu_map_pages(kvm, &new);
if (r)
goto out_free;
- }
+ } else
+ kvm_iommu_unmap_pages(kvm, &old);
r = -ENOMEM;
slots = kmemdup(kvm->memslots, sizeof(struct kvm_memslots),

View File

@ -42,7 +42,7 @@ Summary: The Linux kernel
# When changing real_sublevel below, reset this by hand to 1
# (or to 0 and then use rpmdev-bumpspec).
#
%global baserelease 2
%global baserelease 1
%global fedora_build %{baserelease}
# real_sublevel is the 3.x kernel version we're starting with
@ -51,7 +51,7 @@ Summary: The Linux kernel
%define fake_sublevel %(echo $((40 + %{real_sublevel})))
# Do we have a -stable update to apply?
%define stable_update 3
%define stable_update 4
# Is it a -stable RC?
%define stable_rc 0
# Set rpm version accordingly
@ -688,9 +688,6 @@ Patch21306: shlib_base_randomize.patch
#rhbz 770476
Patch21371: iwlwifi-do-not-nulify-ctx-vif-on-reset.patch
#rhbz 808603
Patch21380: wimax-i2400m-prevent-a-possible-kernel-bug-due-to-mi.patch
#rhbz 807632
Patch21385: libata-forbid-port-runtime-pm-by-default.patch
@ -708,22 +705,14 @@ Patch21710: disable-hid-battery.patch
Patch22000: weird-root-dentry-name-debug.patch
#rhbz 814149 814155 CVE-2012-2121
Patch22006: KVM-unmap-pages-from-the-iommu-when-slots-are-removed.patch
#rhbz 814278 814289 CVE-2012-2119
Patch22007: macvtap-zerocopy-validate-vector-length.patch
#rhbz 811225
Patch22010: memblock-memblock-should-be-able-to-handle-zero-leng.patch
Patch22011: input-synaptics-fix-regression-with-image-sensor-trackpads.patch
#rhbz 783708
Patch22012: ipw2200-Fix-race-condition-in-the-command-completion-acknowledge.patch
Patch22013: perf-fix-build-breakage.patch
# END OF PATCH DEFINITIONS
%endif
@ -1312,9 +1301,6 @@ ApplyPatch KVM-Ensure-all-vcpus-are-consistent-with-in-kernel-i.patch
#rhbz 770476
ApplyPatch iwlwifi-do-not-nulify-ctx-vif-on-reset.patch
#rhbz 808603
ApplyPatch wimax-i2400m-prevent-a-possible-kernel-bug-due-to-mi.patch
#rhbz 807632
ApplyPatch libata-forbid-port-runtime-pm-by-default.patch
@ -1325,22 +1311,14 @@ ApplyPatch x86-microcode-Ensure-that-module-is-only-loaded-for-supported-AMD-CPU
#rhbz 806295
ApplyPatch disable-hid-battery.patch
#rhbz 814149 814155 CVE-2012-2121
ApplyPatch KVM-unmap-pages-from-the-iommu-when-slots-are-removed.patch
#rhbz 814278 814289 CVE-2012-2119
ApplyPatch macvtap-zerocopy-validate-vector-length.patch
#rhbz 811225
ApplyPatch memblock-memblock-should-be-able-to-handle-zero-leng.patch
ApplyPatch input-synaptics-fix-regression-with-image-sensor-trackpads.patch
#rhbz 783708
ApplyPatch ipw2200-Fix-race-condition-in-the-command-completion-acknowledge.patch
ApplyPatch perf-fix-build-breakage.patch
# END OF PATCH APPLICATIONS
%endif
@ -1993,6 +1971,9 @@ fi
# and build.
%changelog
* Mon Apr 30 2012 Justin M. Forbes <jforbes@redhat.com> 2.6.43.4-1
- Linux 3.3.4
* Tue Apr 24 2012 Josh Boyer <jwboyer@redhat.com>
- Add patch to fix perf build due to incorrect cherry-pick in 3.3.3
- Add patch to fix ipw2200 (rhbz 783708)

View File

@ -1,63 +0,0 @@
From b3dc627cabb33fc95f93da78457770c1b2a364d2 Mon Sep 17 00:00:00 2001
From: Tejun Heo <tj@kernel.org>
Date: Fri, 20 Apr 2012 08:31:34 -0700
Subject: [PATCH] memblock: memblock should be able to handle zero length
operations
Commit 24aa07882b ("memblock, x86: Replace memblock_x86_reserve/
free_range() with generic ones") replaced x86 specific memblock
operations with the generic ones; unfortunately, it lost zero length
operation handling in the process making the kernel panic if somebody
tries to reserve zero length area.
There isn't much to be gained by being cranky to zero length operations
and panicking is almost the worst response. Drop the BUG_ON() in
memblock_reserve() and update memblock_add_region/isolate_range() so
that all zero length operations are handled as noops.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org
Reported-by: Valere Monseur <valere.monseur@ymail.com>
Bisected-by: Joseph Freeman <jfree143dev@gmail.com>
Tested-by: Joseph Freeman <jfree143dev@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43098
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
mm/memblock.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/mm/memblock.c b/mm/memblock.c
index 99f2855..a44eab3 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -330,6 +330,9 @@ static int __init_memblock memblock_add_region(struct memblock_type *type,
phys_addr_t end = base + memblock_cap_size(base, &size);
int i, nr_new;
+ if (!size)
+ return 0;
+
/* special case for empty array */
if (type->regions[0].size == 0) {
WARN_ON(type->cnt != 1 || type->total_size);
@@ -430,6 +433,9 @@ static int __init_memblock memblock_isolate_range(struct memblock_type *type,
*start_rgn = *end_rgn = 0;
+ if (!size)
+ return 0;
+
/* we'll create at most two more regions */
while (type->cnt + 2 > type->max)
if (memblock_double_array(type) < 0)
@@ -514,7 +520,6 @@ int __init_memblock memblock_reserve(phys_addr_t base, phys_addr_t size)
(unsigned long long)base,
(unsigned long long)base + size,
(void *)_RET_IP_);
- BUG_ON(0 == size);
return memblock_add_region(_rgn, base, size, MAX_NUMNODES);
}
--
1.7.7.6

View File

@ -1,54 +0,0 @@
From zeev.tarantov@gmail.com Sun Apr 22 23:38:36 2012
From: Zeev Tarantov <zeev.tarantov@gmail.com>
Date: Mon, 23 Apr 2012 09:37:04 +0300
Subject: Perf: fix build breakage
To: "David S. Miller" <davem@davemloft.net>, Arnaldo Carvalho de Melo <acme@redhat.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Message-ID: <20120423063704.GA3465@myhost>
Content-Disposition: inline
From: Zeev Tarantov <zeev.tarantov@gmail.com>
[Patch not needed upstream as this is a backport build bugfix - gregkh
gcc correctly complains:
util/hist.c: In function __hists__add_entry:
util/hist.c:240:27: error: invalid type argument of -> (have struct hist_entry)
util/hist.c:241:23: error: invalid type argument of -> (have struct hist_entry)
for this new code:
+ if (he->ms.map != entry->ms.map) {
+ he->ms.map = entry->ms.map;
+ if (he->ms.map)
+ he->ms.map->referenced = true;
+ }
because "entry" is a "struct hist_entry", not a pointer to a struct.
In mainline, "entry" is a pointer to struct passed as argument to the function.
So this is broken during backporting. But obviously not compile tested.
Signed-off-by: Zeev Tarantov <zeev.tarantov@gmail.com>
Cc: Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
tools/perf/util/hist.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -237,8 +237,8 @@ struct hist_entry *__hists__add_entry(st
* mis-adjust symbol addresses when computing
* the history counter to increment.
*/
- if (he->ms.map != entry->ms.map) {
- he->ms.map = entry->ms.map;
+ if (he->ms.map != entry.ms.map) {
+ he->ms.map = entry.ms.map;
if (he->ms.map)
he->ms.map->referenced = true;
}

View File

@ -1,2 +1,2 @@
7133f5a2086a7d7ef97abac610c094f5 linux-3.3.tar.xz
634a088d3789870885dc6ee1eb9627d4 patch-3.3.3.xz
9c4cc16f10b645fbb90f6c05ad388883 patch-3.3.4.xz

View File

@ -1,34 +0,0 @@
From 4eee6a3a04e8bb53fbe7de0f64d0524d3fbe3f80 Mon Sep 17 00:00:00 2001
From: Phil Sutter <phil.sutter@viprinet.com>
Date: Mon, 26 Mar 2012 09:01:30 +0000
Subject: [PATCH] wimax: i2400m - prevent a possible kernel bug due to missing
fw_name string
This happened on a machine with a custom hotplug script calling nameif,
probably due to slow firmware loading. At the time nameif uses ethtool
to gather interface information, i2400m->fw_name is zero and so a null
pointer dereference occurs from within i2400m_get_drvinfo().
Signed-off-by: Phil Sutter <phil.sutter@viprinet.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/net/wimax/i2400m/netdev.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wimax/i2400m/netdev.c b/drivers/net/wimax/i2400m/netdev.c
index 63e4b70..1d76ae8 100644
--- a/drivers/net/wimax/i2400m/netdev.c
+++ b/drivers/net/wimax/i2400m/netdev.c
@@ -597,7 +597,8 @@ static void i2400m_get_drvinfo(struct net_device *net_dev,
struct i2400m *i2400m = net_dev_to_i2400m(net_dev);
strncpy(info->driver, KBUILD_MODNAME, sizeof(info->driver) - 1);
- strncpy(info->fw_version, i2400m->fw_name, sizeof(info->fw_version) - 1);
+ strncpy(info->fw_version,
+ i2400m->fw_name ? : "", sizeof(info->fw_version) - 1);
if (net_dev->dev.parent)
strncpy(info->bus_info, dev_name(net_dev->dev.parent),
sizeof(info->bus_info) - 1);
--
1.7.7.6