linux-kernel - Re: i915 X lockup

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: <1235841119.4162.5.camel@aiko.keithp.com>
Date:	Sat, 28 Feb 2009 09:11:58 -0800
From:	Keith Packard <keith.packard@...el.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Keith Packard <keith.packard@...el.com>,
	Jiri Slaby <jirislaby@...il.com>,
	Eric Anholt <eric@...olt.net>,
	Sitsofe Wheeler <sitsofe@...oo.com>, airlied@...ux.ie,
	dri-devel@...ts.sourceforge.net,
	Linux kernel mailing list <linux-kernel@...r.kernel.org>
Subject: Re: i915 X lockup

On Sat, 2009-02-28 at 00:47 -0800, Andrew Morton wrote:

> The kernel deadlocked on struct_mutex, did it not?  That's a kernel bug
> regardless of what userspace you're running.

No, it didn't deadlock on struct_mutex, it deadlocked because the
hardware got wedged, and we still don't know how to unwedge the hardware
and get it working again other than turning it off and back on again.

> Do we know why this happened?

Yes, the hardware will happily lock up when user space maps the PCI BAR
covering the device registers and the application pokes various internal
device registers directly.

That's the fundamental contract KMS requires -- if the kernel is going
to manage the device, then user space isn't supposed to manipulate it
directly anymore.

I suspect most any other device in the machine could be made to do 'bad
things' if userspace went and poked it directly.

-- 
keith.packard@...el.com

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)