On 16/06/15 10:18, Jan Beulich wrote: >>>> On 15.06.15 at 17:48, <david.vra...@citrix.com> wrote: >> @@ -1163,11 +1213,15 @@ int alloc_unbound_xen_event_channel( >> if ( rc ) >> goto out; >> >> + spin_lock(&chn->lock); >> + >> chn->state = ECS_UNBOUND; >> chn->xen_consumer = get_xen_consumer(notification_fn); >> chn->notify_vcpu_id = lvcpu; >> chn->u.unbound.remote_domid = remote_domid; >> >> + spin_unlock(&chn->lock); >> + >> out: >> spin_unlock(&ld->event_lock); > > I don't see why you shouldn't be able to move up this unlock.
Because we need to (also) hold ld->event_lock while changing the state from ECS_FREE or a concurrent get_free_port() will find this port again. >> @@ -1221,6 +1277,8 @@ void notify_via_xen_event_channel(struct domain *ld, >> int lport) >> evtchn_port_set_pending(rd, rchn->notify_vcpu_id, rchn); >> } >> >> + spin_unlock(&lchn->lock); >> + >> spin_unlock(&ld->event_lock); >> } > > Again I think the event lock can be dropped earlier now. Ditto. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel