[Intel-gfx] [PATCH v3 11/28] drm/i915: Add IRQ friendly request deference facility

[Daniel Vetter]

On Wed, Nov 26, 2014 at 1:23 PM, John Harrison
<John.C.Harrison at intel.com> wrote:
>> This needs locking. It might work as-is but it's definitely too tricky to
>> be worth it.
>
> The manipulation of the list is locked, only this test is unlocked. Do you
> really need to lock when testing for empty? Nothing can be removing items
> from the list although something could be asynchronously adding them. If the
> 'head->next == head' test goes wrong because head or next is being written
> to, it can't deference a dodgy pointer. It can only return an incorrect
> 'empty' in which case the clean up is delayed until later. An incorrect
> 'not-empty' is not possible.

The problem is not that it's broken but too tricky. And nothing in
either the commit message nor a code commit explains and justifies
this. Of course every time I stumble over this I can think hard for a
while and convince myself that it works, but GEM is already littered
with such inherent complexity, so adding accidental complexity for
locking tricks when they're not needed is a bad move.

Since we don't actually need this in current code I'll drop it.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch