linux-kernel - Re: [Intel-gfx] [Regression] WARNING: drivers/gpu/drm/i915/i915_gem.c:4525 i915_gem_free

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: <20150223234245.GA24485@phenom.ffwll.local>
Date:	Tue, 24 Feb 2015 00:42:45 +0100
From:	Daniel Vetter <daniel@...ll.ch>
To:	Chris Wilson <chris@...is-wilson.co.uk>,
	Andrey Skvortsov <andrej.skvortzov@...il.com>,
	Daniel Vetter <daniel.vetter@...el.com>,
	Jani Nikula <jani.nikula@...ux.intel.com>,
	David Airlie <airlied@...ux.ie>,
	intel-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
	linux-kernel@...r.kernel.org, Sitsofe Wheeler <sitsofe@...il.com>
Subject: Re: [Intel-gfx] [Regression] WARNING:
 drivers/gpu/drm/i915/i915_gem.c:4525 i915_gem_free_object

On Mon, Feb 23, 2015 at 09:20:31PM +0000, Chris Wilson wrote:
> On Mon, Feb 23, 2015 at 11:12:39PM +0300, Andrey Skvortsov wrote:
> > Hi, 
> > 
> > This warning is moved from linux-next to v4.0-rc1 now. After system boot is just a black screen.
> > I ssh'ed into the machine and saved the log. I attached updated dmesg.log with drm.debug=6. Hopefully it helps. 
> > If you need any other debug information, traces, core dump or something else. Feel free to ask.
> 
> The warning from free_object is annoying (and quite possibly dangerous),
> but the actual hang during boot is:
> 
> [  243.876375] INFO: task Xorg:2422 blocked for more than 120 seconds.
> [  243.876382]       Tainted: G        W   E   4.0.0-rc1-150223- #2
> [  243.876388] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [  243.876393] Xorg            D ffff88019fc12dc0     0  2422   2180 0x00400000
> [  243.876404]  ffff8800dabfe1a0 0000000000000002 ffff880194537fd8 ffff880194537ba0
> [  243.876416]  ffff8800dab9e22c ffff8800dabfe1a0 ffff8800dab9e230 00000000ffffffff
> [  243.876426]  ffffffff813e2479 ffff8800dab9e228 ffffffff813e26a7 0000000000000000
> [  243.876438] Call Trace:
> [  243.876449]  [<ffffffff813e2479>] ? schedule+0x6f/0x7c
> [  243.876459]  [<ffffffff813e26a7>] ? schedule_preempt_disabled+0x15/0x21
> [  243.876469]  [<ffffffff813e3347>] ? __ww_mutex_lock_slowpath+0xdf/0x1c2
> [  243.876480]  [<ffffffff813e3446>] ? __ww_mutex_lock+0x1c/0x93
> [  243.876541]  [<ffffffffa050e70d>] ? modeset_lock+0x8f/0xf2 [drm]
> [  243.876632]  [<ffffffffa09aa0b9>] ? intel_get_load_detect_pipe+0x80/0x427 [i915]
> [  243.876674]  [<ffffffffa04fd42f>] ? drm_ut_debug_printk+0x5e/0x63 [drm]
> [  243.876771]  [<ffffffffa09d4661>] ? intel_tv_detect+0x115/0x43a [i915]
> [  243.876783]  [<ffffffff810608d9>] ? preempt_count_sub+0xbf/0xca
> [  243.876809]  [<ffffffffa05d6f24>] ? drm_helper_probe_single_connector_modes_merge_bits+0xc6/0x38d [drm_kms_helper]
> [  243.876860]  [<ffffffffa0505b5d>] ? drm_mode_getconnector+0xf4/0x2ac [drm]
> [  243.876900]  [<ffffffffa04fa911>] ? drm_ioctl+0x338/0x3c5 [drm]
> [  243.876949]  [<ffffffffa0505a69>] ? drm_mode_getcrtc+0xb3/0xb3 [drm]
> [  243.876961]  [<ffffffff81167deb>] ? fsnotify+0x314/0x35d
> [  243.876973]  [<ffffffff811487be>] ? do_vfs_ioctl+0x379/0x431
> [  243.876983]  [<ffffffff811488cc>] ? SyS_ioctl+0x56/0x7c
> [  243.876994]  [<ffffffff813e5152>] ? system_call_fastpath+0x12/0x17
> 
> i.e. it is a mutex deadlock inside tv detect. Daniel does that make sense?

Botch locking rework for atomic. Fix is

https://patchwork.kernel.org/patch/5861631/

and will land as soon as an affected user has provided a tested-by.
Andrey, can you pls give this a spin?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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/