linux-kernel - Re: [RFC][PATCH v2] drm: kirin: Add a mutex to avoid fb initialization race

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] [day] [month] [year] [list]

Date:   Mon, 27 Feb 2017 15:33:16 -0800
From:   John Stultz <john.stultz@...aro.org>
To:     John Stultz <john.stultz@...aro.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Xinliang Liu <z.liuxinliang@...ilicon.com>,
        Rongrong Zou <zourongrong@...il.com>,
        Xinwei Kong <kong.kongxinwei@...ilicon.com>,
        Chen Feng <puck.chen@...ilicon.com>,
        David Airlie <airlied@...ux.ie>,
        Sean Paul <seanpaul@...omium.org>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>
Cc:     Daniel Vetter <daniel.vetter@...ll.ch>
Subject: Re: [RFC][PATCH v2] drm: kirin: Add a mutex to avoid fb
 initialization race

On Sat, Feb 25, 2017 at 11:36 AM, Daniel Vetter <daniel@...ll.ch> wrote:
> On Fri, Feb 24, 2017 at 05:25:16PM -0800, John Stultz wrote:
>> In some cases I've been seeing a race where two framebuffers
>> would be initialized, as kirin_fbdev_output_poll_changed()
>> might get called quickly in succession, resulting in the
>> initialization happening twice. This could cause the system
>> to boot up with a blank screen.
>>
>> This patch adds a simple mutex to serialize it and seems to
>> avoid the race.
>>
>> Suggestions or feedback would be greatly appreciated!
>
> I feel a bit like a broken record, but:
>
> Instead of reinventing broken delayed fbdev setup everywhere, can we
> polish Thierry's patches to move that into the fbdev helpers in the core?
> hisilicon isn't the only driver the (re)invents this weel, it'd be really
> awesome if we could fix this bug just once ...
>
> For reference, the patches:
>
> http://markmail.org/message/d3jc4vebkndtvlkf#query:+page:1+mid:d3jc4vebkndtvlkf+state:results

Thanks for the pointer here, and apologies, I really am not very deep
into or do that much following DRM development. I just am chasing bugs
on my board and trying to fix them up, so I wasn't aware this was
something brought up before.

> I guess Thierry got sidetracked on these, but except for a bit of locking
> scheme polish I think they've been mostly ready. Shouldn't be much work to
> refresh them, hunt for other new drivers reinventing this wheel, do the
> locking polish maybe and then get them landed.

I'll take a look at it and see what I can sort out.

thanks
-john