[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 |