On 05/19/2014 03:13 PM, Maarten Lankhorst wrote:
> op 19-05-14 15:42, Thomas Hellstrom schreef:
>> Hi, Maarten!
>>
>> Some nitpicks, and that krealloc within rcu lock still worries me.
>> Otherwise looks good.
>>
>> /Thomas
>>
>>
>>
>> On 04/23/2014 12:15 PM, Maarten Lankhorst wrote:
>>> @@ -55,8 +60,8 @@ int reservation_object_reserve_shared(struct
>>> reservation_object *obj)
>>> kfree(obj->staged);
>>> obj->staged = NULL;
>>> return 0;
>>> - }
>>> - max = old->shared_max * 2;
>>> + } else
>>> + max = old->shared_max * 2;
>> Perhaps as a separate reformatting patch?
> I'll fold it in to the patch that added
> reservation_object_reserve_shared.
>>> +
>>> +int reservation_object_get_fences_rcu(struct reservation_object *obj,
>>> + struct fence **pfence_excl,
>>> + unsigned *pshared_count,
>>> + struct fence ***pshared)
>>> +{
>>> + unsigned shared_count = 0;
>>> + unsigned retry = 1;
>>> + struct fence **shared = NULL, *fence_excl = NULL;
>>> + int ret = 0;
>>> +
>>> + while (retry) {
>>> + struct reservation_object_list *fobj;
>>> + unsigned seq;
>>> +
>>> + seq = read_seqcount_begin(&obj->seq);
>>> +
>>> + rcu_read_lock();
>>> +
>>> + fobj = rcu_dereference(obj->fence);
>>> + if (fobj) {
>>> + struct fence **nshared;
>>> +
>>> + shared_count = ACCESS_ONCE(fobj->shared_count);
>> ACCESS_ONCE() shouldn't be needed inside the seqlock?
> Yes it is, shared_count may be increased, leading to potential
> different sizes for krealloc and memcpy
> if the ACCESS_ONCE is removed. I could use shared_max here instead,
> which stays the same,
> but it would waste more memory.
Maarten, Another perhaps ignorant question WRT this,
Does ACCESS_ONCE() guarantee that the value accessed is read atomically?
/Thomas
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
