On Mon, Feb 4, 2013 at 8:36 PM, Jerome Glisse j.glisse@gmail.com wrote:
On Mon, Feb 4, 2013 at 2:21 PM, Daniel Vetter daniel@ffwll.ch wrote:
On Mon, Feb 4, 2013 at 7:34 PM, j.glisse@gmail.com wrote:
From: Jerome Glisse jglisse@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@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