[PATCH] drm/dp: look up the mstb passed into work function

Dave Airlie airlied at gmail.com
Mon Jun 22 00:15:05 PDT 2015

>> 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 point primary will either be a or b
>> as we hold the lock, and if primary from outside the function is a, b or c won't
>> matter as the validation will either pass or fail depending on the
>> state under the
>> lock.
> Hm, I was afraid of some derefencing of the passed-in mstb pointer, but
> indeed we seem to be covered. Still I think pulling the mgr->lock out and
> instead using drm_dp_mst_get_validated_mstb_ref_locked in
> drm_dp_check_and_send_link_address would result in less head-scratching
> next time we read this code ;-)

That's why the follow up patch adds a comment. Also that starts down the road
of locks protecting code not data, the lock is only needed for the lookup
not the whole function. The problem being the function iterates, so then
we end up holding the lock for a lot longer than is required IMO.


More information about the dri-devel mailing list