[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 5/5] evtchn: don't call Xen consumer callback with per-channel lock held


  • To: Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Isaila Alexandru <aisaila@xxxxxxxxxxxxxxx>
  • Date: Mon, 30 Nov 2020 12:39:23 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=bitdefender.com; dmarc=pass action=none header.from=bitdefender.com; dkim=pass header.d=bitdefender.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=g9DiQhYKayoFWZlhVMSSV5VnP10hD7SjHfBowlZ/e+o=; b=aJf7s1+Kqg5IwyhMljj7avfk2aJJhrosPa7M6FJm31zQXUHs9natflOSiJTxiElnLpqBblqQltsJG5q/zPNuYdig0gCkhKpu1Yb4/7yzOVDBU15w7Z4Usfb8ns0efcM2VRg3s3cnKXe+pdTEsQDJTbw+EuJGHPTCgDq8DM9mmj5PasYY8DboJRjSXS/SXGh7suUwFBhwSlSvtlxkMlaL9O1CKxaaEN8wfCSUhbXQ2ko3S+HN0uAGLSLzudMaiwRWe2m6iVPXnjfzxROVluHjr4nhsfq92UWSBTw2zBGHZIzmBf5sRZPnGM6Eod5uyzaupR/OIXDskwuFhU4b6YeKfQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QlCYa3XLQdrBggSb5abn3o5I0qRPYS+wDCo1Ek98/ES0dWM1ehkoauUwK2Bay/wZGMT47yk9TrUie3qDeR6ZQWMeIBI2rFL7fupV7J+Eecax+DgGtQQ/kQ7TbYJ90qAjdmpQwj2ZyKD6NriQKrf+EUvcc1XIyoxhY8sUYMNEePRPS26xCHgUFzBb7xgOfHUe9vrl73c55gp8z/RW7iRldx6V2HZltk5TWbAv2s6qpWNdHQyGh0H+yIzSXDq/GH65KwV0w8++OT46owxKRK4Fk0dneqLj9YFYky1JQ6F/AFMIVXuvRj4RVsP1ofPgJL1uoDvzL35/86XnHEPdnf4sQQ==
  • Authentication-results: bitdefender.com; dkim=none (message not signed) header.d=none;bitdefender.com; dmarc=none action=none header.from=bitdefender.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Wei Liu <wl@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Tamas K Lengyel <lengyelt@xxxxxxxxxxxx>, Petre Ovidiu PIRCALABU <ppircalabu@xxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 30 Nov 2020 10:39:36 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 23.11.2020 15:30, Jan Beulich wrote:
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.

However, vm_event_disable() frees the structures used by respective
callbacks and isn't otherwise synchronized with invocations of these
callbacks, so maintain a count of in-progress calls, for evtchn_close()
to wait to drop to zero before freeing the port (and dropping the lock).

Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>

Reviewed-by: Alexandru Isaila <aisaila@xxxxxxxxxxxxxxx>

---
Should we make this accounting optional, to be requested through a new
parameter to alloc_unbound_xen_event_channel(), or derived from other
than the default callback being requested?
---
v3: Drain callbacks before proceeding with closing. Re-base.

--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -397,6 +397,7 @@ static long evtchn_bind_interdomain(evtc
rchn->u.interdomain.remote_dom = ld;
      rchn->u.interdomain.remote_port = lport;
+    atomic_set(&rchn->u.interdomain.active_calls, 0);
      rchn->state                     = ECS_INTERDOMAIN;
/*
@@ -720,6 +721,10 @@ int evtchn_close(struct domain *d1, int
double_evtchn_lock(chn1, chn2); + if ( consumer_is_xen(chn1) )
+            while ( atomic_read(&chn1->u.interdomain.active_calls) )
+                cpu_relax();
+
          evtchn_free(d1, chn1);
chn2->state = ECS_UNBOUND;
@@ -781,9 +786,15 @@ int evtchn_send(struct domain *ld, unsig
          rport = lchn->u.interdomain.remote_port;
          rchn  = evtchn_from_port(rd, rport);
          if ( consumer_is_xen(rchn) )
+        {
+            /* Don't keep holding the lock for the call below. */
+            atomic_inc(&rchn->u.interdomain.active_calls);
+            evtchn_read_unlock(lchn);
              xen_notification_fn(rchn)(rd->vcpu[rchn->notify_vcpu_id], rport);
-        else
-            evtchn_port_set_pending(rd, rchn->notify_vcpu_id, rchn);
+            atomic_dec(&rchn->u.interdomain.active_calls);
+            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);
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -104,6 +104,7 @@ struct evtchn
          } unbound;     /* state == ECS_UNBOUND */
          struct {
              evtchn_port_t  remote_port;
+            atomic_t       active_calls;
              struct domain *remote_dom;
          } interdomain; /* state == ECS_INTERDOMAIN */
          struct {





 


Rackspace

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