linux-kernel - Re: [PATCH] drm: Check for connector->state NULL in drm_atomic_add_affected

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: <CAD=FV=VpAAXRHurEZr--cfQr-FkhVCCA_LMoR0LFDea2DQ_2XA@mail.gmail.com>
Date:	Mon, 7 Mar 2016 16:05:48 -0800
From:	Doug Anderson <dianders@...omium.org>
To:	Douglas Anderson <dianders@...omium.org>,
	David Airlie <airlied@...ux.ie>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	Tomasz Figa <tfiga@...omium.org>,
	姚智情 <mark.yao@...k-chips.com>,
	Heiko Stübner <heiko@...ech.de>
Subject: Re: [PATCH] drm: Check for connector->state NULL in drm_atomic_add_affected_connectors

Daniel,

On Sun, Mar 6, 2016 at 8:29 AM, Daniel Vetter <daniel@...ll.ch> wrote:
> On Fri, Mar 04, 2016 at 03:43:53PM -0800, Douglas Anderson wrote:
>> On a system I'm doing development on I found a crash.  The crawl looked
>> like:
>>
>>   PC is at drm_atomic_add_affected_connectors+0x98/0xe8
>>   ...
>>   drm_atomic_add_affected_connectors from __drm_atomic_helper_set_config+0x218/0x344
>>   __drm_atomic_helper_set_config from restore_fbdev_mode+0x108/0x250
>>   restore_fbdev_mode from drm_fb_helper_restore_fbdev_mode_unlocked+0x3c/0x80
>>   drm_fb_helper_restore_fbdev_mode_unlocked from rockchip_drm_lastclose+0x1c/0x20
>>   rockchip_drm_lastclose from drm_lastclose+0x4c/0x104
>>   drm_lastclose from drm_release+0x424/0x47c
>>   drm_release from __fput+0xf8/0x1d4
>>   __fput from ____fput+0x18/0x1c
>>   ____fput from task_work_run+0xa8/0xbc
>>   task_work_run from do_exit+0x448/0x91c
>>   do_exit from do_group_exit+0x5c/0xcc
>>   do_group_exit from get_signal+0x4dc/0x57c
>>   get_signal from do_signal+0x9c/0x3b4
>>   do_signal from do_work_pending+0x60/0xb8
>>   do_work_pending from slow_work_pending+0xc/0x20
>>
>> I found that I could fix the crash by checking connector->state against
>> NULL.  This isn't code I'm familiar with and I didn't dig too deep, so
>> I'd appreciate any opinions about whether this is a sane thing to do.
>> Note that I don't actually have graphics up on my system at the moment,
>> so perhaps this is all just a symptom of the strange state I'm in.
>>
>> Signed-off-by: Douglas Anderson <dianders@...omium.org>
>
> This is a driver bug - under atomic the assumption is that there is
> _always_ a current software state. Most driver set up the initial
> "everything off" state in the ->reset functions.

Ah, I see what the problem is.  It looks like the main Rockchip
subsystem moved to atomic but the patch to support that in dw_hdmi
never landed.  If I pick <https://patchwork.kernel.org/patch/7868951/>
then my crash goes away.  :)

In case it's not obvious, please consider $SUBJECT patch abandoned.  Thanks!

-Doug