On Mon, Feb 4, 2013 at 8:36 PM, Jerome Glisse <j.glisse@xxxxxxxxx> wrote: > On Mon, Feb 4, 2013 at 2:21 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: >> On Mon, Feb 4, 2013 at 7:34 PM, <j.glisse@xxxxxxxxx> wrote: >>> From: Jerome Glisse <jglisse@xxxxxxxxxx> >>> >>> 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@xxxxxxxxxx> >> >> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
