From patchwork Sat Oct 20 12:00:48 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Borislav Petkov X-Patchwork-Id: 192914 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id B47762C0386 for ; Sat, 20 Oct 2012 23:00:57 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755252Ab2JTMAw (ORCPT ); Sat, 20 Oct 2012 08:00:52 -0400 Received: from mail.skyhub.de ([78.46.96.112]:47259 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755244Ab2JTMAv (ORCPT ); Sat, 20 Oct 2012 08:00:51 -0400 X-Virus-Scanned: Nedap ESD1 at mail.skyhub.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8; t=1350734449; bh=S6NR4cGd+xHGP/RXYp1DgRC+EMsUuq93PNwLR41eVWg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Transfer-Encoding:In-Reply-To; b=VzcDwGyYlRjd ruzwk+B8hfLw8244MrTHpi/Y1kxN9bFcldLPtvhLX1+zhP8cPFVT09Fbp6leNEWgqRD t1vZ2Mlyv1Lzz0s+2EcCZBR+lioM6W9NOKqSnqQMSo4ElS9V8+xWBPaUDXoua4B9VWN OSkSJOPaNl42x3NWAQYrNDtwE= Received: from mail.skyhub.de ([127.0.0.1]) by localhost (door.skyhub.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YeIotY6CCKtG; Sat, 20 Oct 2012 14:00:49 +0200 (CEST) Received: from liondog.tnic (p5B32D366.dip.t-dialin.net [91.50.211.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id B72261D95E8; Sat, 20 Oct 2012 14:00:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8; t=1350734449; bh=S6NR4cGd+xHGP/RXYp1DgRC+EMsUuq93PNwLR41eVWg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Transfer-Encoding:In-Reply-To; b=VzcDwGyYlRjd ruzwk+B8hfLw8244MrTHpi/Y1kxN9bFcldLPtvhLX1+zhP8cPFVT09Fbp6leNEWgqRD t1vZ2Mlyv1Lzz0s+2EcCZBR+lioM6W9NOKqSnqQMSo4ElS9V8+xWBPaUDXoua4B9VWN OSkSJOPaNl42x3NWAQYrNDtwE= Received: by liondog.tnic (Postfix, from userid 1000) id 258F84B8ED9; Sat, 20 Oct 2012 14:00:48 +0200 (CEST) Date: Sat, 20 Oct 2012 14:00:48 +0200 From: Borislav Petkov To: "Anton V. Boyarshinov" , phillip.wood@dunelm.org.uk Cc: bugzilla-daemon@bugzilla.kernel.org, linux-ide@vger.kernel.org, Jeff Garzik , Alan Cox Subject: Re: [Bug 49151] New: NULL pointer dereference in pata_acpi Message-ID: <20121020120047.GC17563@liondog.tnic> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-ide-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ide@vger.kernel.org On Sat, Oct 20, 2012 at 10:19:22AM +0000, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=49151 > > Summary: NULL pointer dereference in pata_acpi > Product: IO/Storage > Version: 2.5 > Kernel Version: 3.6.2 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: IDE > AssignedTo: io_ide@kernel-bugs.osdl.org > ReportedBy: phillip.wood@dunelm.org.uk > Regression: No > > > Just upgraded from 3.2.20 to 3.6.2 and when I try to boot a get > > BUG unable to handle kernel NULL pointer dereference at 00000010 > IP [] pacpi_set_dmamode+0x50/0xa0 [pata_acpi] > > and it wont find my hard disc. I'm using the standard arch linux kernel config > available at > https://projects.archlinux.org/svntogit/packages.git/tree/trunk/config?h=packages/linux > > I've attached a couple of photos of the message and backtrace Ok, let's first switch to mail. FWIW, there's another report of this http://marc.info/?l=linux-ide&m=134995465614435&w=2 and it is on 64-bit while Phillip's is 32-bit. Adding Anton and a couple more people to CC. From Anton's disassembly I get: Ä 2.703078Ü Code: 01 00 00 00 f6 43 10 10 74 0a 41 89 c7 43 8d 0c 3f 41 d3 e6 41 0f b6 bd e1 02 00 00 e8 ce 74 0f 00 41 80 bd e1 02 00 00 3f 77 44 <0f> b7 40 10 41 f7 d6 44 21 73 10 4d 63 ff 42 89 44 fb 04 48 89 All code --- Thanks. ======== 0: 01 00 add %eax,(%rax) 2: 00 00 add %al,(%rax) 4: f6 43 10 10 testb $0x10,0x10(%rbx) 8: 74 0a je 0x14 a: 41 89 c7 mov %eax,%r15d d: 43 8d 0c 3f lea (%r15,%r15,1),%ecx 11: 41 d3 e6 shl %cl,%r14d 14: 41 0f b6 bd e1 02 00 movzbl 0x2e1(%r13),%edi 1b: 00 1c: e8 ce 74 0f 00 callq 0xf74ef 21: 41 80 bd e1 02 00 00 cmpb $0x3f,0x2e1(%r13) 28: 3f 29: 77 44 ja 0x6f 2b:* 0f b7 40 10 movzwl 0x10(%rax),%eax <-- trapping instruction 2f: 41 f7 d6 not %r14d 32: 44 21 73 10 and %r14d,0x10(%rbx) 36: 4d 63 ff movslq %r15d,%r15 39: 42 89 44 fb 04 mov %eax,0x4(%rbx,%r15,8) 3e: 48 rex.W 3f: 89 .byte 0x89 And although I cannot generate the exact code here, building drivers/ata/pata_acpi.c locally gives only one instruction like the trapping one (thankfully, function is short enough): sall %cl, %eax # tmp92, tmp93 orl %eax, 16(%rbx) # tmp93, acpi_6->gtm.flags jmp .L30 # .LVL46: .L29: .loc 1 151 0 movzwl 16(%rax), %eax # t_12->cycle, t_12->cycle <--- .LVL47: .loc 1 152 0 leal (%r12,%r12), %ecx #, tmp97 which could mean that ata_timing_find_mode() might be returning NULL on those systems (t is in %(r|e)ax in both oopses and the 0x10 offset points to ata_timing->cycle). So, Anton, Phillip, can you guys try the following debugging patch to confirm (it is against mainline but should apply cleanly ontop of 3.6-stable): --- diff --git a/drivers/ata/pata_acpi.c b/drivers/ata/pata_acpi.c index 09723b76beac..c5a54faecb98 100644 --- a/drivers/ata/pata_acpi.c +++ b/drivers/ata/pata_acpi.c @@ -144,6 +144,12 @@ 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) { + WARN(1, "%s: ata_timing_find_mode gives NULL\n", __func__); + return; + } + if (adev->dma_mode >= XFER_UDMA_0) { acpi->gtm.drive[unit].dma = t->udma; acpi->gtm.flags |= (1 << (2 * unit));