|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH V2] xen: Fix BUFIOREQ evtchn init for a stubdom.
On 29/06/2012 11:25, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>>>> + {
>>>> + spin_lock(&iorp->lock);
>>>> + rc = hvm_replace_event_channel(v, a.value,
>>>> +
>>>> (int*)&v->domain->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_EVTCHN]);
>>>> + spin_unlock(&iorp->lock);
>>>> + if ( rc )
>>>> + break;
>>>> }
>>>
>>> My first preference would be for this to be moved out of the
>>> loop. If it has to remain in the loop for some reason, then the
>>> next best option would be to move this into the iorp->lock
>>> protected region immediately below.
>>
>> Agree on moving it out of the loop. But why would you want it protected by
>> iorp->lock?
>
> That's a question to Anthony - I just saw that the same lock is
> being used here and a few lines down.
Ah, I see. It is not necessary to take the lock in the above code fragment.
-- Keir
> Jan
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |