--- /dev/null
+From 8112006f41fd76ddf4988f8ddd904563db85613c Mon Sep 17 00:00:00 2001
+From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
+Date: Sun, 16 Jun 2013 00:38:30 +0200
+Subject: ACPI / dock: Take ACPI scan lock in write_undock()
+
+From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
+
+commit 8112006f41fd76ddf4988f8ddd904563db85613c upstream.
+
+Since commit 3757b94 (ACPI / hotplug: Fix concurrency issues and
+memory leaks) acpi_bus_scan() and acpi_bus_trim() must always be
+called under acpi_scan_lock, but currently the following scenario
+violating that requirement is possible:
+
+ write_undock()
+ handle_eject_request()
+ hotplug_dock_devices()
+ dock_remove_acpi_device()
+ acpi_bus_trim()
+
+Fix that by making write_undock() acquire acpi_scan_lock before
+calling handle_eject_request() as appropriate (begin_undock() is
+under the lock too in analogy with acpi_dock_deferred_cb()).
+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Acked-by: Toshi Kani <toshi.kani@hp.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/acpi/dock.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/acpi/dock.c
++++ b/drivers/acpi/dock.c
+@@ -868,8 +868,10 @@ static ssize_t write_undock(struct devic
+ if (!count)
+ return -EINVAL;
+
++ acpi_scan_lock_acquire();
+ begin_undock(dock_station);
+ ret = handle_eject_request(dock_station, ACPI_NOTIFY_EJECT_REQUEST);
++ acpi_scan_lock_release();
+ return ret ? ret: count;
+ }
+ static DEVICE_ATTR(undock, S_IWUSR, NULL, write_undock);
--- /dev/null
+From 6ee22e9d59151550a55d370b14109bdae8b58bda Mon Sep 17 00:00:00 2001
+From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
+Date: Wed, 19 Jun 2013 00:44:45 +0200
+Subject: ACPI / PM: Fix error code path for power resources initialization
+
+From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
+
+commit 6ee22e9d59151550a55d370b14109bdae8b58bda upstream.
+
+Commit 781d737 (ACPI: Drop power resources driver) introduced a
+bug in the power resources initialization error code path causing
+a NULL pointer to be referenced in acpi_release_power_resource()
+if there's an error triggering a jump to the 'err' label in
+acpi_add_power_resource(). This happens because the list_node
+field of struct acpi_power_resource has not been initialized yet
+at this point and doing a list_del() on it is a bad idea.
+
+To prevent this problem from occuring, initialize the list_node
+field of struct acpi_power_resource upfront.
+
+Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Tested-by: Lan Tianyu <tianyu.lan@intel.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
+Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/acpi/power.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/acpi/power.c
++++ b/drivers/acpi/power.c
+@@ -865,6 +865,7 @@ int acpi_add_power_resource(acpi_handle
+ ACPI_STA_DEFAULT);
+ mutex_init(&resource->resource_lock);
+ INIT_LIST_HEAD(&resource->dependent);
++ INIT_LIST_HEAD(&resource->list_node);
+ resource->name = device->pnp.bus_id;
+ strcpy(acpi_device_name(device), ACPI_POWER_DEVICE_NAME);
+ strcpy(acpi_device_class(device), ACPI_POWER_CLASS);
--- /dev/null
+From 204ebc0aa30a7115f300cac39fbb7eeb66524881 Mon Sep 17 00:00:00 2001
+From: Mika Westerberg <mika.westerberg@linux.intel.com>
+Date: Mon, 20 May 2013 15:41:45 +0000
+Subject: ACPI / resources: call acpi_get_override_irq() only for legacy IRQ resources
+
+From: Mika Westerberg <mika.westerberg@linux.intel.com>
+
+commit 204ebc0aa30a7115f300cac39fbb7eeb66524881 upstream.
+
+acpi_get_override_irq() was added because there was a problem with
+buggy BIOSes passing wrong IRQ() resource for the RTC IRQ. The
+commit that added the workaround was 61fd47e0c8476 (ACPI: fix two
+IRQ8 issues in IOAPIC mode).
+
+With ACPI 5 enumerated devices there are typically one or more
+extended IRQ resources per device (and these IRQs can be shared).
+However, the acpi_get_override_irq() workaround forces all IRQs in
+range 0 - 15 (the legacy ISA IRQs) to be edge triggered, active high
+as can be seen from the dmesg below:
+
+ ACPI: IRQ 6 override to edge, high
+ ACPI: IRQ 7 override to edge, high
+ ACPI: IRQ 7 override to edge, high
+ ACPI: IRQ 13 override to edge, high
+
+Also /proc/interrupts for the I2C controllers (INT33C2 and INT33C3) shows
+the same thing:
+
+ 7: 4 0 0 0 IO-APIC-edge INT33C2:00, INT33C3:00
+
+The _CSR method for INT33C2 (and INT33C3) device returns following
+resource:
+
+ Interrupt (ResourceConsumer, Level, ActiveLow, Shared,,, )
+ {
+ 0x00000007,
+ }
+
+which states that this is supposed to be level triggered, active low,
+shared IRQ instead.
+
+Fix this by making sure that acpi_get_override_irq() gets only called
+when we are dealing with legacy IRQ() or IRQNoFlags() descriptors.
+
+While we are there, correct pr_warning() to print the right triggering
+value.
+
+This change turns out to be necessary to make DMA work correctly on
+systems based on the Intel Lynxpoint PCH (Platform Controller Hub).
+
+[rjw: Changelog]
+Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/acpi/resource.c | 16 +++++++++++-----
+ 1 file changed, 11 insertions(+), 5 deletions(-)
+
+--- a/drivers/acpi/resource.c
++++ b/drivers/acpi/resource.c
+@@ -304,7 +304,8 @@ static void acpi_dev_irqresource_disable
+ }
+
+ static void acpi_dev_get_irqresource(struct resource *res, u32 gsi,
+- u8 triggering, u8 polarity, u8 shareable)
++ u8 triggering, u8 polarity, u8 shareable,
++ bool legacy)
+ {
+ int irq, p, t;
+
+@@ -317,14 +318,19 @@ static void acpi_dev_get_irqresource(str
+ * In IO-APIC mode, use overrided attribute. Two reasons:
+ * 1. BIOS bug in DSDT
+ * 2. BIOS uses IO-APIC mode Interrupt Source Override
++ *
++ * We do this only if we are dealing with IRQ() or IRQNoFlags()
++ * resource (the legacy ISA resources). With modern ACPI 5 devices
++ * using extended IRQ descriptors we take the IRQ configuration
++ * from _CRS directly.
+ */
+- if (!acpi_get_override_irq(gsi, &t, &p)) {
++ if (legacy && !acpi_get_override_irq(gsi, &t, &p)) {
+ u8 trig = t ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE;
+ u8 pol = p ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
+
+ if (triggering != trig || polarity != pol) {
+ pr_warning("ACPI: IRQ %d override to %s, %s\n", gsi,
+- t ? "edge" : "level", p ? "low" : "high");
++ t ? "level" : "edge", p ? "low" : "high");
+ triggering = trig;
+ polarity = pol;
+ }
+@@ -373,7 +379,7 @@ bool acpi_dev_resource_interrupt(struct
+ }
+ acpi_dev_get_irqresource(res, irq->interrupts[index],
+ irq->triggering, irq->polarity,
+- irq->sharable);
++ irq->sharable, true);
+ break;
+ case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
+ ext_irq = &ares->data.extended_irq;
+@@ -383,7 +389,7 @@ bool acpi_dev_resource_interrupt(struct
+ }
+ acpi_dev_get_irqresource(res, ext_irq->interrupts[index],
+ ext_irq->triggering, ext_irq->polarity,
+- ext_irq->sharable);
++ ext_irq->sharable, false);
+ break;
+ default:
+ return false;
--- /dev/null
+From 764bcbc5a6d7a2f3e75c9f0e4caa984e2926e346 Mon Sep 17 00:00:00 2001
+From: "Zhanghaoyu (A)" <haoyu.zhang@huawei.com>
+Date: Fri, 14 Jun 2013 07:36:13 +0000
+Subject: KVM: x86: remove vcpu's CPL check in host-invoked XCR set
+
+From: "Zhanghaoyu (A)" <haoyu.zhang@huawei.com>
+
+commit 764bcbc5a6d7a2f3e75c9f0e4caa984e2926e346 upstream.
+
+__kvm_set_xcr function does the CPL check when set xcr. __kvm_set_xcr is
+called in two flows, one is invoked by guest, call stack shown as below,
+
+ handle_xsetbv(or xsetbv_interception)
+ kvm_set_xcr
+ __kvm_set_xcr
+
+the other one is invoked by host, for example during system reset:
+
+ kvm_arch_vcpu_ioctl
+ kvm_vcpu_ioctl_x86_set_xcrs
+ __kvm_set_xcr
+
+The former does need the CPL check, but the latter does not.
+
+Signed-off-by: Zhang Haoyu <haoyu.zhang@huawei.com>
+[Tweaks to commit message. - Paolo]
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kvm/x86.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/arch/x86/kvm/x86.c
++++ b/arch/x86/kvm/x86.c
+@@ -558,8 +558,6 @@ int __kvm_set_xcr(struct kvm_vcpu *vcpu,
+ if (index != XCR_XFEATURE_ENABLED_MASK)
+ return 1;
+ xcr0 = xcr;
+- if (kvm_x86_ops->get_cpl(vcpu) != 0)
+- return 1;
+ if (!(xcr0 & XSTATE_FP))
+ return 1;
+ if ((xcr0 & XSTATE_YMM) && !(xcr0 & XSTATE_SSE))
+@@ -573,7 +571,8 @@ int __kvm_set_xcr(struct kvm_vcpu *vcpu,
+
+ int kvm_set_xcr(struct kvm_vcpu *vcpu, u32 index, u64 xcr)
+ {
+- if (__kvm_set_xcr(vcpu, index, xcr)) {
++ if (kvm_x86_ops->get_cpl(vcpu) != 0 ||
++ __kvm_set_xcr(vcpu, index, xcr)) {
+ kvm_inject_gp(vcpu, 0);
+ return 1;
+ }
parisc-fix-serial-ports-on-c8000-workstation.patch
parisc-provide-pci_mmap_page_range-for-parisc.patch
carl9170-fix-frame-drop-and-warn-due-to-minstrel_ht-change.patch
+x86-efi-fix-dummy-variable-buffer-allocation.patch
+x86-kvmclock-zero-initialize-pvclock-shared-memory-area.patch
+kvm-x86-remove-vcpu-s-cpl-check-in-host-invoked-xcr-set.patch
+acpi-resources-call-acpi_get_override_irq-only-for-legacy-irq-resources.patch
+acpi-dock-take-acpi-scan-lock-in-write_undock.patch
+acpi-pm-fix-error-code-path-for-power-resources.patch
--- /dev/null
+From b8cb62f82103083a6e8fa5470bfe634a2c06514d Mon Sep 17 00:00:00 2001
+From: Ben Hutchings <ben@decadent.org.uk>
+Date: Sun, 16 Jun 2013 21:27:12 +0100
+Subject: x86/efi: Fix dummy variable buffer allocation
+
+From: Ben Hutchings <ben@decadent.org.uk>
+
+commit b8cb62f82103083a6e8fa5470bfe634a2c06514d upstream.
+
+1. Check for allocation failure
+2. Clear the buffer contents, as they may actually be written to flash
+3. Don't leak the buffer
+
+Compile-tested only.
+
+[ Tested successfully on my buggy ASUS machine - Matt ]
+
+Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
+Signed-off-by: Matt Fleming <matt.fleming@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/platform/efi/efi.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/platform/efi/efi.c
++++ b/arch/x86/platform/efi/efi.c
+@@ -1059,7 +1059,10 @@ efi_status_t efi_query_variable_store(u3
+ * that by attempting to use more space than is available.
+ */
+ unsigned long dummy_size = remaining_size + 1024;
+- void *dummy = kmalloc(dummy_size, GFP_ATOMIC);
++ void *dummy = kzalloc(dummy_size, GFP_ATOMIC);
++
++ if (!dummy)
++ return EFI_OUT_OF_RESOURCES;
+
+ status = efi.set_variable(efi_dummy_name, &EFI_DUMMY_GUID,
+ EFI_VARIABLE_NON_VOLATILE |
+@@ -1079,6 +1082,8 @@ efi_status_t efi_query_variable_store(u3
+ 0, dummy);
+ }
+
++ kfree(dummy);
++
+ /*
+ * The runtime code may now have triggered a garbage collection
+ * run, so check the variable info again
--- /dev/null
+From 07868fc6aaf57847b0f3a3d53086b7556eb83f4a Mon Sep 17 00:00:00 2001
+From: Igor Mammedov <imammedo@redhat.com>
+Date: Mon, 10 Jun 2013 18:31:11 +0200
+Subject: x86: kvmclock: zero initialize pvclock shared memory area
+
+From: Igor Mammedov <imammedo@redhat.com>
+
+commit 07868fc6aaf57847b0f3a3d53086b7556eb83f4a upstream.
+
+kernel might hung in pvclock_clocksource_read() due to
+uninitialized memory might contain odd version value in
+following cycle:
+
+ do {
+ version = __pvclock_read_cycles(src, &ret, &flags);
+ } while ((src->version & 1) || version != src->version);
+
+if secondary kvmclock is accessed before it's registered with kvm.
+
+Clear garbage in pvclock shared memory area right after it's
+allocated to avoid this issue.
+
+Ref: https://bugzilla.kernel.org/show_bug.cgi?id=59521
+Signed-off-by: Igor Mammedov <imammedo@redhat.com>
+[See BZ for analysis. We may want a different fix for 3.11, but
+ this is the safest for now - Paolo]
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/kvmclock.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/x86/kernel/kvmclock.c
++++ b/arch/x86/kernel/kvmclock.c
+@@ -238,6 +238,7 @@ void __init kvmclock_init(void)
+ if (!mem)
+ return;
+ hv_clock = __va(mem);
++ memset(hv_clock, 0, size);
+
+ if (kvm_register_clock("boot clock")) {
+ hv_clock = NULL;
projects / thirdparty / kernel / stable-queue.git / commitdiff
