linux-kernel - Re: [crash] NULL pointer dereference at IP: [<ffffffff812e9ccb>] uart

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20091012112504.GA10002@elte.hu>
Date:	Mon, 12 Oct 2009 13:25:04 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Greg KH <gregkh@...e.de>, Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [crash] NULL pointer dereference at IP: [<ffffffff812e9ccb>]
	uart_close+0x2a/0x1e4

* Ingo Molnar <mingo@...e.hu> wrote:

> i also have a crash with vanilla -rc4, test on this commit:
> 
>   d93a8f8: Revert "USB: Work around BIOS bugs by quiescing USB controllers earlier"
> 
> crashlog pasted below - config attached.

i did a full .31 -> .32-rc4 bisection and came up with this result:

|  46d57a449aa13d9c6adcc9d1dbc7b9a0ecfb69d8 is first bad commit
|  commit 46d57a449aa13d9c6adcc9d1dbc7b9a0ecfb69d8
|  Author: Alan Cox <alan@...ux.intel.com>
|  Date:   Sat Sep 19 13:13:29 2009 -0700
|
|     serial: use tty_port pointers in the core code

this is the second time i have bisected back to this commit, see also 
this prior thread on lkml:

 Subject: [origin tree boot crash] Re: [GIT PATCH] TTY patches for 2.6.31-git

i chalked that first crash/hang up to potential cosmic entropy 
(especially since it happened even with all serial logging disabled, and 
because i was unable to get any log of the spontaneous reboot), but this 
second crash occurs on a completely different system and has an 
analyzable crash signature as well.

Both systems are rock-solid with no known hardware weirdness, the first 
test-system passed two hundred thousand boot tests in the past 1.5 
years, and the second one has performed tens of thousands of build+boot 
tests as well. I'd exclude hardware failure as a likely candidate for 
now.

Unfortunately 46d57a449aa13d9c6adcc9d1dbc7b9a0ecfb69d8 is not easy to 
revert, at all. Would be glad to try any patch - fixes or some manual 
revert as well (if that's feasible).

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/