Re: [PATCH V2] xen: Fix BUFIOREQ evtchn init for a stubdom.

[Keir Fraser <keir.xen@gmail.com>]

On 29/06/2012 11:25, "Jan Beulich" <JBeulich@suse.com> 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
>