From patchwork Tue Oct 23 10:17:54 2012
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: [Bug,49151] NULL pointer dereference in pata_acpi
Date: Tue, 23 Oct 2012 00:17:54 -0000
From: bugzilla-daemon@bugzilla.kernel.org
X-Patchwork-Id: 193419
Message-Id: <20121023101754.91A7111FB3D@bugzilla.kernel.org>
To: linux-ide@vger.kernel.org

https://bugzilla.kernel.org/show_bug.cgi?id=49151





--- Comment #14 from Borislav Petkov <bp@alien8.de>  2012-10-23 10:17:54 ---
On Tue, Oct 23, 2012 at 11:05:49AM +0100, Alan Cox wrote:
> > So yes, blacklisting it and verifying that your system still operates
> > normally would be something to do. If it does, you could also build a
> > kernel with pata_acpi disabled (that is, provided you build your own
> > kernels).
> 
> The crash is still a bug. It needs chasing down.

Yes, ata_timing_find_mode gives NULL, we found that out.

Anton, Phillip, anyone willing to run this hunk below and get us the
output:

---
acpi->gtm.flags |= (1 << (2 * unit));
--

Thanks.

diff --git a/drivers/ata/pata_acpi.c b/drivers/ata/pata_acpi.c
index 09723b76beac..80d594d6e7c8 100644
--- a/drivers/ata/pata_acpi.c
+++ b/drivers/ata/pata_acpi.c
@@ -144,6 +144,13 @@ static void pacpi_set_dmamode(struct ata_port *ap, struct
ata_device *adev)

     /* Now stuff the nS values into the structure */
     t = ata_timing_find_mode(adev->dma_mode);
+    if (!t) {
+        pr_err("%s: ata_timing_find_mode gives NULL; adev->dma_mode: 0x%x\n",
+               __func__, adev->dma_mode);
+
+        return;
+    }
+
     if (adev->dma_mode >= XFER_UDMA_0) {
         acpi->gtm.drive[unit].dma = t->udma;