linux-kernel - Re: [BUG][2.6.38] IRQ Lock Inversion / i915 fails

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: <4D829A48.7020408@t-online.de>
Date:	Fri, 18 Mar 2011 00:33:28 +0100
From:	Knut Petersen <Knut_Petersen@...nline.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.de>,
	Chris Wilson <chris@...is-wilson.co.uk>,
	jesse.barnes@...el.com, gregkh@...e.de,
	linux-kernel@...r.kernel.org,
	David Müller <d.mueller@...oft.ch>
Subject: Re: [BUG][2.6.38] IRQ Lock Inversion / i915 fails

Am 17.03.2011 17:55, schrieb Linus Torvalds:
>
> Ok, so the lock inversion seems to be due to the sound/drivers/aloop.c
> file, where the function "loopback_pos_update()" gets called from
> within a softirq context. And it takes a lock (cable->lock) that is
> also taken unprotected by loopback_trigger(). So that's liable to
> deadlock as per lockdep. Jaroslav? Takashi?
Takashi Iwai already gave a solution for the irq inversion problem.

> The X problem seems to be something unrelated. You have those "GPU
> hung" messages, along with i2c/EDID problems. But the actual oops is
> at the very beginning of intel_release_load_detect_pipe(), here:
>
>    0:	55                   	push   %ebp
>    1:	89 e5                	mov    %esp,%ebp
>    3:	57                   	push   %edi
>    4:	89 cf                	mov    %ecx,%edi
>    6:	56                   	push   %esi
>    7:	53                   	push   %ebx
>    8:	89 c3                	mov    %eax,%ebx
>    a:	83 ec 0c             	sub    $0xc,%esp
>    d:	8b 00                	mov    (%eax),%eax
>    f:	8b 73 20             	mov    0x20(%ebx),%esi
>   12:	80 7b 30 00          	cmpb   $0x0,0x30(%ebx)
>   16:	8b 4b 28             	mov    0x28(%ebx),%ecx
>   19:	89 45 f0             	mov    %eax,-0x10(%ebp)
>   1c:*	8b 86 e0 01 00 00    	mov    0x1e0(%esi),%eax     <-- trapping
> instruction
>   22:	89 45 ec             	mov    %eax,-0x14(%ebp)
>   25:	74 2d                	je     0x54
>   27:	c7 43 20 00 00 00 00 	movl   $0x0,0x20(%ebx)
>   2e:	89 f0                	mov    %esi,%eax
>
> where %esi is NULL. I think that is the "crtc->helper_private" load,
> and crtc is NULL.
>
> That code does look broken. The very same function explicitly sets
> crtc to NULL, so clearly it _can_ be NULL. That said, this is all old
> code. I suspect the thing that made it start trigger may be commit
> f5afcd3dd0dc ("drm/i915/crt: Check for a analog monitor in case of
> DVI-I"), which is the only real change to the crt_detect logic I can
> see.
>
Well, I think there are two i915 problems that are independent.

The i2c/edid thing might be related to the f5a...commit, but reverting
that commit alone does not help. i2c/edid error messages might be before
or after the "gpu hung" problem, Xorg seems to be able to cope with that.
But after a gpu lockup it's time to reboot.

If nobody has a better idea I'll try to bisect ... tomorrow.

cu,
 Knut
--
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/