From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751469AbbGMGTk (ORCPT ); Mon, 13 Jul 2015 02:19:40 -0400 Received: from mail-wi0-f173.google.com ([209.85.212.173]:34187 "EHLO mail-wi0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751114AbbGMGTj (ORCPT ); Mon, 13 Jul 2015 02:19:39 -0400 Date: Mon, 13 Jul 2015 08:22:22 +0200 From: Daniel Vetter To: Linus Torvalds Cc: =?iso-8859-1?Q?J=F6rg?= Otte , Daniel Vetter , David Airlie , DRI , Linux Kernel Mailing List , Maarten Lankhorst Subject: Re: [4.2.0-rc1-00201-g59c3cb5] Regression: kernel NULL pointer dereference Message-ID: <20150713062222.GG3736@phenom.ffwll.local> Mail-Followup-To: Linus Torvalds , =?iso-8859-1?Q?J=F6rg?= Otte , David Airlie , DRI , Linux Kernel Mailing List , Maarten Lankhorst References:

MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: Linux phenom 4.2.0-rc1+ User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jul 12, 2015 at 09:52:51AM -0700, Linus Torvalds wrote: > On Sun, Jul 12, 2015 at 1:03 AM, Jörg Otte wrote: > > > > BUG: unable to handle kernel NULL pointer dereference at 0000000000000009 > > IP: [] 0xffffffffbd3447bb > > Ugh. Please enable KALLSYMS to get sane symbols. > > But yes, "crtc_state->base.active" is at offset 9 from "crtc_state", > so it's pretty clearly just that change frm > > - if (intel_crtc->active) { > + if (crtc_state->base.active) { > > and "crtc_state" is NULL. > > And the code very much knows that crtc_state can be NULL, since it's > initialized with > > crtc_state = state->base.state ? > intel_atomic_get_crtc_state(state->base.state, > intel_crtc) : NULL; > > Tssk. Daniel? Should I just revert that commit dec4f799d0a4 > ("drm/i915: Use crtc_state->active in primary check_plane func") for > now, or is there a better fix? Like just checking crtc_state for NULL? Indeed embarrassing. I've missed that we still have 1 caller left that's using the transitional helpers, and those don't fill out plane_state->state backpointers to the global atomic update since there is no global atomic update for transitional helpers. Below diff should fix this - we need to preferentially check crts_state->active and if that's not set intel_crtc->active should yield the right result for the one remaining caller (it's in the crtc_disable paths). For cheap excuses why i915 is so crap in 4.2: Thanks to a hipshot decision to transition to a different QA team ("we'll do this in 1 week without upfront planing") I essentially don't have proper QA support for 1-2 months by now. The other trouble in this area specifically is that this code is already completely changed in -next again, so any testing done on integration trees (like -next or drm-intel-nightly) won't test any patches for 4.2. -Daniel Oh and Signed-off-by: Daniel Vetter in case you decide to apply this right away. --- diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index ba9321998a41..85ac6d85dc39 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -13276,7 +13276,7 @@ intel_check_primary_plane(struct drm_plane *plane, if (ret) return ret; - if (crtc_state->base.active) { + if (crtc_state ? crtc_state->base.active : intel_crtc->active) { struct intel_plane_state *old_state = to_intel_plane_state(plane->state); -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch