[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [xen staging] evtchn: don't call Xen consumer callback with per-channel lock held
commit 1376ef90d31c971df79de331911bf861a9a11a44 Author: Jan Beulich <jbeulich@xxxxxxxx> AuthorDate: Mon Jan 11 14:53:02 2021 +0100 Commit: Jan Beulich <jbeulich@xxxxxxxx> CommitDate: Mon Jan 11 14:53:02 2021 +0100 evtchn: don't call Xen consumer callback with per-channel lock held While there don't look to be any problems with this right now, the lock order implications from holding the lock can be very difficult to follow (and may be easy to violate unknowingly). The present callbacks don't (and no such callback should) have any need for the lock to be held. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Julien Grall <jgrall@xxxxxxxxxx> --- xen/common/event_channel.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c index 3aa4189d7a..37592028c8 100644 --- a/xen/common/event_channel.c +++ b/xen/common/event_channel.c @@ -775,9 +775,18 @@ int evtchn_send(struct domain *ld, unsigned int lport) rport = lchn->u.interdomain.remote_port; rchn = evtchn_from_port(rd, rport); if ( consumer_is_xen(rchn) ) - xen_notification_fn(rchn)(rd->vcpu[rchn->notify_vcpu_id], rport); - else - evtchn_port_set_pending(rd, rchn->notify_vcpu_id, rchn); + { + /* Don't keep holding the lock for the call below. */ + xen_event_channel_notification_t fn = xen_notification_fn(rchn); + struct vcpu *rv = rd->vcpu[rchn->notify_vcpu_id]; + + rcu_lock_domain(rd); + evtchn_read_unlock(lchn); + fn(rv, rport); + rcu_unlock_domain(rd); + return 0; + } + evtchn_port_set_pending(rd, rchn->notify_vcpu_id, rchn); break; case ECS_IPI: evtchn_port_set_pending(ld, lchn->notify_vcpu_id, lchn); -- generated by git-patchbot for /home/xen/git/xen.git#staging
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |