From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751822AbbGMHX7 (ORCPT ); Mon, 13 Jul 2015 03:23:59 -0400 Received: from mga11.intel.com ([192.55.52.93]:39449 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751327AbbGMHX6 (ORCPT ); Mon, 13 Jul 2015 03:23:58 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,461,1432623600"; d="scan'208";a="745966785" Message-ID: <55A3678B.6080803@linux.intel.com> Date: Mon, 13 Jul 2015 09:23:55 +0200 From: Maarten Lankhorst User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Linus Torvalds , =?windows-1252?Q?J=F6?= =?windows-1252?Q?rg_Otte?= , David Airlie , DRI , Linux Kernel Mailing List Subject: Re: [4.2.0-rc1-00201-g59c3cb5] Regression: kernel NULL pointer dereference References:

<20150713062222.GG3736@phenom.ffwll.local> In-Reply-To: <20150713062222.GG3736@phenom.ffwll.local> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Op 13-07-15 om 08:22 schreef Daniel Vetter: > 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. > Well your version has the benefit of compiling without errors. :-) Reviewed-by: Maarten Lankhorst