[PATCH] drm/ttm: avoid allocation memory while spinlock is held v2

[Daniel Vetter]

On Mon, Feb 4, 2013 at 8:36 PM, Jerome Glisse <j.glisse at gmail.com> wrote:
> On Mon, Feb 4, 2013 at 2:21 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
>> On Mon, Feb 4, 2013 at 7:34 PM,  <j.glisse at gmail.com> wrote:
>>> From: Jerome Glisse <jglisse at redhat.com>
>>>
>>> We need to take reference on the sync object while holding the
>>> fence spinlock but at the same time we don't want to allocate
>>> memory while holding the spinlock. This patch make sure we
>>> enforce both of this constraint.
>>>
>>> v2: actually test build it
>>>
>>> Fix https://bugzilla.redhat.com/show_bug.cgi?id=906296
>>>
>>> Signed-off-by: Jerome Glisse <jglisse at redhat.com>
>>
>> Isn't that just another iteration of
>> https://patchwork.kernel.org/patch/1972071/ which somehow never
>> reached -fixes?
>> -Daniel
>
> Yes but my version doesn't drop the lock before taking the ref, iirc
> there might be a race if droping the lock and then taking it again.
> Another process might race to unref the sync obj but i haven't
> tortured too much my brain on how likely if at all this is possible.

Hm, mine rechecks whether the sync object disappeared (spotted by
Maarten) before grabbing a reference. So should be ok if the fence
signals. Ofc, if we don't hold a reservation on bo someone else might
sneak and add a new one. But since we're trying to move the bo that'd
be a pretty bug already.

In any case yours is a bit nicer since it only grabs the fence_lock
once. My poke was more a stab at Dave, since he originally prodded me
on irc for breaking this, and then it seems to have fallen by the
wayside ;-)

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch