>> It doesn't actually matter if mgr->mst_primary gets messed up here I
>> don't think,
>> as long as we validate it. So the value is going to be either a)
>> correct, b) NULL,
>> c) garbage between a and b assuming its not atomic, the validate function
>> locks the mgr, and checks primary, at this
On 20 June 2015 at 01:42, Daniel Vetter wrote:
> On Fri, Jun 19, 2015 at 10:53:10AM +1000, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> We should validate the passed in mstb under the lock
>> this should stop us getting an invalid mstb here.
>>
>> (first attempt with cancelling work has lockdep
On Mon, Jun 22, 2015 at 02:28:33PM +1000, Dave Airlie wrote:
> On 20 June 2015 at 01:42, Daniel Vetter wrote:
> > On Fri, Jun 19, 2015 at 10:53:10AM +1000, Dave Airlie wrote:
> >> From: Dave Airlie
> >>
> >> We should validate the passed in mstb under the lock
> >> this should stop us getting an
On Fri, Jun 19, 2015 at 10:53:10AM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> We should validate the passed in mstb under the lock
> this should stop us getting an invalid mstb here.
>
> (first attempt with cancelling work has lockdep issues).
Yeah cancel_work_sync is nasty that way ;-)
From: Dave Airlie
We should validate the passed in mstb under the lock
this should stop us getting an invalid mstb here.
(first attempt with cancelling work has lockdep issues).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89366
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_dp_
