Bug#665493: bug fixed in 3.6; patch

2012-10-08 Thread Ben Hutchings
On Sun, 2012-10-07 at 10:29 +0200, Jeroen Nijhof wrote:
 tags 665493 patch
 quit
 
 As noted in the upstream bugzilla, the bug is fixed in kernel 3.6,
 in commit dfb117b3e50c52c7b3416db4a4569224b8db80bb ,
 PCI: acpiphp: check whether _ADR evaluation succeeded.
 
 Attached as a patch below. Applying this on top of 3.2.30 fixes the
 problem indeed (and without the patch that still fails).
 Would it be possible to apply this to the Debian kernel?

This is under review for inclusion in 3.2.31.

Ben.

-- 
Ben Hutchings
Who are all these weirdos? - David Bowie, about L-Space IRC channel #afp


signature.asc
Description: This is a digitally signed message part


Bug#665493: bug fixed in 3.6; patch

2012-10-08 Thread Stefan Nagy
I can confirm that the bug is fixed in kernel 3.6 and that applying the
patch provided by Jeroen in Message #71 (PCI: acpiphp: check whether
_ADR evaluation succeeded) on top of 3.2.30 solves the problem.

Thanks!
Stefan.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#665493: bug fixed in 3.6; patch

2012-10-07 Thread Jeroen Nijhof
tags 665493 patch
quit

As noted in the upstream bugzilla, the bug is fixed in kernel 3.6,
in commit dfb117b3e50c52c7b3416db4a4569224b8db80bb ,
PCI: acpiphp: check whether _ADR evaluation succeeded.

Attached as a patch below. Applying this on top of 3.2.30 fixes the
problem indeed (and without the patch that still fails).
Would it be possible to apply this to the Debian kernel?

Thanks,

Jeroen Nijhof

From dfb117b3e50c52c7b3416db4a4569224b8db80bb Mon Sep 17 00:00:00 2001
From: Bjorn Helgaas bhelg...@google.com
Date: Wed, 20 Jun 2012 16:18:29 -0600
Subject: [PATCH] PCI: acpiphp: check whether _ADR evaluation succeeded

Check whether we evaluated _ADR successfully.  Previously we ignored
failure, so we would have used garbage data from the stack as the device
and function number.

We return AE_OK so that we ignore only this slot and continue looking
for other slots.

Found by Coverity (CID 113981).

Signed-off-by: Bjorn Helgaas bhelg...@google.com
---
 drivers/pci/hotplug/acpiphp_glue.c |   13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/hotplug/acpiphp_glue.c b/drivers/pci/hotplug/acpiphp_glue.c
index 806c44f..09bf377 100644
--- a/drivers/pci/hotplug/acpiphp_glue.c
+++ b/drivers/pci/hotplug/acpiphp_glue.c
@@ -132,6 +132,15 @@ register_slot(acpi_handle handle, u32 lvl, void *context, void **rv)
 	if (!acpi_pci_check_ejectable(pbus, handle)  !is_dock_device(handle))
 		return AE_OK;
 
+	status = acpi_evaluate_integer(handle, _ADR, NULL, adr);
+	if (ACPI_FAILURE(status)) {
+		warn(can't evaluate _ADR (%#x)\n, status);
+		return AE_OK;
+	}
+
+	device = (adr  16)  0x;
+	function = adr  0x;
+
 	pdev = pbus-self;
 	if (pdev  pci_is_pcie(pdev)) {
 		tmp = acpi_find_root_bridge_handle(pdev);
@@ -144,10 +153,6 @@ register_slot(acpi_handle handle, u32 lvl, void *context, void **rv)
 		}
 	}
 
-	acpi_evaluate_integer(handle, _ADR, NULL, adr);
-	device = (adr  16)  0x;
-	function = adr  0x;
-
 	newfunc = kzalloc(sizeof(struct acpiphp_func), GFP_KERNEL);
 	if (!newfunc)
 		return AE_NO_MEMORY;
-- 
1.7.10.4