linux-kernel - Re: [BISECTED] drm: random hang since 620f378 "drm: prune modes when ..."

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 for Android: free password hash cracker in your pocket

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

Date:	Sun, 13 Dec 2009 12:18:24 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	Dave Airlie <airlied@...hat.com>
Cc:	Adam Jackson <ajax@...hat.com>, linux-kernel@...r.kernel.org,
	dri-devel@...ts.sourceforge.net, keithp@...thp.com,
	eric@...olt.net, jbarnes@...tuousgeek.org,
	Daniel Vetter <daniel.vetter@...ll.ch>
Subject: Re: [BISECTED] drm: random hang since 620f378 "drm: prune modes when ..."

On Wednesday 09 December 2009 05:38:07 Dave Airlie wrote:
> On Wed, 2009-12-09 at 00:07 +0100, Arnd Bergmann wrote:
> > On Tuesday 08 December 2009, Dave Airlie wrote:
> > > > 
> > > > Sorry for blaming the wrong patch, especially if it already caused a lot 
> > > > of work. I'll try blaming ec2a4c3fdc8 "drm/i915: get the bridge device
> > > > once" now, that is the next-best candidate that my bisection pointed to,
> > > > but I'll do more rigorous testing.
> > 
> > It just crashed again with both 620f378 and ec2a4c3fdc8 reverted as well, 
> > after about an hour of uptime.
> > 
> ...
> 
> regression since 2.6.31 by the looks of it, bisection has found two
> false positives so far.

I did a more thorough bisection this time, which points to c05422d52ee6b
"drm/i915: remove open-coded drm_mode_object_find". The system crashed
within minutes with 2.6.32-git and with c05422d52ee6b, but stayed up
for 12 hours on identical kernels with this one reverted:

>  From c05422d52ee6b4cff8b63eab1a7351780518fc5e Mon Sep 17 00:00:00 2001
>  From: Daniel Vetter <daniel.vetter@...ll.ch>
>  Date: Tue, 11 Aug 2009 16:05:30 +0200
>  Subject: [PATCH] drm/i915: remove open-coded drm_mode_object_find
>
>  And clean up a small whitespace goof-up in the same function, while
>  I was looking at it.
>
>  Signed-off-by: Daniel Vetter <daniel.vetter@...ll.ch>
>  Signed-off-by: Eric Anholt <eric@...olt.net>

Given that my last bisection went wrong and I can't prove why this
patch is bad, I'd of course like to see some insight about what
could go wrong here, but at least reverting it should not be able
to cause any harm.

---

[PATCH] drm/i915: revert c05422d52 "remove open-coded drm_mode_object_find"

The patch was meant as a cleanup, but apparently caused random hangs
on my machine.

Signed-off-by: Arnd Bergmann <arnd@...db.de>
Cc: Daniel Vetter <daniel.vetter@...ll.ch>
Cc: Eric Anholt <eric@...olt.net>

diff --git b/drivers/gpu/drm/i915/intel_display.c a/drivers/gpu/drm/i915/intel_display.c
index f0f38f5..35e8619 100644
--- b/drivers/gpu/drm/i915/intel_display.c
+++ a/drivers/gpu/drm/i915/intel_display.c
@@ -3557,26 +3557,30 @@ int intel_get_pipe_from_crtc_id(struct drm_device *dev, void *data,
 {
 	drm_i915_private_t *dev_priv = dev->dev_private;
 	struct drm_i915_get_pipe_from_crtc_id *pipe_from_crtc_id = data;
-	struct drm_mode_object *drmmode_obj;
-	struct intel_crtc *crtc;
+	struct drm_crtc *crtc = NULL;
+	int pipe = -1;
 
 	if (!dev_priv) {
 		DRM_ERROR("called with no initialization\n");
 		return -EINVAL;
 	}
 
-	drmmode_obj = drm_mode_object_find(dev, pipe_from_crtc_id->crtc_id,
-			DRM_MODE_OBJECT_CRTC);
+	list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
+		struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+		if (crtc->base.id == pipe_from_crtc_id->crtc_id) {
+			pipe = intel_crtc->pipe;
+			break;
+		}
+	}
 
-	if (!drmmode_obj) {
+	if (pipe == -1) {
 		DRM_ERROR("no such CRTC id\n");
 		return -EINVAL;
 	}
 
-	crtc = to_intel_crtc(obj_to_crtc(drmmode_obj));
-	pipe_from_crtc_id->pipe = crtc->pipe;
+	pipe_from_crtc_id->pipe = pipe;
 
-	return 0;
+	return 0;
 }
 
 struct drm_crtc *intel_get_crtc_from_pipe(struct drm_device *dev, int pipe)
--
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/