[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.