Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1552865 > unrolled thread
| Started by | Juergen Gross <jgross@suse.com> |
|---|---|
| First post | 2017-01-06 16:10 +0100 |
| Last post | 2017-01-11 18:00 +0100 |
| Articles | 17 — 5 participants |
Back to article view | Back to linux.kernel
[PATCH 0/3] xen: optimize xenbus performance Juergen Gross <jgross@suse.com> - 2017-01-06 16:10 +0100
[PATCH 2/3] xen: modify xenstore watch event interface Juergen Gross <jgross@suse.com> - 2017-01-06 16:10 +0100
RE: [PATCH 2/3] xen: modify xenstore watch event interface Paul Durrant <Paul.Durrant@citrix.com> - 2017-01-06 16:40 +0100
Re: [PATCH 2/3] xen: modify xenstore watch event interface Wei Liu <wei.liu2@citrix.com> - 2017-01-06 17:30 +0100
Re: [PATCH 2/3] xen: modify xenstore watch event interface Roger Pau Monné <roger.pau@citrix.com> - 2017-01-06 17:40 +0100
Re: [PATCH 2/3] xen: modify xenstore watch event interface Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2017-01-06 23:40 +0100
Re: [PATCH 2/3] xen: modify xenstore watch event interface Juergen Gross <jgross@suse.com> - 2017-01-09 08:20 +0100
Re: [PATCH 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2017-01-09 22:20 +0100
Re: [PATCH 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses Juergen Gross <jgross@suse.com> - 2017-01-10 07:20 +0100
Re: [PATCH 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2017-01-10 17:40 +0100
Re: [PATCH 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2017-01-10 17:40 +0100
Re: [PATCH 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses Juergen Gross <jgross@suse.com> - 2017-01-10 17:50 +0100
Re: [PATCH 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2017-01-10 20:20 +0100
Re: [PATCH 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2017-01-11 00:00 +0100
Re: [PATCH 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses Juergen Gross <jgross@suse.com> - 2017-01-11 06:30 +0100
Re: [PATCH 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2017-01-11 16:40 +0100
Re: [PATCH 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses Juergen Gross <jgross@suse.com> - 2017-01-11 18:00 +0100
| From | Juergen Gross <jgross@suse.com> |
|---|---|
| Date | 2017-01-06 16:10 +0100 |
| Subject | [PATCH 0/3] xen: optimize xenbus performance |
| Message-ID | <sWEjv-3EM-9@gated-at.bofh.it> |
The xenbus driver used for communication with Xenstore (all kernel accesses to Xenstore and in case of Xenstore living in another domain all accesses of the local domain to Xenstore) is rather simple especially regarding multiple concurrent accesses: they are just being serialized in spite of Xenstore being capable to handle multiple parallel accesses. Clean up the external interface(s) of xenbus and optimize its performance by allowing multiple concurrent accesses to Xenstore. Juergen Gross (3): xen: clean up xenbus internal headers xen: modify xenstore watch event interface xen: optimize xenbus driver for multiple concurrent xenstore accesses drivers/block/xen-blkback/xenbus.c | 6 +- drivers/net/xen-netback/xenbus.c | 8 +- drivers/xen/cpu_hotplug.c | 5 +- drivers/xen/manage.c | 6 +- drivers/xen/xen-balloon.c | 2 +- drivers/xen/xen-pciback/xenbus.c | 2 +- drivers/xen/xenbus/xenbus.h | 134 ++++++++ drivers/xen/xenbus/xenbus_client.c | 6 +- drivers/xen/xenbus/xenbus_comms.c | 319 +++++++++++++++-- drivers/xen/xenbus/xenbus_comms.h | 51 --- drivers/xen/xenbus/xenbus_dev_backend.c | 2 +- drivers/xen/xenbus/xenbus_dev_frontend.c | 213 +++++++----- drivers/xen/xenbus/xenbus_probe.c | 14 +- drivers/xen/xenbus/xenbus_probe.h | 88 ----- drivers/xen/xenbus/xenbus_probe_backend.c | 11 +- drivers/xen/xenbus/xenbus_probe_frontend.c | 17 +- drivers/xen/xenbus/xenbus_xs.c | 535 +++++++++++++---------------- drivers/xen/xenfs/super.c | 2 +- drivers/xen/xenfs/xenstored.c | 2 +- include/xen/xenbus.h | 18 +- 20 files changed, 830 insertions(+), 611 deletions(-) create mode 100644 drivers/xen/xenbus/xenbus.h delete mode 100644 drivers/xen/xenbus/xenbus_comms.h delete mode 100644 drivers/xen/xenbus/xenbus_probe.h Cc: konrad.wilk@oracle.com Cc: roger.pau@citrix.com Cc: wei.liu2@citrix.com Cc: paul.durrant@citrix.com Cc: netdev@vger.kernel.org -- 2.10.2
[toc] | [next] | [standalone]
| From | Juergen Gross <jgross@suse.com> |
|---|---|
| Date | 2017-01-06 16:10 +0100 |
| Subject | [PATCH 2/3] xen: modify xenstore watch event interface |
| Message-ID | <sWEjw-3EM-37@gated-at.bofh.it> |
| In reply to | #1552865 |
Today a Xenstore watch event is delivered via a callback function
declared as:
void (*callback)(struct xenbus_watch *,
const char **vec, unsigned int len);
As all watch events only ever come with two parameters (path and token)
changing the prototype to:
void (*callback)(struct xenbus_watch *,
const char *path, const char *token);
is the natural thing to do.
Apply this change and adapt all users.
Cc: konrad.wilk@oracle.com
Cc: roger.pau@citrix.com
Cc: wei.liu2@citrix.com
Cc: paul.durrant@citrix.com
Cc: netdev@vger.kernel.org
Signed-off-by: Juergen Gross <jgross@suse.com>
---
drivers/block/xen-blkback/xenbus.c | 6 +++---
drivers/net/xen-netback/xenbus.c | 8 ++++----
drivers/xen/cpu_hotplug.c | 5 ++---
drivers/xen/manage.c | 6 +++---
drivers/xen/xen-balloon.c | 2 +-
drivers/xen/xen-pciback/xenbus.c | 2 +-
drivers/xen/xenbus/xenbus.h | 6 +++---
drivers/xen/xenbus/xenbus_client.c | 4 ++--
drivers/xen/xenbus/xenbus_dev_frontend.c | 21 ++++++++-------------
drivers/xen/xenbus/xenbus_probe.c | 11 ++++-------
drivers/xen/xenbus/xenbus_probe_backend.c | 8 ++++----
drivers/xen/xenbus/xenbus_probe_frontend.c | 14 +++++++-------
drivers/xen/xenbus/xenbus_xs.c | 29 ++++++++++++++---------------
include/xen/xenbus.h | 6 +++---
14 files changed, 59 insertions(+), 69 deletions(-)
diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
index 415e79b..8fe61b5 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -38,8 +38,8 @@ struct backend_info {
static struct kmem_cache *xen_blkif_cachep;
static void connect(struct backend_info *);
static int connect_ring(struct backend_info *);
-static void backend_changed(struct xenbus_watch *, const char **,
- unsigned int);
+static void backend_changed(struct xenbus_watch *, const char *,
+ const char *);
static void xen_blkif_free(struct xen_blkif *blkif);
static void xen_vbd_free(struct xen_vbd *vbd);
@@ -661,7 +661,7 @@ static int xen_blkbk_probe(struct xenbus_device *dev,
* ready, connect.
*/
static void backend_changed(struct xenbus_watch *watch,
- const char **vec, unsigned int len)
+ const char *path, const char *token)
{
int err;
unsigned major;
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 3124eae..d8a40fa 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -723,7 +723,7 @@ static int xen_net_read_mac(struct xenbus_device *dev, u8 mac[])
}
static void xen_net_rate_changed(struct xenbus_watch *watch,
- const char **vec, unsigned int len)
+ const char *path, const char *token)
{
struct xenvif *vif = container_of(watch, struct xenvif, credit_watch);
struct xenbus_device *dev = xenvif_to_xenbus_device(vif);
@@ -780,7 +780,7 @@ static void xen_unregister_credit_watch(struct xenvif *vif)
}
static void xen_mcast_ctrl_changed(struct xenbus_watch *watch,
- const char **vec, unsigned int len)
+ const char *path, const char *token)
{
struct xenvif *vif = container_of(watch, struct xenvif,
mcast_ctrl_watch);
@@ -855,8 +855,8 @@ static void unregister_hotplug_status_watch(struct backend_info *be)
}
static void hotplug_status_changed(struct xenbus_watch *watch,
- const char **vec,
- unsigned int vec_size)
+ const char *path,
+ const char *token)
{
struct backend_info *be = container_of(watch,
struct backend_info,
diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
index 5676aef..7a4daa2 100644
--- a/drivers/xen/cpu_hotplug.c
+++ b/drivers/xen/cpu_hotplug.c
@@ -68,13 +68,12 @@ static void vcpu_hotplug(unsigned int cpu)
}
static void handle_vcpu_hotplug_event(struct xenbus_watch *watch,
- const char **vec, unsigned int len)
+ const char *path, const char *token)
{
unsigned int cpu;
char *cpustr;
- const char *node = vec[XS_WATCH_PATH];
- cpustr = strstr(node, "cpu/");
+ cpustr = strstr(path, "cpu/");
if (cpustr != NULL) {
sscanf(cpustr, "cpu/%u", &cpu);
vcpu_hotplug(cpu);
diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
index 26e5e85..ca62c09 100644
--- a/drivers/xen/manage.c
+++ b/drivers/xen/manage.c
@@ -218,7 +218,7 @@ static struct shutdown_handler shutdown_handlers[] = {
};
static void shutdown_handler(struct xenbus_watch *watch,
- const char **vec, unsigned int len)
+ const char *path, const char *token)
{
char *str;
struct xenbus_transaction xbt;
@@ -266,8 +266,8 @@ static void shutdown_handler(struct xenbus_watch *watch,
}
#ifdef CONFIG_MAGIC_SYSRQ
-static void sysrq_handler(struct xenbus_watch *watch, const char **vec,
- unsigned int len)
+static void sysrq_handler(struct xenbus_watch *watch, const char *path,
+ const char *token)
{
char sysrq_key = '\0';
struct xenbus_transaction xbt;
diff --git a/drivers/xen/xen-balloon.c b/drivers/xen/xen-balloon.c
index 79865b8..e7715cb 100644
--- a/drivers/xen/xen-balloon.c
+++ b/drivers/xen/xen-balloon.c
@@ -55,7 +55,7 @@ static int register_balloon(struct device *dev);
/* React to a change in the target key */
static void watch_target(struct xenbus_watch *watch,
- const char **vec, unsigned int len)
+ const char *path, const char *token)
{
unsigned long long new_target;
int err;
diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
index 3f0aee0..3814b44 100644
--- a/drivers/xen/xen-pciback/xenbus.c
+++ b/drivers/xen/xen-pciback/xenbus.c
@@ -652,7 +652,7 @@ static int xen_pcibk_setup_backend(struct xen_pcibk_device *pdev)
}
static void xen_pcibk_be_watch(struct xenbus_watch *watch,
- const char **vec, unsigned int len)
+ const char *path, const char *token)
{
struct xen_pcibk_device *pdev =
container_of(watch, struct xen_pcibk_device, be_watch);
diff --git a/drivers/xen/xenbus/xenbus.h b/drivers/xen/xenbus/xenbus.h
index 6a80c1e..bd95c21 100644
--- a/drivers/xen/xenbus/xenbus.h
+++ b/drivers/xen/xenbus/xenbus.h
@@ -39,8 +39,8 @@ struct xen_bus_type {
int (*get_bus_id)(char bus_id[XEN_BUS_ID_SIZE], const char *nodename);
int (*probe)(struct xen_bus_type *bus, const char *type,
const char *dir);
- void (*otherend_changed)(struct xenbus_watch *watch, const char **vec,
- unsigned int len);
+ void (*otherend_changed)(struct xenbus_watch *watch, const char *path,
+ const char *token);
struct bus_type bus;
};
@@ -83,7 +83,7 @@ int xenbus_dev_resume(struct device *dev);
int xenbus_dev_cancel(struct device *dev);
void xenbus_otherend_changed(struct xenbus_watch *watch,
- const char **vec, unsigned int len,
+ const char *path, const char *token,
int ignore_on_shutdown);
int xenbus_read_otherend_details(struct xenbus_device *xendev,
diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index 23edf53..9586c24 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -115,7 +115,7 @@ EXPORT_SYMBOL_GPL(xenbus_strstate);
int xenbus_watch_path(struct xenbus_device *dev, const char *path,
struct xenbus_watch *watch,
void (*callback)(struct xenbus_watch *,
- const char **, unsigned int))
+ const char *, const char *))
{
int err;
@@ -153,7 +153,7 @@ EXPORT_SYMBOL_GPL(xenbus_watch_path);
int xenbus_watch_pathfmt(struct xenbus_device *dev,
struct xenbus_watch *watch,
void (*callback)(struct xenbus_watch *,
- const char **, unsigned int),
+ const char *, const char *),
const char *pathfmt, ...)
{
int err;
diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c b/drivers/xen/xenbus/xenbus_dev_frontend.c
index e2bc9b3..e4b9847 100644
--- a/drivers/xen/xenbus/xenbus_dev_frontend.c
+++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
@@ -258,26 +258,23 @@ static struct watch_adapter *alloc_watch_adapter(const char *path,
}
static void watch_fired(struct xenbus_watch *watch,
- const char **vec,
- unsigned int len)
+ const char *path,
+ const char *token)
{
struct watch_adapter *adap;
struct xsd_sockmsg hdr;
- const char *path, *token;
- int path_len, tok_len, body_len, data_len = 0;
+ const char *token_caller;
+ int path_len, tok_len, body_len;
int ret;
LIST_HEAD(staging_q);
adap = container_of(watch, struct watch_adapter, watch);
- path = vec[XS_WATCH_PATH];
- token = adap->token;
+ token_caller = adap->token;
path_len = strlen(path) + 1;
- tok_len = strlen(token) + 1;
- if (len > 2)
- data_len = vec[len] - vec[2] + 1;
- body_len = path_len + tok_len + data_len;
+ tok_len = strlen(token_caller) + 1;
+ body_len = path_len + tok_len;
hdr.type = XS_WATCH_EVENT;
hdr.len = body_len;
@@ -288,9 +285,7 @@ static void watch_fired(struct xenbus_watch *watch,
if (!ret)
ret = queue_reply(&staging_q, path, path_len);
if (!ret)
- ret = queue_reply(&staging_q, token, tok_len);
- if (!ret && len > 2)
- ret = queue_reply(&staging_q, vec[2], data_len);
+ ret = queue_reply(&staging_q, token_caller, tok_len);
if (!ret) {
/* success: pass reply list onto watcher */
diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
index 6baffbb..74888ca 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -169,7 +169,7 @@ int xenbus_read_otherend_details(struct xenbus_device *xendev,
EXPORT_SYMBOL_GPL(xenbus_read_otherend_details);
void xenbus_otherend_changed(struct xenbus_watch *watch,
- const char **vec, unsigned int len,
+ const char *path, const char *token,
int ignore_on_shutdown)
{
struct xenbus_device *dev =
@@ -180,18 +180,15 @@ void xenbus_otherend_changed(struct xenbus_watch *watch,
/* Protect us against watches firing on old details when the otherend
details change, say immediately after a resume. */
if (!dev->otherend ||
- strncmp(dev->otherend, vec[XS_WATCH_PATH],
- strlen(dev->otherend))) {
- dev_dbg(&dev->dev, "Ignoring watch at %s\n",
- vec[XS_WATCH_PATH]);
+ strncmp(dev->otherend, path, strlen(dev->otherend))) {
+ dev_dbg(&dev->dev, "Ignoring watch at %s\n", path);
return;
}
state = xenbus_read_driver_state(dev->otherend);
dev_dbg(&dev->dev, "state is %d, (%s), %s, %s\n",
- state, xenbus_strstate(state), dev->otherend_watch.node,
- vec[XS_WATCH_PATH]);
+ state, xenbus_strstate(state), dev->otherend_watch.node, path);
/*
* Ignore xenbus transitions during shutdown. This prevents us doing
diff --git a/drivers/xen/xenbus/xenbus_probe_backend.c b/drivers/xen/xenbus/xenbus_probe_backend.c
index f46b4dc..b0bed4f 100644
--- a/drivers/xen/xenbus/xenbus_probe_backend.c
+++ b/drivers/xen/xenbus/xenbus_probe_backend.c
@@ -181,9 +181,9 @@ static int xenbus_probe_backend(struct xen_bus_type *bus, const char *type,
}
static void frontend_changed(struct xenbus_watch *watch,
- const char **vec, unsigned int len)
+ const char *path, const char *token)
{
- xenbus_otherend_changed(watch, vec, len, 0);
+ xenbus_otherend_changed(watch, path, token, 0);
}
static struct xen_bus_type xenbus_backend = {
@@ -204,11 +204,11 @@ static struct xen_bus_type xenbus_backend = {
};
static void backend_changed(struct xenbus_watch *watch,
- const char **vec, unsigned int len)
+ const char *path, const char *token)
{
DPRINTK("");
- xenbus_dev_changed(vec[XS_WATCH_PATH], &xenbus_backend);
+ xenbus_dev_changed(path, &xenbus_backend);
}
static struct xenbus_watch be_watch = {
diff --git a/drivers/xen/xenbus/xenbus_probe_frontend.c b/drivers/xen/xenbus/xenbus_probe_frontend.c
index d7b77a6..19e45ce 100644
--- a/drivers/xen/xenbus/xenbus_probe_frontend.c
+++ b/drivers/xen/xenbus/xenbus_probe_frontend.c
@@ -86,9 +86,9 @@ static int xenbus_uevent_frontend(struct device *_dev,
static void backend_changed(struct xenbus_watch *watch,
- const char **vec, unsigned int len)
+ const char *path, const char *token)
{
- xenbus_otherend_changed(watch, vec, len, 1);
+ xenbus_otherend_changed(watch, path, token, 1);
}
static void xenbus_frontend_delayed_resume(struct work_struct *w)
@@ -153,11 +153,11 @@ static struct xen_bus_type xenbus_frontend = {
};
static void frontend_changed(struct xenbus_watch *watch,
- const char **vec, unsigned int len)
+ const char *path, const char *token)
{
DPRINTK("");
- xenbus_dev_changed(vec[XS_WATCH_PATH], &xenbus_frontend);
+ xenbus_dev_changed(path, &xenbus_frontend);
}
@@ -332,13 +332,13 @@ static DECLARE_WAIT_QUEUE_HEAD(backend_state_wq);
static int backend_state;
static void xenbus_reset_backend_state_changed(struct xenbus_watch *w,
- const char **v, unsigned int l)
+ const char *path, const char *token)
{
- if (xenbus_scanf(XBT_NIL, v[XS_WATCH_PATH], "", "%i",
+ if (xenbus_scanf(XBT_NIL, path, "", "%i",
&backend_state) != 1)
backend_state = XenbusStateUnknown;
printk(KERN_DEBUG "XENBUS: backend %s %s\n",
- v[XS_WATCH_PATH], xenbus_strstate(backend_state));
+ path, xenbus_strstate(backend_state));
wake_up(&backend_state_wq);
}
diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index 4c49d87..ebc768f 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -64,8 +64,8 @@ struct xs_stored_msg {
/* Queued watch events. */
struct {
struct xenbus_watch *handle;
- char **vec;
- unsigned int vec_size;
+ const char *path;
+ const char *token;
} watch;
} u;
};
@@ -765,7 +765,7 @@ void unregister_xenbus_watch(struct xenbus_watch *watch)
if (msg->u.watch.handle != watch)
continue;
list_del(&msg->list);
- kfree(msg->u.watch.vec);
+ kfree(msg->u.watch.path);
kfree(msg);
}
spin_unlock(&watch_events_lock);
@@ -833,11 +833,10 @@ static int xenwatch_thread(void *unused)
if (ent != &watch_events) {
msg = list_entry(ent, struct xs_stored_msg, list);
- msg->u.watch.handle->callback(
- msg->u.watch.handle,
- (const char **)msg->u.watch.vec,
- msg->u.watch.vec_size);
- kfree(msg->u.watch.vec);
+ msg->u.watch.handle->callback(msg->u.watch.handle,
+ msg->u.watch.path,
+ msg->u.watch.token);
+ kfree(msg->u.watch.path);
kfree(msg);
}
@@ -903,24 +902,24 @@ static int process_msg(void)
body[msg->hdr.len] = '\0';
if (msg->hdr.type == XS_WATCH_EVENT) {
- msg->u.watch.vec = split(body, msg->hdr.len,
- &msg->u.watch.vec_size);
- if (IS_ERR(msg->u.watch.vec)) {
- err = PTR_ERR(msg->u.watch.vec);
+ if (count_strings(body, msg->hdr.len) != 2) {
+ err = -EINVAL;
kfree(msg);
+ kfree(body);
goto out;
}
+ msg->u.watch.path = (const char *)body;
+ msg->u.watch.token = (const char *)strchr(body, '\0') + 1;
spin_lock(&watches_lock);
- msg->u.watch.handle = find_watch(
- msg->u.watch.vec[XS_WATCH_TOKEN]);
+ msg->u.watch.handle = find_watch(msg->u.watch.token);
if (msg->u.watch.handle != NULL) {
spin_lock(&watch_events_lock);
list_add_tail(&msg->list, &watch_events);
wake_up(&watch_events_waitq);
spin_unlock(&watch_events_lock);
} else {
- kfree(msg->u.watch.vec);
+ kfree(body);
kfree(msg);
}
spin_unlock(&watches_lock);
diff --git a/include/xen/xenbus.h b/include/xen/xenbus.h
index 98f73a2..869c816 100644
--- a/include/xen/xenbus.h
+++ b/include/xen/xenbus.h
@@ -61,7 +61,7 @@ struct xenbus_watch
/* Callback (executed in a process context with no locks held). */
void (*callback)(struct xenbus_watch *,
- const char **vec, unsigned int len);
+ const char *path, const char *token);
};
@@ -193,11 +193,11 @@ void xenbus_probe(struct work_struct *);
int xenbus_watch_path(struct xenbus_device *dev, const char *path,
struct xenbus_watch *watch,
void (*callback)(struct xenbus_watch *,
- const char **, unsigned int));
+ const char *, const char *));
__printf(4, 5)
int xenbus_watch_pathfmt(struct xenbus_device *dev, struct xenbus_watch *watch,
void (*callback)(struct xenbus_watch *,
- const char **, unsigned int),
+ const char *, const char *),
const char *pathfmt, ...);
int xenbus_switch_state(struct xenbus_device *dev, enum xenbus_state new_state);
--
2.10.2
[toc] | [prev] | [next] | [standalone]
| From | Paul Durrant <Paul.Durrant@citrix.com> |
|---|---|
| Date | 2017-01-06 16:40 +0100 |
| Subject | RE: [PATCH 2/3] xen: modify xenstore watch event interface |
| Message-ID | <sWEMx-3RV-23@gated-at.bofh.it> |
| In reply to | #1552869 |
> -----Original Message-----
> From: Juergen Gross [mailto:jgross@suse.com]
> Sent: 06 January 2017 15:06
> To: linux-kernel@vger.kernel.org; xen-devel@lists.xenproject.org
> Cc: boris.ostrovsky@oracle.com; Juergen Gross <jgross@suse.com>;
> konrad.wilk@oracle.com; Roger Pau Monne <roger.pau@citrix.com>; Wei Liu
> <wei.liu2@citrix.com>; Paul Durrant <Paul.Durrant@citrix.com>;
> netdev@vger.kernel.org
> Subject: [PATCH 2/3] xen: modify xenstore watch event interface
>
> Today a Xenstore watch event is delivered via a callback function
> declared as:
>
> void (*callback)(struct xenbus_watch *,
> const char **vec, unsigned int len);
>
> As all watch events only ever come with two parameters (path and token)
> changing the prototype to:
>
> void (*callback)(struct xenbus_watch *,
> const char *path, const char *token);
>
> is the natural thing to do.
>
> Apply this change and adapt all users.
>
> Cc: konrad.wilk@oracle.com
> Cc: roger.pau@citrix.com
> Cc: wei.liu2@citrix.com
> Cc: paul.durrant@citrix.com
> Cc: netdev@vger.kernel.org
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
xen-netback changes...
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
> ---
> drivers/block/xen-blkback/xenbus.c | 6 +++---
> drivers/net/xen-netback/xenbus.c | 8 ++++----
> drivers/xen/cpu_hotplug.c | 5 ++---
> drivers/xen/manage.c | 6 +++---
> drivers/xen/xen-balloon.c | 2 +-
> drivers/xen/xen-pciback/xenbus.c | 2 +-
> drivers/xen/xenbus/xenbus.h | 6 +++---
> drivers/xen/xenbus/xenbus_client.c | 4 ++--
> drivers/xen/xenbus/xenbus_dev_frontend.c | 21 ++++++++-------------
> drivers/xen/xenbus/xenbus_probe.c | 11 ++++-------
> drivers/xen/xenbus/xenbus_probe_backend.c | 8 ++++----
> drivers/xen/xenbus/xenbus_probe_frontend.c | 14 +++++++-------
> drivers/xen/xenbus/xenbus_xs.c | 29 ++++++++++++++---------------
> include/xen/xenbus.h | 6 +++---
> 14 files changed, 59 insertions(+), 69 deletions(-)
>
> diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-
> blkback/xenbus.c
> index 415e79b..8fe61b5 100644
> --- a/drivers/block/xen-blkback/xenbus.c
> +++ b/drivers/block/xen-blkback/xenbus.c
> @@ -38,8 +38,8 @@ struct backend_info {
> static struct kmem_cache *xen_blkif_cachep;
> static void connect(struct backend_info *);
> static int connect_ring(struct backend_info *);
> -static void backend_changed(struct xenbus_watch *, const char **,
> - unsigned int);
> +static void backend_changed(struct xenbus_watch *, const char *,
> + const char *);
> static void xen_blkif_free(struct xen_blkif *blkif);
> static void xen_vbd_free(struct xen_vbd *vbd);
>
> @@ -661,7 +661,7 @@ static int xen_blkbk_probe(struct xenbus_device
> *dev,
> * ready, connect.
> */
> static void backend_changed(struct xenbus_watch *watch,
> - const char **vec, unsigned int len)
> + const char *path, const char *token)
> {
> int err;
> unsigned major;
> diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-
> netback/xenbus.c
> index 3124eae..d8a40fa 100644
> --- a/drivers/net/xen-netback/xenbus.c
> +++ b/drivers/net/xen-netback/xenbus.c
> @@ -723,7 +723,7 @@ static int xen_net_read_mac(struct xenbus_device
> *dev, u8 mac[])
> }
>
> static void xen_net_rate_changed(struct xenbus_watch *watch,
> - const char **vec, unsigned int len)
> + const char *path, const char *token)
> {
> struct xenvif *vif = container_of(watch, struct xenvif, credit_watch);
> struct xenbus_device *dev = xenvif_to_xenbus_device(vif);
> @@ -780,7 +780,7 @@ static void xen_unregister_credit_watch(struct xenvif
> *vif)
> }
>
> static void xen_mcast_ctrl_changed(struct xenbus_watch *watch,
> - const char **vec, unsigned int len)
> + const char *path, const char *token)
> {
> struct xenvif *vif = container_of(watch, struct xenvif,
> mcast_ctrl_watch);
> @@ -855,8 +855,8 @@ static void unregister_hotplug_status_watch(struct
> backend_info *be)
> }
>
> static void hotplug_status_changed(struct xenbus_watch *watch,
> - const char **vec,
> - unsigned int vec_size)
> + const char *path,
> + const char *token)
> {
> struct backend_info *be = container_of(watch,
> struct backend_info,
> diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
> index 5676aef..7a4daa2 100644
> --- a/drivers/xen/cpu_hotplug.c
> +++ b/drivers/xen/cpu_hotplug.c
> @@ -68,13 +68,12 @@ static void vcpu_hotplug(unsigned int cpu)
> }
>
> static void handle_vcpu_hotplug_event(struct xenbus_watch *watch,
> - const char **vec, unsigned int len)
> + const char *path, const char *token)
> {
> unsigned int cpu;
> char *cpustr;
> - const char *node = vec[XS_WATCH_PATH];
>
> - cpustr = strstr(node, "cpu/");
> + cpustr = strstr(path, "cpu/");
> if (cpustr != NULL) {
> sscanf(cpustr, "cpu/%u", &cpu);
> vcpu_hotplug(cpu);
> diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
> index 26e5e85..ca62c09 100644
> --- a/drivers/xen/manage.c
> +++ b/drivers/xen/manage.c
> @@ -218,7 +218,7 @@ static struct shutdown_handler shutdown_handlers[]
> = {
> };
>
> static void shutdown_handler(struct xenbus_watch *watch,
> - const char **vec, unsigned int len)
> + const char *path, const char *token)
> {
> char *str;
> struct xenbus_transaction xbt;
> @@ -266,8 +266,8 @@ static void shutdown_handler(struct xenbus_watch
> *watch,
> }
>
> #ifdef CONFIG_MAGIC_SYSRQ
> -static void sysrq_handler(struct xenbus_watch *watch, const char **vec,
> - unsigned int len)
> +static void sysrq_handler(struct xenbus_watch *watch, const char *path,
> + const char *token)
> {
> char sysrq_key = '\0';
> struct xenbus_transaction xbt;
> diff --git a/drivers/xen/xen-balloon.c b/drivers/xen/xen-balloon.c
> index 79865b8..e7715cb 100644
> --- a/drivers/xen/xen-balloon.c
> +++ b/drivers/xen/xen-balloon.c
> @@ -55,7 +55,7 @@ static int register_balloon(struct device *dev);
>
> /* React to a change in the target key */
> static void watch_target(struct xenbus_watch *watch,
> - const char **vec, unsigned int len)
> + const char *path, const char *token)
> {
> unsigned long long new_target;
> int err;
> diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-
> pciback/xenbus.c
> index 3f0aee0..3814b44 100644
> --- a/drivers/xen/xen-pciback/xenbus.c
> +++ b/drivers/xen/xen-pciback/xenbus.c
> @@ -652,7 +652,7 @@ static int xen_pcibk_setup_backend(struct
> xen_pcibk_device *pdev)
> }
>
> static void xen_pcibk_be_watch(struct xenbus_watch *watch,
> - const char **vec, unsigned int len)
> + const char *path, const char *token)
> {
> struct xen_pcibk_device *pdev =
> container_of(watch, struct xen_pcibk_device, be_watch);
> diff --git a/drivers/xen/xenbus/xenbus.h b/drivers/xen/xenbus/xenbus.h
> index 6a80c1e..bd95c21 100644
> --- a/drivers/xen/xenbus/xenbus.h
> +++ b/drivers/xen/xenbus/xenbus.h
> @@ -39,8 +39,8 @@ struct xen_bus_type {
> int (*get_bus_id)(char bus_id[XEN_BUS_ID_SIZE], const char
> *nodename);
> int (*probe)(struct xen_bus_type *bus, const char *type,
> const char *dir);
> - void (*otherend_changed)(struct xenbus_watch *watch, const char
> **vec,
> - unsigned int len);
> + void (*otherend_changed)(struct xenbus_watch *watch, const char
> *path,
> + const char *token);
> struct bus_type bus;
> };
>
> @@ -83,7 +83,7 @@ int xenbus_dev_resume(struct device *dev);
> int xenbus_dev_cancel(struct device *dev);
>
> void xenbus_otherend_changed(struct xenbus_watch *watch,
> - const char **vec, unsigned int len,
> + const char *path, const char *token,
> int ignore_on_shutdown);
>
> int xenbus_read_otherend_details(struct xenbus_device *xendev,
> diff --git a/drivers/xen/xenbus/xenbus_client.c
> b/drivers/xen/xenbus/xenbus_client.c
> index 23edf53..9586c24 100644
> --- a/drivers/xen/xenbus/xenbus_client.c
> +++ b/drivers/xen/xenbus/xenbus_client.c
> @@ -115,7 +115,7 @@ EXPORT_SYMBOL_GPL(xenbus_strstate);
> int xenbus_watch_path(struct xenbus_device *dev, const char *path,
> struct xenbus_watch *watch,
> void (*callback)(struct xenbus_watch *,
> - const char **, unsigned int))
> + const char *, const char *))
> {
> int err;
>
> @@ -153,7 +153,7 @@ EXPORT_SYMBOL_GPL(xenbus_watch_path);
> int xenbus_watch_pathfmt(struct xenbus_device *dev,
> struct xenbus_watch *watch,
> void (*callback)(struct xenbus_watch *,
> - const char **, unsigned int),
> + const char *, const char *),
> const char *pathfmt, ...)
> {
> int err;
> diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c
> b/drivers/xen/xenbus/xenbus_dev_frontend.c
> index e2bc9b3..e4b9847 100644
> --- a/drivers/xen/xenbus/xenbus_dev_frontend.c
> +++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
> @@ -258,26 +258,23 @@ static struct watch_adapter
> *alloc_watch_adapter(const char *path,
> }
>
> static void watch_fired(struct xenbus_watch *watch,
> - const char **vec,
> - unsigned int len)
> + const char *path,
> + const char *token)
> {
> struct watch_adapter *adap;
> struct xsd_sockmsg hdr;
> - const char *path, *token;
> - int path_len, tok_len, body_len, data_len = 0;
> + const char *token_caller;
> + int path_len, tok_len, body_len;
> int ret;
> LIST_HEAD(staging_q);
>
> adap = container_of(watch, struct watch_adapter, watch);
>
> - path = vec[XS_WATCH_PATH];
> - token = adap->token;
> + token_caller = adap->token;
>
> path_len = strlen(path) + 1;
> - tok_len = strlen(token) + 1;
> - if (len > 2)
> - data_len = vec[len] - vec[2] + 1;
> - body_len = path_len + tok_len + data_len;
> + tok_len = strlen(token_caller) + 1;
> + body_len = path_len + tok_len;
>
> hdr.type = XS_WATCH_EVENT;
> hdr.len = body_len;
> @@ -288,9 +285,7 @@ static void watch_fired(struct xenbus_watch *watch,
> if (!ret)
> ret = queue_reply(&staging_q, path, path_len);
> if (!ret)
> - ret = queue_reply(&staging_q, token, tok_len);
> - if (!ret && len > 2)
> - ret = queue_reply(&staging_q, vec[2], data_len);
> + ret = queue_reply(&staging_q, token_caller, tok_len);
>
> if (!ret) {
> /* success: pass reply list onto watcher */
> diff --git a/drivers/xen/xenbus/xenbus_probe.c
> b/drivers/xen/xenbus/xenbus_probe.c
> index 6baffbb..74888ca 100644
> --- a/drivers/xen/xenbus/xenbus_probe.c
> +++ b/drivers/xen/xenbus/xenbus_probe.c
> @@ -169,7 +169,7 @@ int xenbus_read_otherend_details(struct
> xenbus_device *xendev,
> EXPORT_SYMBOL_GPL(xenbus_read_otherend_details);
>
> void xenbus_otherend_changed(struct xenbus_watch *watch,
> - const char **vec, unsigned int len,
> + const char *path, const char *token,
> int ignore_on_shutdown)
> {
> struct xenbus_device *dev =
> @@ -180,18 +180,15 @@ void xenbus_otherend_changed(struct
> xenbus_watch *watch,
> /* Protect us against watches firing on old details when the otherend
> details change, say immediately after a resume. */
> if (!dev->otherend ||
> - strncmp(dev->otherend, vec[XS_WATCH_PATH],
> - strlen(dev->otherend))) {
> - dev_dbg(&dev->dev, "Ignoring watch at %s\n",
> - vec[XS_WATCH_PATH]);
> + strncmp(dev->otherend, path, strlen(dev->otherend))) {
> + dev_dbg(&dev->dev, "Ignoring watch at %s\n", path);
> return;
> }
>
> state = xenbus_read_driver_state(dev->otherend);
>
> dev_dbg(&dev->dev, "state is %d, (%s), %s, %s\n",
> - state, xenbus_strstate(state), dev->otherend_watch.node,
> - vec[XS_WATCH_PATH]);
> + state, xenbus_strstate(state), dev->otherend_watch.node,
> path);
>
> /*
> * Ignore xenbus transitions during shutdown. This prevents us doing
> diff --git a/drivers/xen/xenbus/xenbus_probe_backend.c
> b/drivers/xen/xenbus/xenbus_probe_backend.c
> index f46b4dc..b0bed4f 100644
> --- a/drivers/xen/xenbus/xenbus_probe_backend.c
> +++ b/drivers/xen/xenbus/xenbus_probe_backend.c
> @@ -181,9 +181,9 @@ static int xenbus_probe_backend(struct
> xen_bus_type *bus, const char *type,
> }
>
> static void frontend_changed(struct xenbus_watch *watch,
> - const char **vec, unsigned int len)
> + const char *path, const char *token)
> {
> - xenbus_otherend_changed(watch, vec, len, 0);
> + xenbus_otherend_changed(watch, path, token, 0);
> }
>
> static struct xen_bus_type xenbus_backend = {
> @@ -204,11 +204,11 @@ static struct xen_bus_type xenbus_backend = {
> };
>
> static void backend_changed(struct xenbus_watch *watch,
> - const char **vec, unsigned int len)
> + const char *path, const char *token)
> {
> DPRINTK("");
>
> - xenbus_dev_changed(vec[XS_WATCH_PATH], &xenbus_backend);
> + xenbus_dev_changed(path, &xenbus_backend);
> }
>
> static struct xenbus_watch be_watch = {
> diff --git a/drivers/xen/xenbus/xenbus_probe_frontend.c
> b/drivers/xen/xenbus/xenbus_probe_frontend.c
> index d7b77a6..19e45ce 100644
> --- a/drivers/xen/xenbus/xenbus_probe_frontend.c
> +++ b/drivers/xen/xenbus/xenbus_probe_frontend.c
> @@ -86,9 +86,9 @@ static int xenbus_uevent_frontend(struct device *_dev,
>
>
> static void backend_changed(struct xenbus_watch *watch,
> - const char **vec, unsigned int len)
> + const char *path, const char *token)
> {
> - xenbus_otherend_changed(watch, vec, len, 1);
> + xenbus_otherend_changed(watch, path, token, 1);
> }
>
> static void xenbus_frontend_delayed_resume(struct work_struct *w)
> @@ -153,11 +153,11 @@ static struct xen_bus_type xenbus_frontend = {
> };
>
> static void frontend_changed(struct xenbus_watch *watch,
> - const char **vec, unsigned int len)
> + const char *path, const char *token)
> {
> DPRINTK("");
>
> - xenbus_dev_changed(vec[XS_WATCH_PATH], &xenbus_frontend);
> + xenbus_dev_changed(path, &xenbus_frontend);
> }
>
>
> @@ -332,13 +332,13 @@ static
> DECLARE_WAIT_QUEUE_HEAD(backend_state_wq);
> static int backend_state;
>
> static void xenbus_reset_backend_state_changed(struct xenbus_watch *w,
> - const char **v, unsigned int l)
> + const char *path, const char *token)
> {
> - if (xenbus_scanf(XBT_NIL, v[XS_WATCH_PATH], "", "%i",
> + if (xenbus_scanf(XBT_NIL, path, "", "%i",
> &backend_state) != 1)
> backend_state = XenbusStateUnknown;
> printk(KERN_DEBUG "XENBUS: backend %s %s\n",
> - v[XS_WATCH_PATH],
> xenbus_strstate(backend_state));
> + path, xenbus_strstate(backend_state));
> wake_up(&backend_state_wq);
> }
>
> diff --git a/drivers/xen/xenbus/xenbus_xs.c
> b/drivers/xen/xenbus/xenbus_xs.c
> index 4c49d87..ebc768f 100644
> --- a/drivers/xen/xenbus/xenbus_xs.c
> +++ b/drivers/xen/xenbus/xenbus_xs.c
> @@ -64,8 +64,8 @@ struct xs_stored_msg {
> /* Queued watch events. */
> struct {
> struct xenbus_watch *handle;
> - char **vec;
> - unsigned int vec_size;
> + const char *path;
> + const char *token;
> } watch;
> } u;
> };
> @@ -765,7 +765,7 @@ void unregister_xenbus_watch(struct xenbus_watch
> *watch)
> if (msg->u.watch.handle != watch)
> continue;
> list_del(&msg->list);
> - kfree(msg->u.watch.vec);
> + kfree(msg->u.watch.path);
> kfree(msg);
> }
> spin_unlock(&watch_events_lock);
> @@ -833,11 +833,10 @@ static int xenwatch_thread(void *unused)
>
> if (ent != &watch_events) {
> msg = list_entry(ent, struct xs_stored_msg, list);
> - msg->u.watch.handle->callback(
> - msg->u.watch.handle,
> - (const char **)msg->u.watch.vec,
> - msg->u.watch.vec_size);
> - kfree(msg->u.watch.vec);
> + msg->u.watch.handle->callback(msg-
> >u.watch.handle,
> + msg->u.watch.path,
> + msg->u.watch.token);
> + kfree(msg->u.watch.path);
> kfree(msg);
> }
>
> @@ -903,24 +902,24 @@ static int process_msg(void)
> body[msg->hdr.len] = '\0';
>
> if (msg->hdr.type == XS_WATCH_EVENT) {
> - msg->u.watch.vec = split(body, msg->hdr.len,
> - &msg->u.watch.vec_size);
> - if (IS_ERR(msg->u.watch.vec)) {
> - err = PTR_ERR(msg->u.watch.vec);
> + if (count_strings(body, msg->hdr.len) != 2) {
> + err = -EINVAL;
> kfree(msg);
> + kfree(body);
> goto out;
> }
> + msg->u.watch.path = (const char *)body;
> + msg->u.watch.token = (const char *)strchr(body, '\0') + 1;
>
> spin_lock(&watches_lock);
> - msg->u.watch.handle = find_watch(
> - msg->u.watch.vec[XS_WATCH_TOKEN]);
> + msg->u.watch.handle = find_watch(msg->u.watch.token);
> if (msg->u.watch.handle != NULL) {
> spin_lock(&watch_events_lock);
> list_add_tail(&msg->list, &watch_events);
> wake_up(&watch_events_waitq);
> spin_unlock(&watch_events_lock);
> } else {
> - kfree(msg->u.watch.vec);
> + kfree(body);
> kfree(msg);
> }
> spin_unlock(&watches_lock);
> diff --git a/include/xen/xenbus.h b/include/xen/xenbus.h
> index 98f73a2..869c816 100644
> --- a/include/xen/xenbus.h
> +++ b/include/xen/xenbus.h
> @@ -61,7 +61,7 @@ struct xenbus_watch
>
> /* Callback (executed in a process context with no locks held). */
> void (*callback)(struct xenbus_watch *,
> - const char **vec, unsigned int len);
> + const char *path, const char *token);
> };
>
>
> @@ -193,11 +193,11 @@ void xenbus_probe(struct work_struct *);
> int xenbus_watch_path(struct xenbus_device *dev, const char *path,
> struct xenbus_watch *watch,
> void (*callback)(struct xenbus_watch *,
> - const char **, unsigned int));
> + const char *, const char *));
> __printf(4, 5)
> int xenbus_watch_pathfmt(struct xenbus_device *dev, struct
> xenbus_watch *watch,
> void (*callback)(struct xenbus_watch *,
> - const char **, unsigned int),
> + const char *, const char *),
> const char *pathfmt, ...);
>
> int xenbus_switch_state(struct xenbus_device *dev, enum xenbus_state
> new_state);
> --
> 2.10.2
[toc] | [prev] | [next] | [standalone]
| From | Wei Liu <wei.liu2@citrix.com> |
|---|---|
| Date | 2017-01-06 17:30 +0100 |
| Subject | Re: [PATCH 2/3] xen: modify xenstore watch event interface |
| Message-ID | <sWFyW-4sv-41@gated-at.bofh.it> |
| In reply to | #1552869 |
On Fri, Jan 06, 2017 at 04:05:43PM +0100, Juergen Gross wrote: > Today a Xenstore watch event is delivered via a callback function > declared as: > > void (*callback)(struct xenbus_watch *, > const char **vec, unsigned int len); > > As all watch events only ever come with two parameters (path and token) > changing the prototype to: > > void (*callback)(struct xenbus_watch *, > const char *path, const char *token); > > is the natural thing to do. > > Apply this change and adapt all users. > > Cc: konrad.wilk@oracle.com > Cc: roger.pau@citrix.com > Cc: wei.liu2@citrix.com > Cc: paul.durrant@citrix.com > Cc: netdev@vger.kernel.org > > Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com>
[toc] | [prev] | [next] | [standalone]
| From | Roger Pau Monné <roger.pau@citrix.com> |
|---|---|
| Date | 2017-01-06 17:40 +0100 |
| Subject | Re: [PATCH 2/3] xen: modify xenstore watch event interface |
| Message-ID | <sWFIC-4w8-41@gated-at.bofh.it> |
| In reply to | #1552869 |
On Fri, Jan 06, 2017 at 04:05:43PM +0100, Juergen Gross wrote: > Today a Xenstore watch event is delivered via a callback function > declared as: > > void (*callback)(struct xenbus_watch *, > const char **vec, unsigned int len); > > As all watch events only ever come with two parameters (path and token) > changing the prototype to: > > void (*callback)(struct xenbus_watch *, > const char *path, const char *token); > > is the natural thing to do. > > Apply this change and adapt all users. > > Cc: konrad.wilk@oracle.com > Cc: roger.pau@citrix.com > Cc: wei.liu2@citrix.com > Cc: paul.durrant@citrix.com > Cc: netdev@vger.kernel.org > > Signed-off-by: Juergen Gross <jgross@suse.com> blkback changes: Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Thanks, Roger.
[toc] | [prev] | [next] | [standalone]
| From | Boris Ostrovsky <boris.ostrovsky@oracle.com> |
|---|---|
| Date | 2017-01-06 23:40 +0100 |
| Subject | Re: [PATCH 2/3] xen: modify xenstore watch event interface |
| Message-ID | <sWLl0-8sx-15@gated-at.bofh.it> |
| In reply to | #1552869 |
On 01/06/2017 10:05 AM, Juergen Gross wrote:
> Today a Xenstore watch event is delivered via a callback function
> declared as:
>
> void (*callback)(struct xenbus_watch *,
> const char **vec, unsigned int len);
>
> As all watch events only ever come with two parameters (path and token)
> changing the prototype to:
>
> void (*callback)(struct xenbus_watch *,
> const char *path, const char *token);
>
> is the natural thing to do.
>
> Apply this change and adapt all users.
>
> Cc: konrad.wilk@oracle.com
> Cc: roger.pau@citrix.com
> Cc: wei.liu2@citrix.com
> Cc: paul.durrant@citrix.com
> Cc: netdev@vger.kernel.org
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
>
> @@ -903,24 +902,24 @@ static int process_msg(void)
> body[msg->hdr.len] = '\0';
>
> if (msg->hdr.type == XS_WATCH_EVENT) {
> - msg->u.watch.vec = split(body, msg->hdr.len,
> - &msg->u.watch.vec_size);
> - if (IS_ERR(msg->u.watch.vec)) {
> - err = PTR_ERR(msg->u.watch.vec);
> + if (count_strings(body, msg->hdr.len) != 2) {
> + err = -EINVAL;
xenbus_write_watch() returns -EILSEQ when this type of error is
encountered so perhaps for we should return the same error here.
Either way
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
[toc] | [prev] | [next] | [standalone]
| From | Juergen Gross <jgross@suse.com> |
|---|---|
| Date | 2017-01-09 08:20 +0100 |
| Subject | Re: [PATCH 2/3] xen: modify xenstore watch event interface |
| Message-ID | <sXCpj-13u-3@gated-at.bofh.it> |
| In reply to | #1553355 |
On 06/01/17 22:57, Boris Ostrovsky wrote:
> On 01/06/2017 10:05 AM, Juergen Gross wrote:
>> Today a Xenstore watch event is delivered via a callback function
>> declared as:
>>
>> void (*callback)(struct xenbus_watch *,
>> const char **vec, unsigned int len);
>>
>> As all watch events only ever come with two parameters (path and token)
>> changing the prototype to:
>>
>> void (*callback)(struct xenbus_watch *,
>> const char *path, const char *token);
>>
>> is the natural thing to do.
>>
>> Apply this change and adapt all users.
>>
>> Cc: konrad.wilk@oracle.com
>> Cc: roger.pau@citrix.com
>> Cc: wei.liu2@citrix.com
>> Cc: paul.durrant@citrix.com
>> Cc: netdev@vger.kernel.org
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>
>
>>
>> @@ -903,24 +902,24 @@ static int process_msg(void)
>> body[msg->hdr.len] = '\0';
>>
>> if (msg->hdr.type == XS_WATCH_EVENT) {
>> - msg->u.watch.vec = split(body, msg->hdr.len,
>> - &msg->u.watch.vec_size);
>> - if (IS_ERR(msg->u.watch.vec)) {
>> - err = PTR_ERR(msg->u.watch.vec);
>> + if (count_strings(body, msg->hdr.len) != 2) {
>> + err = -EINVAL;
>
> xenbus_write_watch() returns -EILSEQ when this type of error is
> encountered so perhaps for we should return the same error here.
Not since 9a6161fe73bdd3ae4a1e18421b0b20cb7141f680. :-)
>
> Either way
>
> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Thanks,
Juergen
[toc] | [prev] | [next] | [standalone]
| From | Boris Ostrovsky <boris.ostrovsky@oracle.com> |
|---|---|
| Date | 2017-01-09 22:20 +0100 |
| Subject | Re: [PATCH 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses |
| Message-ID | <sXPwe-PW-29@gated-at.bofh.it> |
| In reply to | #1552865 |
On 01/06/2017 10:05 AM, Juergen Gross wrote:
> Handling of multiple concurrent Xenstore accesses through xenbus driver
> either from the kernel or user land is rather lame today: xenbus is
> capable to have one access active only at one point of time.
>
> Rewrite xenbus to handle multiple requests concurrently by making use
> of the request id of the Xenstore protocol. This requires to:
>
> - Instead of blocking inside xb_read() when trying to read data from
> the xenstore ring buffer do so only in the main loop of
> xenbus_thread().
>
> - Instead of doing writes to the xenstore ring buffer in the context of
> the caller just queue the request and do the write in the dedicated
> xenbus thread.
>
> - Instead of just forwarding the request id specified by the caller of
> xenbus to xenstore use a xenbus internal unique request id. This will
> allow multiple outstanding requests.
>
> - Modify the locking scheme in order to allow multiple requests being
> active in parallel.
>
> - Instead of waiting for the reply of a user's xenstore request after
> writing the request to the xenstore ring buffer return directly to
> the caller and do the waiting in the read path.
>
> Additionally signal handling was optimized by avoiding waking up the
> xenbus thread or sending an event to Xenstore in case the addressed
> entity is known to be running already.
>
> As a result communication with Xenstore is sped up by a factor of up
> to 5: depending on the request type (read or write) and the amount of
> data transferred the gain was at least 20% (small reads) and went up to
> a factor of 5 for large writes.
>
> In the end some more rough edges of xenbus have been smoothed:
>
> - Handling of memory shortage when reading from xenstore ring buffer in
> the xenbus driver was not optimal: it was busy looping and issuing a
> warning in each loop.
>
> - In case of xenstore not running in dom0 but in a stubdom we end up
> with two xenbus threads running as the initialization of xenbus in
> dom0 expecting a local xenstored will be redone later when connecting
> to the xenstore domain. Up to now this was no problem as locking
> would prevent the two xenbus threads interfering with each other, but
> this was just a waste of kernel resources.
>
> - An out of memory situation while writing to or reading from the
> xenstore ring buffer no longer will lead to a possible loss of
> synchronization with xenstore.
>
> - The user read and write part are now interruptible by signals.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> I'm aware that the changes are quite large. I thought about sending a
> version split into multiple patches, but a lot of lines would have been
> touched by more than one patch. I still have the multiple patch variant
> lying around - this patch is split into 11 smaller ones. While all
> steps of this larger series is operational some steps are not optimal
> as they are even slower than the original version of xenbus.
>
> Nevertheless I can send the large series if there are requests for it.
I will comment only on xen_comms changes for now since otherwise I am
afraid it may be difficult to keep track of conversation.
> diff --git a/drivers/xen/xenbus/xenbus_comms.c b/drivers/xen/xenbus/xenbus_comms.c
> index c21ec02..fa054ca 100644
> --- a/drivers/xen/xenbus/xenbus_comms.c
> +++ b/drivers/xen/xenbus/xenbus_comms.c
> @@ -34,6 +34,7 @@
>
> #include <linux/wait.h>
> #include <linux/interrupt.h>
> +#include <linux/kthread.h>
> #include <linux/sched.h>
> #include <linux/err.h>
> #include <xen/xenbus.h>
> @@ -42,11 +43,40 @@
> #include <xen/page.h>
> #include "xenbus.h"
>
> +struct xs_thread_state_write {
> + struct xb_req_data *req;
> + int idx;
> + unsigned int used;
"written" or "sent"?
> +};
> +
> +struct xs_thread_state_read {
> + struct xsd_sockmsg msg;
> + char *body;
> + union {
> + void *alloc;
> + struct xs_watch_event *watch;
> + };
> + bool in_msg;
> + bool in_hdr;
It may be better to keep track of which state we are in using a bitmap.
Otherwise it easy to lose track of one or the other.
> + unsigned int used;
"read" or"received"?
> +};
Both of these are private to process_msg/process_write so perhaps they
can be declared in those routines' scopes.
> +
> +/* A list of replies. Currently only one will ever be outstanding. */
> +LIST_HEAD(xs_reply_list);
> +
> +/* A list of write requests. */
> +LIST_HEAD(xb_write_list);
> +DECLARE_WAIT_QUEUE_HEAD(xb_waitq);
> +DEFINE_MUTEX(xb_write_mutex);
> +
> +/* Protect xenbus reader thread against save/restore. */
> +DEFINE_MUTEX(xs_response_mutex);
> +
> static int xenbus_irq;
> +static struct task_struct *xenbus_task;
>
> static DECLARE_WORK(probe_work, xenbus_probe);
>
> -static DECLARE_WAIT_QUEUE_HEAD(xb_waitq);
>
> static irqreturn_t wake_waiting(int irq, void *unused)
> {
> @@ -84,30 +114,31 @@ static const void *get_input_chunk(XENSTORE_RING_IDX cons,
> return buf + MASK_XENSTORE_IDX(cons);
> }
>
> +static int xb_data_to_write(void)
> +{
> + struct xenstore_domain_interface *intf = xen_store_interface;
> +
> + return (intf->req_prod - intf->req_cons) != XENSTORE_RING_SIZE &&
> + !list_empty(&xb_write_list);
> +}
> +
> /**
> * xb_write - low level write
> * @data: buffer to send
> * @len: length of buffer
> *
> - * Returns 0 on success, error otherwise.
> + * Returns number of bytes written or -err.
> */
> -int xb_write(const void *data, unsigned len)
> +static int xb_write(const void *data, unsigned int len)
> {
> struct xenstore_domain_interface *intf = xen_store_interface;
> XENSTORE_RING_IDX cons, prod;
> - int rc;
> + unsigned int bytes = 0;
>
> while (len != 0) {
> void *dst;
> unsigned int avail;
>
> - rc = wait_event_interruptible(
> - xb_waitq,
> - (intf->req_prod - intf->req_cons) !=
> - XENSTORE_RING_SIZE);
> - if (rc < 0)
> - return rc;
> -
> /* Read indexes, then verify. */
> cons = intf->req_cons;
> prod = intf->req_prod;
> @@ -115,59 +146,57 @@ int xb_write(const void *data, unsigned len)
> intf->req_cons = intf->req_prod = 0;
> return -EIO;
> }
> -
> - dst = get_output_chunk(cons, prod, intf->req, &avail);
> - if (avail == 0)
> - continue;
> - if (avail > len)
> - avail = len;
> + if (!xb_data_to_write())
> + return bytes;
>
> /* Must write data /after/ reading the consumer index. */
> virt_mb();
>
> + dst = get_output_chunk(cons, prod, intf->req, &avail);
> + if (avail == 0)
> + continue;
Should we continue the loop here or return? We are waiting for the
reader to get stuff off the ring.
> + if (avail > len)
> + avail = len;
> +
> memcpy(dst, data, avail);
> data += avail;
> len -= avail;
> + bytes += avail;
>
> /* Other side must not see new producer until data is there. */
> virt_wmb();
> intf->req_prod += avail;
>
> /* Implies mb(): other side will see the updated producer. */
> - notify_remote_via_evtchn(xen_store_evtchn);
> + if (prod <= intf->req_cons)
> + notify_remote_via_evtchn(xen_store_evtchn);
> }
>
> - return 0;
> + return bytes;
> }
>
> -int xb_data_to_read(void)
> +static int xb_data_to_read(void)
> {
> struct xenstore_domain_interface *intf = xen_store_interface;
> return (intf->rsp_cons != intf->rsp_prod);
> }
>
> -int xb_wait_for_data_to_read(void)
> -{
> - return wait_event_interruptible(xb_waitq, xb_data_to_read());
> -}
> -
> -int xb_read(void *data, unsigned len)
> +static int xb_read(void *data, unsigned int len)
> {
> struct xenstore_domain_interface *intf = xen_store_interface;
> XENSTORE_RING_IDX cons, prod;
> - int rc;
> + unsigned int bytes = 0;
>
> while (len != 0) {
> unsigned int avail;
> const char *src;
>
> - rc = xb_wait_for_data_to_read();
> - if (rc < 0)
> - return rc;
> -
> /* Read indexes, then verify. */
> cons = intf->rsp_cons;
> prod = intf->rsp_prod;
> + if (cons == prod)
> + return bytes;
> +
> if (!check_indexes(cons, prod)) {
> intf->rsp_cons = intf->rsp_prod = 0;
> return -EIO;
> @@ -185,17 +214,229 @@ int xb_read(void *data, unsigned len)
> memcpy(data, src, avail);
> data += avail;
> len -= avail;
> + bytes += avail;
>
> /* Other side must not see free space until we've copied out */
> virt_mb();
> intf->rsp_cons += avail;
>
> - pr_debug("Finished read of %i bytes (%i to go)\n", avail, len);
> -
> /* Implies mb(): other side will see the updated consumer. */
> - notify_remote_via_evtchn(xen_store_evtchn);
> + if (intf->rsp_prod - cons >= XENSTORE_RING_SIZE)
> + notify_remote_via_evtchn(xen_store_evtchn);
> }
>
> + return bytes;
> +}
> +
> +static int process_msg(void)
> +{
> + static struct xs_thread_state_read state;
> + struct xb_req_data *req;
> + int err;
> + unsigned int len;
> +
> + if (!state.in_msg) {
> + state.in_msg = true;
> + state.in_hdr = true;
> + state.used = 0;
> +
> + /*
> + * We must disallow save/restore while reading a message.
> + * A partial read across s/r leaves us out of sync with
> + * xenstored.
> + */
> + mutex_lock(&xs_response_mutex);
> +
> + if (!xb_data_to_read()) {
> + /* We raced with save/restore: pending data 'gone'. */
> + mutex_unlock(&xs_response_mutex);
> + state.in_msg = false;
> + return 0;
> + }
> + }
> +
> + if (state.in_hdr) {
> + if (state.used != sizeof(state.msg)) {
> + err = xb_read((void *)&state.msg + state.used,
> + sizeof(state.msg) - state.used);
> + if (err < 0)
> + goto out;
> + state.used += err;
> + if (state.used != sizeof(state.msg))
> + return 0;
Would it be possible to do locking at the caller? I understand that you
are trying to hold the lock across multiple invocations of this function
but it feels somewhat counter-intuitive and bug-prone.
If it's not possible then at least please add a comment explaining
locking algorithm.
> + if (state.msg.len > XENSTORE_PAYLOAD_MAX) {
> + err = -EINVAL;
> + goto out;
> + }
> + }
> +
> + len = state.msg.len + 1;
> + if (state.msg.type == XS_WATCH_EVENT)
> + len += sizeof(*state.watch);
> +
> + state.alloc = kmalloc(len, GFP_NOIO | __GFP_HIGH);
Why can't you kmalloc to state.body only when type!=XS_WATCH_EVENT ?
> + if (!state.alloc)
> + return -ENOMEM;
> +
> + if (state.msg.type == XS_WATCH_EVENT)
> + state.body = state.watch->body;
> + else
> + state.body = state.alloc;
> + state.in_hdr = false;
> + state.used = 0;
> + }
> +
> + err = xb_read(state.body + state.used, state.msg.len - state.used);
> + if (err < 0)
> + goto out;
> +
> + state.used += err;
> + if (state.used != state.msg.len)
> + return 0;
> +
> + state.body[state.msg.len] = '\0';
> +
> + if (state.msg.type == XS_WATCH_EVENT) {
> + state.watch->len = state.msg.len;
> + err = xs_watch_msg(state.watch);
> + } else {
> + err = -ENOENT;
> + mutex_lock(&xb_write_mutex);
> + list_for_each_entry(req, &xs_reply_list, list) {
> + if (req->msg.req_id == state.msg.req_id) {
> + if (req->state == xb_req_state_wait_reply) {
> + req->msg.type = state.msg.type;
> + req->msg.len = state.msg.len;
> + req->body = state.body;
> + req->state = xb_req_state_got_reply;
> + list_del(&req->list);
> + req->cb(req);
> + } else {
> + list_del(&req->list);
> + kfree(req);
> + }
> + err = 0;
> + break;
> + }
> + }
> + mutex_unlock(&xb_write_mutex);
> + if (err)
> + goto out;
> + }
> +
> + mutex_unlock(&xs_response_mutex);
> +
> + state.in_msg = false;
> + state.alloc = NULL;
> + return err;
> +
> + out:
> + mutex_unlock(&xs_response_mutex);
> + state.in_msg = false;
> + kfree(state.alloc);
> + state.alloc = NULL;
> + return err;
> +}
> +
> +static int process_writes(void)
> +{
> + static struct xs_thread_state_write state;
> + void *base;
> + unsigned int len;
> + int err = 0;
> +
> + if (!xb_data_to_write())
> + return 0;
> +
> + mutex_lock(&xb_write_mutex);
> +
> + if (!state.req) {
> + state.req = list_first_entry(&xb_write_list,
> + struct xb_req_data, list);
> + state.idx = -1;
> + state.used = 0;
> + }
> +
> + if (state.req->state == xb_req_state_aborted)
> + goto out_err;
> +
> + while (state.idx < state.req->num_vecs) {
> + if (state.idx < 0) {
> + base = &state.req->msg;
> + len = sizeof(state.req->msg);
> + } else {
> + base = state.req->vec[state.idx].iov_base;
> + len = state.req->vec[state.idx].iov_len;
> + }
> + err = xb_write(base + state.used, len - state.used);
> + if (err < 0)
> + goto out_err;
> + state.used += err;
> + if (state.used != len)
> + goto out;
> +
> + state.idx++;
> + state.used = 0;
> + }
> +
> + /*
> + * You would expect the following to be racy, but as the response is
> + * being read by our thread there is no risk of req being freed
> + * under our feet.
> + */
I don't think I understand this (and it's missing a "so" or something
like that between "thread" and "there"). If this is not racy, why are we
doing this under xb_write_mutex?
> + list_del(&state.req->list);
> + state.req->state = xb_req_state_wait_reply;
> + list_add_tail(&state.req->list, &xs_reply_list);
> + state.req = NULL;
> +
> + out:
> + mutex_unlock(&xb_write_mutex);
> +
> + return 0;
> +
> + out_err:
> + state.req->msg.type = XS_ERROR;
> + state.req->err = err;
You don't seem to need this for xb_req_state_aborted since you are
freeing state_req. OTOH, why shouldn't aborted requests generate an
error reply as well?
> + list_del(&state.req->list);
> + if (state.req->state == xb_req_state_aborted)
> + kfree(state.req);
> + else {
> + state.req->state = xb_req_state_got_reply;
> + wake_up(&state.req->wq);
> + }
> +
> + mutex_unlock(&xb_write_mutex);
> +
> + state.req = NULL;
> +
> + return err;
> +}
> +
> +static int xb_thread_work(void)
> +{
> + return xb_data_to_read() || xb_data_to_write();
> +}
> +
> +static int xenbus_thread(void *unused)
> +{
> + int err;
> +
> + while (!kthread_should_stop()) {
> + if (wait_event_interruptible(xb_waitq, xb_thread_work()))
> + continue;
> +
> + err = process_msg();
> + if (err == -ENOMEM)
> + schedule();
> + else if (err)
> + pr_warn("error %d while reading message\n", err);
> +
> + err = process_writes();
> + if (err)
> + pr_warn("error %d while writing message\n", err);
Is there a chance that errors are persistent and you then spam the log?
-boris
> + }
> +
> + xenbus_task = NULL;
> return 0;
> }
>
> @@ -223,6 +464,7 @@ int xb_init_comms(void)
> rebind_evtchn_irq(xen_store_evtchn, xenbus_irq);
> } else {
> int err;
> +
> err = bind_evtchn_to_irqhandler(xen_store_evtchn, wake_waiting,
> 0, "xenbus", &xb_waitq);
> if (err < 0) {
> @@ -231,6 +473,13 @@ int xb_init_comms(void)
> }
>
> xenbus_irq = err;
> +
> + if (!xenbus_task) {
> + xenbus_task = kthread_run(xenbus_thread, NULL,
> + "xenbus");
> + if (IS_ERR(xenbus_task))
> + return PTR_ERR(xenbus_task);
> + }
> }
>
> return 0;
>
>
>
>
>
[toc] | [prev] | [next] | [standalone]
| From | Juergen Gross <jgross@suse.com> |
|---|---|
| Date | 2017-01-10 07:20 +0100 |
| Subject | Re: [PATCH 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses |
| Message-ID | <sXXWO-6eM-17@gated-at.bofh.it> |
| In reply to | #1554728 |
On 09/01/17 22:17, Boris Ostrovsky wrote:
> On 01/06/2017 10:05 AM, Juergen Gross wrote:
>> Handling of multiple concurrent Xenstore accesses through xenbus driver
>> either from the kernel or user land is rather lame today: xenbus is
>> capable to have one access active only at one point of time.
>>
>> Rewrite xenbus to handle multiple requests concurrently by making use
>> of the request id of the Xenstore protocol. This requires to:
>>
>> - Instead of blocking inside xb_read() when trying to read data from
>> the xenstore ring buffer do so only in the main loop of
>> xenbus_thread().
>>
>> - Instead of doing writes to the xenstore ring buffer in the context of
>> the caller just queue the request and do the write in the dedicated
>> xenbus thread.
>>
>> - Instead of just forwarding the request id specified by the caller of
>> xenbus to xenstore use a xenbus internal unique request id. This will
>> allow multiple outstanding requests.
>>
>> - Modify the locking scheme in order to allow multiple requests being
>> active in parallel.
>>
>> - Instead of waiting for the reply of a user's xenstore request after
>> writing the request to the xenstore ring buffer return directly to
>> the caller and do the waiting in the read path.
>>
>> Additionally signal handling was optimized by avoiding waking up the
>> xenbus thread or sending an event to Xenstore in case the addressed
>> entity is known to be running already.
>>
>> As a result communication with Xenstore is sped up by a factor of up
>> to 5: depending on the request type (read or write) and the amount of
>> data transferred the gain was at least 20% (small reads) and went up to
>> a factor of 5 for large writes.
>>
>> In the end some more rough edges of xenbus have been smoothed:
>>
>> - Handling of memory shortage when reading from xenstore ring buffer in
>> the xenbus driver was not optimal: it was busy looping and issuing a
>> warning in each loop.
>>
>> - In case of xenstore not running in dom0 but in a stubdom we end up
>> with two xenbus threads running as the initialization of xenbus in
>> dom0 expecting a local xenstored will be redone later when connecting
>> to the xenstore domain. Up to now this was no problem as locking
>> would prevent the two xenbus threads interfering with each other, but
>> this was just a waste of kernel resources.
>>
>> - An out of memory situation while writing to or reading from the
>> xenstore ring buffer no longer will lead to a possible loss of
>> synchronization with xenstore.
>>
>> - The user read and write part are now interruptible by signals.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>> I'm aware that the changes are quite large. I thought about sending a
>> version split into multiple patches, but a lot of lines would have been
>> touched by more than one patch. I still have the multiple patch variant
>> lying around - this patch is split into 11 smaller ones. While all
>> steps of this larger series is operational some steps are not optimal
>> as they are even slower than the original version of xenbus.
>>
>> Nevertheless I can send the large series if there are requests for it.
>
> I will comment only on xen_comms changes for now since otherwise I am
> afraid it may be difficult to keep track of conversation.
Okay.
>> diff --git a/drivers/xen/xenbus/xenbus_comms.c b/drivers/xen/xenbus/xenbus_comms.c
>> index c21ec02..fa054ca 100644
>> --- a/drivers/xen/xenbus/xenbus_comms.c
>> +++ b/drivers/xen/xenbus/xenbus_comms.c
>> @@ -34,6 +34,7 @@
>>
>> #include <linux/wait.h>
>> #include <linux/interrupt.h>
>> +#include <linux/kthread.h>
>> #include <linux/sched.h>
>> #include <linux/err.h>
>> #include <xen/xenbus.h>
>> @@ -42,11 +43,40 @@
>> #include <xen/page.h>
>> #include "xenbus.h"
>>
>> +struct xs_thread_state_write {
>> + struct xb_req_data *req;
>> + int idx;
>> + unsigned int used;
>
> "written" or "sent"?
I don't mind.
>> +};
>> +
>> +struct xs_thread_state_read {
>> + struct xsd_sockmsg msg;
>> + char *body;
>> + union {
>> + void *alloc;
>> + struct xs_watch_event *watch;
>> + };
>> + bool in_msg;
>> + bool in_hdr;
>
> It may be better to keep track of which state we are in using a bitmap.
> Otherwise it easy to lose track of one or the other.
Hmm, really? It's rather easy:
in_msg: are we processing any message?
in_hdr: are we processing the message header (in_msg is true)?
>> + unsigned int used;
>
> "read" or"received"?
Sure, can change.
>> +};
>
> Both of these are private to process_msg/process_write so perhaps they
> can be declared in those routines' scopes.
I can do this if you want.
>> /* Read indexes, then verify. */
>> cons = intf->req_cons;
>> prod = intf->req_prod;
>> @@ -115,59 +146,57 @@ int xb_write(const void *data, unsigned len)
>> intf->req_cons = intf->req_prod = 0;
>> return -EIO;
>> }
>> -
>> - dst = get_output_chunk(cons, prod, intf->req, &avail);
>> - if (avail == 0)
>> - continue;
>> - if (avail > len)
>> - avail = len;
>> + if (!xb_data_to_write())
>> + return bytes;
>>
>> /* Must write data /after/ reading the consumer index. */
>> virt_mb();
>>
>> + dst = get_output_chunk(cons, prod, intf->req, &avail);
>> + if (avail == 0)
>> + continue;
>
> Should we continue the loop here or return? We are waiting for the
> reader to get stuff off the ring.
avail == 0 can happen only if the reader just modified req_cons
between us reading it to cons and testing for free space via
xb_data_to_write(). So the (local) retry should happen only very
rarely and exactly once between writing any further bytes. We
could return, of course, but then the retry would happen anyway
via the main thread loop.
>> +static int process_msg(void)
>> +{
>> + static struct xs_thread_state_read state;
>> + struct xb_req_data *req;
>> + int err;
>> + unsigned int len;
>> +
>> + if (!state.in_msg) {
>> + state.in_msg = true;
>> + state.in_hdr = true;
>> + state.used = 0;
>> +
>> + /*
>> + * We must disallow save/restore while reading a message.
>> + * A partial read across s/r leaves us out of sync with
>> + * xenstored.
>> + */
>> + mutex_lock(&xs_response_mutex);
>> +
>> + if (!xb_data_to_read()) {
>> + /* We raced with save/restore: pending data 'gone'. */
>> + mutex_unlock(&xs_response_mutex);
>> + state.in_msg = false;
>> + return 0;
>> + }
>> + }
>> +
>> + if (state.in_hdr) {
>> + if (state.used != sizeof(state.msg)) {
>> + err = xb_read((void *)&state.msg + state.used,
>> + sizeof(state.msg) - state.used);
>> + if (err < 0)
>> + goto out;
>> + state.used += err;
>> + if (state.used != sizeof(state.msg))
>> + return 0;
>
> Would it be possible to do locking at the caller? I understand that you
> are trying to hold the lock across multiple invocations of this function
> but it feels somewhat counter-intuitive and bug-prone.
I think that would be difficult.
> If it's not possible then at least please add a comment explaining
> locking algorithm.
Okay. Something like:
/*
* xs_response_mutex is locked as long as we are processing one
* message. state.in_msg will be true as long as we are holding the
* lock in process_msg().
*/
>> + if (state.msg.len > XENSTORE_PAYLOAD_MAX) {
>> + err = -EINVAL;
>> + goto out;
>> + }
>> + }
>> +
>> + len = state.msg.len + 1;
>> + if (state.msg.type == XS_WATCH_EVENT)
>> + len += sizeof(*state.watch);
>> +
>> + state.alloc = kmalloc(len, GFP_NOIO | __GFP_HIGH);
>
> Why can't you kmalloc to state.body only when type!=XS_WATCH_EVENT ?
I need to read the watch data, too.
>> + if (!state.alloc)
>> + return -ENOMEM;
>> +
>> + if (state.msg.type == XS_WATCH_EVENT)
>> + state.body = state.watch->body;
>> + else
>> + state.body = state.alloc;
>> + state.in_hdr = false;
>> + state.used = 0;
>> + }
>> +static int process_writes(void)
>> +{
>> + static struct xs_thread_state_write state;
>> + void *base;
>> + unsigned int len;
>> + int err = 0;
>> +
>> + if (!xb_data_to_write())
>> + return 0;
>> +
>> + mutex_lock(&xb_write_mutex);
>> +
>> + if (!state.req) {
>> + state.req = list_first_entry(&xb_write_list,
>> + struct xb_req_data, list);
>> + state.idx = -1;
>> + state.used = 0;
>> + }
>> +
>> + if (state.req->state == xb_req_state_aborted)
>> + goto out_err;
>> +
>> + while (state.idx < state.req->num_vecs) {
>> + if (state.idx < 0) {
>> + base = &state.req->msg;
>> + len = sizeof(state.req->msg);
>> + } else {
>> + base = state.req->vec[state.idx].iov_base;
>> + len = state.req->vec[state.idx].iov_len;
>> + }
>> + err = xb_write(base + state.used, len - state.used);
>> + if (err < 0)
>> + goto out_err;
>> + state.used += err;
>> + if (state.used != len)
>> + goto out;
>> +
>> + state.idx++;
>> + state.used = 0;
>> + }
>> +
>> + /*
>> + * You would expect the following to be racy, but as the response is
>> + * being read by our thread there is no risk of req being freed
>> + * under our feet.
>> + */
>
> I don't think I understand this (and it's missing a "so" or something
> like that between "thread" and "there"). If this is not racy, why are we
> doing this under xb_write_mutex?
You are right. This was a problem in an intermediate stage of
development, but now the freeing of req is done with xb_write_mutex
held. I'll remove the comment.
>> + list_del(&state.req->list);
>> + state.req->state = xb_req_state_wait_reply;
>> + list_add_tail(&state.req->list, &xs_reply_list);
>> + state.req = NULL;
>> +
>> + out:
>> + mutex_unlock(&xb_write_mutex);
>> +
>> + return 0;
>> +
>> + out_err:
>> + state.req->msg.type = XS_ERROR;
>> + state.req->err = err;
>
> You don't seem to need this for xb_req_state_aborted since you are
> freeing state_req. OTOH, why shouldn't aborted requests generate an
> error reply as well?
They do. Before setting xb_req_state_aborted a possible error
is taken from req (see xs_wait_for_reply()). In case of an
early error returned (EIO in read_reply()) there is nobody
waiting for (another) response.
>> + list_del(&state.req->list);
>> + if (state.req->state == xb_req_state_aborted)
>> + kfree(state.req);
>> + else {
>> + state.req->state = xb_req_state_got_reply;
>> + wake_up(&state.req->wq);
>> + }
>> +
>> + mutex_unlock(&xb_write_mutex);
>> +
>> + state.req = NULL;
>> +
>> + return err;
>> +}
>> +
>> +static int xb_thread_work(void)
>> +{
>> + return xb_data_to_read() || xb_data_to_write();
>> +}
>> +
>> +static int xenbus_thread(void *unused)
>> +{
>> + int err;
>> +
>> + while (!kthread_should_stop()) {
>> + if (wait_event_interruptible(xb_waitq, xb_thread_work()))
>> + continue;
>> +
>> + err = process_msg();
>> + if (err == -ENOMEM)
>> + schedule();
>> + else if (err)
>> + pr_warn("error %d while reading message\n", err);
>> +
>> + err = process_writes();
>> + if (err)
>> + pr_warn("error %d while writing message\n", err);
>
> Is there a chance that errors are persistent and you then spam the log?
Only in case xenstored is spamming the ring buffer with illegal data.
I believe this is rather improbable and we are doomed in this case
anyway. OTOH it doesn't hurt to switch to pr_warn_ratelimited().
> -boris
Thanks for the comments!
Juergen
[toc] | [prev] | [next] | [standalone]
| From | Boris Ostrovsky <boris.ostrovsky@oracle.com> |
|---|---|
| Date | 2017-01-10 17:40 +0100 |
| Subject | Re: [PATCH 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses |
| Message-ID | <sY7CO-3Fl-13@gated-at.bofh.it> |
| In reply to | #1554977 |
>> /* >> * xs_response_mutex is locked as long as we are processing one >> * message. state.in_msg will be true as long as we are holding the >> * lock in process_msg(). > > Then in_msg is the same as mutex_is_locked(&xs_response_mutex). And if > so, do we really need it? Nevermind this. The lock can be held by others, obviously. -boris
[toc] | [prev] | [next] | [standalone]
| From | Boris Ostrovsky <boris.ostrovsky@oracle.com> |
|---|---|
| Date | 2017-01-10 17:40 +0100 |
| Subject | Re: [PATCH 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses |
| Message-ID | <sY7CO-3Fl-15@gated-at.bofh.it> |
| In reply to | #1554977 |
>>> +static int process_msg(void)
>>> +{
>>> + static struct xs_thread_state_read state;
>>> + struct xb_req_data *req;
>>> + int err;
>>> + unsigned int len;
>>> +
>>> + if (!state.in_msg) {
>>> + state.in_msg = true;
>>> + state.in_hdr = true;
>>> + state.used = 0;
>>> +
>>> + /*
>>> + * We must disallow save/restore while reading a message.
>>> + * A partial read across s/r leaves us out of sync with
>>> + * xenstored.
>>> + */
>>> + mutex_lock(&xs_response_mutex);
>>> +
>>> + if (!xb_data_to_read()) {
>>> + /* We raced with save/restore: pending data 'gone'. */
>>> + mutex_unlock(&xs_response_mutex);
>>> + state.in_msg = false;
Just noticed: should in_hdr be set to false here as well?
>>> + return 0;
>>> + }
Or set it to true here.
>>> + }
>>> +
>>> + if (state.in_hdr) {
>>> + if (state.used != sizeof(state.msg)) {
>>> + err = xb_read((void *)&state.msg + state.used,
>>> + sizeof(state.msg) - state.used);
>>> + if (err < 0)
>>> + goto out;
>>> + state.used += err;
>>> + if (state.used != sizeof(state.msg))
>>> + return 0;
>> Would it be possible to do locking at the caller? I understand that you
>> are trying to hold the lock across multiple invocations of this function
>> but it feels somewhat counter-intuitive and bug-prone.
> I think that would be difficult.
>
>> If it's not possible then at least please add a comment explaining
>> locking algorithm.
> Okay. Something like:
>
> /*
> * xs_response_mutex is locked as long as we are processing one
> * message. state.in_msg will be true as long as we are holding the
> * lock in process_msg().
Then in_msg is the same as mutex_is_locked(&xs_response_mutex). And if
so, do we really need it?
-boris
[toc] | [prev] | [next] | [standalone]
| From | Juergen Gross <jgross@suse.com> |
|---|---|
| Date | 2017-01-10 17:50 +0100 |
| Subject | Re: [PATCH 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses |
| Message-ID | <sY7Mt-3II-27@gated-at.bofh.it> |
| In reply to | #1555684 |
On 10/01/17 17:36, Boris Ostrovsky wrote:
>
>>>> +static int process_msg(void)
>>>> +{
>>>> + static struct xs_thread_state_read state;
>>>> + struct xb_req_data *req;
>>>> + int err;
>>>> + unsigned int len;
>>>> +
>>>> + if (!state.in_msg) {
>>>> + state.in_msg = true;
>>>> + state.in_hdr = true;
>>>> + state.used = 0;
>>>> +
>>>> + /*
>>>> + * We must disallow save/restore while reading a message.
>>>> + * A partial read across s/r leaves us out of sync with
>>>> + * xenstored.
>>>> + */
>>>> + mutex_lock(&xs_response_mutex);
>>>> +
>>>> + if (!xb_data_to_read()) {
>>>> + /* We raced with save/restore: pending data 'gone'. */
>>>> + mutex_unlock(&xs_response_mutex);
>>>> + state.in_msg = false;
>
> Just noticed: should in_hdr be set to false here as well?
Doesn't matter: It is valid only if in_msg is true.
>
>>>> + return 0;
>>>> + }
>
> Or set it to true here.
>
>>>> + }
>>>> +
>>>> + if (state.in_hdr) {
>>>> + if (state.used != sizeof(state.msg)) {
>>>> + err = xb_read((void *)&state.msg + state.used,
>>>> + sizeof(state.msg) - state.used);
>>>> + if (err < 0)
>>>> + goto out;
>>>> + state.used += err;
>>>> + if (state.used != sizeof(state.msg))
>>>> + return 0;
>>> Would it be possible to do locking at the caller? I understand that you
>>> are trying to hold the lock across multiple invocations of this function
>>> but it feels somewhat counter-intuitive and bug-prone.
>> I think that would be difficult.
>>
>>> If it's not possible then at least please add a comment explaining
>>> locking algorithm.
>> Okay. Something like:
>>
>> /*
>> * xs_response_mutex is locked as long as we are processing one
>> * message. state.in_msg will be true as long as we are holding the
>> * lock in process_msg().
>
>
> Then in_msg is the same as mutex_is_locked(&xs_response_mutex). And if
> so, do we really need it?
Yes. xs_response_mutex is used in suspend path, too.
Juergen
[toc] | [prev] | [next] | [standalone]
| From | Boris Ostrovsky <boris.ostrovsky@oracle.com> |
|---|---|
| Date | 2017-01-10 20:20 +0100 |
| Subject | Re: [PATCH 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses |
| Message-ID | <sYa7D-5fe-11@gated-at.bofh.it> |
| In reply to | #1552865 |
> diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c b/drivers/xen/xenbus/xenbus_dev_frontend.c > index e4b9847..4d343ee 100644 > --- a/drivers/xen/xenbus/xenbus_dev_frontend.c > +++ b/drivers/xen/xenbus/xenbus_dev_frontend.c > LGTM. -boris
[toc] | [prev] | [next] | [standalone]
| From | Boris Ostrovsky <boris.ostrovsky@oracle.com> |
|---|---|
| Date | 2017-01-11 00:00 +0100 |
| Subject | Re: [PATCH 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses |
| Message-ID | <sYdyy-7hm-29@gated-at.bofh.it> |
| In reply to | #1552865 |
> diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
> index ebc768f..ebdfbee 100644
> --- a/drivers/xen/xenbus/xenbus_xs.c
> +++ b/drivers/xen/xenbus/xenbus_xs.c
> -
> -static struct xs_handle xs_state;
> +/*
> + * Framework to protect suspend/resume handling against normal Xenstore
> + * message handling:
> + * During suspend/resume there must be no open transaction and no pending
> + * Xenstore request.
> + * New watch events happening in this time can be ignored by firing all watches
> + * after resume.
> + */
> +/* Lock protecting enter/exit critical region. */
> +static DEFINE_SPINLOCK(xs_state_lock);
> +/* Wait queue for all callers waiting for critical region to become usable. */
> +static DECLARE_WAIT_QUEUE_HEAD(xs_state_enter_wq);
> +/* Wait queue for suspend handling waiting for critical region being empty. */
> +static DECLARE_WAIT_QUEUE_HEAD(xs_state_exit_wq);
> +/* Number of users in critical region. */
> +static unsigned int xs_state_users;
> +/* Suspend handler waiting or already active? */
> +static int xs_suspend_active;
I think these two should be declared next to xs_state _lock since they
are protected by it. Or maybe even put them into some sort of a state
struct.
> +
> +
> +static bool test_reply(struct xb_req_data *req)
> +{
> + if (req->state == xb_req_state_got_reply || !xenbus_ok())
> + return true;
> +
> + /* Make sure to reread req->state each time. */
> + cpu_relax();
I don't think I understand why this is needed.
> +
> + return false;
> +}
> +
> +static void xs_send(struct xb_req_data *req, struct xsd_sockmsg *msg)
> {
> - mutex_lock(&xs_state.transaction_mutex);
> - atomic_inc(&xs_state.transaction_count);
> - mutex_unlock(&xs_state.transaction_mutex);
> -}
> + bool notify;
>
> -static void transaction_end(void)
> -{
> - if (atomic_dec_and_test(&xs_state.transaction_count))
> - wake_up(&xs_state.transaction_wq);
> -}
> + req->msg = *msg;
> + req->err = 0;
> + req->state = xb_req_state_queued;
> + init_waitqueue_head(&req->wq);
>
> -static void transaction_suspend(void)
> -{
> - mutex_lock(&xs_state.transaction_mutex);
> - wait_event(xs_state.transaction_wq,
> - atomic_read(&xs_state.transaction_count) == 0);
> -}
> + xs_request_enter(req);
>
> -static void transaction_resume(void)
> -{
> - mutex_unlock(&xs_state.transaction_mutex);
> + req->msg.req_id = xs_request_id++;
Is it safe to do this without a lock?
> +
> +int xenbus_dev_request_and_reply(struct xsd_sockmsg *msg, void *par)
> +{
> + struct xb_req_data *req;
> + struct kvec *vec;
> +
> + req = kmalloc(sizeof(*req) + sizeof(*vec), GFP_KERNEL);
Is there a reason why you are using different flags here?
> @@ -263,11 +295,20 @@ static void *xs_talkv(struct xenbus_transaction t,
> unsigned int num_vecs,
> unsigned int *len)
> {
> + struct xb_req_data *req;
> struct xsd_sockmsg msg;
> void *ret = NULL;
> unsigned int i;
> int err;
>
> + req = kmalloc(sizeof(*req), GFP_NOIO | __GFP_HIGH);
> + if (!req)
> + return ERR_PTR(-ENOMEM);
> +
> + req->vec = iovec;
> + req->num_vecs = num_vecs;
> + req->cb = xs_wake_up;
> +
> msg.tx_id = t.id;
> msg.req_id = 0;
Is this still needed? You are assigning it in xs_send().
> +static int xs_reboot_notify(struct notifier_block *nb,
> + unsigned long code, void *unused)
> {
> - struct xs_stored_msg *msg;
> + struct xb_req_data *req;
> +
> + mutex_lock(&xb_write_mutex);
> + list_for_each_entry(req, &xs_reply_list, list)
> + wake_up(&req->wq);
> + list_for_each_entry(req, &xb_write_list, list)
> + wake_up(&req->wq);
We are waking up waiters here but there is not guarantee that waiting
threads will have a chance to run, is there?
-boris
[toc] | [prev] | [next] | [standalone]
| From | Juergen Gross <jgross@suse.com> |
|---|---|
| Date | 2017-01-11 06:30 +0100 |
| Subject | Re: [PATCH 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses |
| Message-ID | <sYjDX-2Is-5@gated-at.bofh.it> |
| In reply to | #1555987 |
On 10/01/17 23:56, Boris Ostrovsky wrote:
>
>
>
>> diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
>> index ebc768f..ebdfbee 100644
>> --- a/drivers/xen/xenbus/xenbus_xs.c
>> +++ b/drivers/xen/xenbus/xenbus_xs.c
>
>
>> -
>> -static struct xs_handle xs_state;
>> +/*
>> + * Framework to protect suspend/resume handling against normal Xenstore
>> + * message handling:
>> + * During suspend/resume there must be no open transaction and no pending
>> + * Xenstore request.
>> + * New watch events happening in this time can be ignored by firing all watches
>> + * after resume.
>> + */
>> +/* Lock protecting enter/exit critical region. */
>> +static DEFINE_SPINLOCK(xs_state_lock);
>> +/* Wait queue for all callers waiting for critical region to become usable. */
>> +static DECLARE_WAIT_QUEUE_HEAD(xs_state_enter_wq);
>> +/* Wait queue for suspend handling waiting for critical region being empty. */
>> +static DECLARE_WAIT_QUEUE_HEAD(xs_state_exit_wq);
>> +/* Number of users in critical region. */
>> +static unsigned int xs_state_users;
>> +/* Suspend handler waiting or already active? */
>> +static int xs_suspend_active;
>
> I think these two should be declared next to xs_state _lock since they
> are protected by it. Or maybe even put them into some sort of a state
> struct.
I think placing them near the lock and adding a comment is enough.
>> +
>> +
>> +static bool test_reply(struct xb_req_data *req)
>> +{
>> + if (req->state == xb_req_state_got_reply || !xenbus_ok())
>> + return true;
>> +
>> + /* Make sure to reread req->state each time. */
>> + cpu_relax();
>
> I don't think I understand why this is needed.
I need a compiler barrier. Otherwise the compiler read req->state only
once outside the while loop.
>> +
>> + return false;
>> +}
>> +
>
>
>> +static void xs_send(struct xb_req_data *req, struct xsd_sockmsg *msg)
>> {
>> - mutex_lock(&xs_state.transaction_mutex);
>> - atomic_inc(&xs_state.transaction_count);
>> - mutex_unlock(&xs_state.transaction_mutex);
>> -}
>> + bool notify;
>>
>> -static void transaction_end(void)
>> -{
>> - if (atomic_dec_and_test(&xs_state.transaction_count))
>> - wake_up(&xs_state.transaction_wq);
>> -}
>> + req->msg = *msg;
>> + req->err = 0;
>> + req->state = xb_req_state_queued;
>> + init_waitqueue_head(&req->wq);
>>
>> -static void transaction_suspend(void)
>> -{
>> - mutex_lock(&xs_state.transaction_mutex);
>> - wait_event(xs_state.transaction_wq,
>> - atomic_read(&xs_state.transaction_count) == 0);
>> -}
>> + xs_request_enter(req);
>>
>> -static void transaction_resume(void)
>> -{
>> - mutex_unlock(&xs_state.transaction_mutex);
>> + req->msg.req_id = xs_request_id++;
>
> Is it safe to do this without a lock?
You are right: I should move this to xs_request_enter() inside the
lock. I think I'll let return xs_request_enter() the request id.
>> +
>> +int xenbus_dev_request_and_reply(struct xsd_sockmsg *msg, void *par)
>> +{
>> + struct xb_req_data *req;
>> + struct kvec *vec;
>> +
>> + req = kmalloc(sizeof(*req) + sizeof(*vec), GFP_KERNEL);
>
> Is there a reason why you are using different flags here?
Yes. This function is always called in user context. No need to be
more restrictive.
>> @@ -263,11 +295,20 @@ static void *xs_talkv(struct xenbus_transaction t,
>> unsigned int num_vecs,
>> unsigned int *len)
>> {
>> + struct xb_req_data *req;
>> struct xsd_sockmsg msg;
>> void *ret = NULL;
>> unsigned int i;
>> int err;
>>
>> + req = kmalloc(sizeof(*req), GFP_NOIO | __GFP_HIGH);
>> + if (!req)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + req->vec = iovec;
>> + req->num_vecs = num_vecs;
>> + req->cb = xs_wake_up;
>> +
>> msg.tx_id = t.id;
>> msg.req_id = 0;
>
> Is this still needed? You are assigning it in xs_send().
Right. Can be removed.
>> +static int xs_reboot_notify(struct notifier_block *nb,
>> + unsigned long code, void *unused)
>> {
>> - struct xs_stored_msg *msg;
>
>
>
>> + struct xb_req_data *req;
>> +
>> + mutex_lock(&xb_write_mutex);
>> + list_for_each_entry(req, &xs_reply_list, list)
>> + wake_up(&req->wq);
>> + list_for_each_entry(req, &xb_write_list, list)
>> + wake_up(&req->wq);
>
> We are waking up waiters here but there is not guarantee that waiting
> threads will have a chance to run, is there?
You are right. But this isn't the point. We want to avoid blocking a
reboot due to some needed thread waiting for xenstore. And this task
is being accomplished here.
Juergen
[toc] | [prev] | [next] | [standalone]
| From | Boris Ostrovsky <boris.ostrovsky@oracle.com> |
|---|---|
| Date | 2017-01-11 16:40 +0100 |
| Subject | Re: [PATCH 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses |
| Message-ID | <sYtah-an-9@gated-at.bofh.it> |
| In reply to | #1556211 |
>>> +
>>> +
>>> +static bool test_reply(struct xb_req_data *req)
>>> +{
>>> + if (req->state == xb_req_state_got_reply || !xenbus_ok())
>>> + return true;
>>> +
>>> + /* Make sure to reread req->state each time. */
>>> + cpu_relax();
>> I don't think I understand why this is needed.
> I need a compiler barrier. Otherwise the compiler read req->state only
> once outside the while loop.
Then barrier() looks the right primitive to use here. cpu_relax(), while
doing what you want, is intended for other purposes.
>
>>> +
>>> + return false;
>>> +}
>>> +
>>
>>> +static void xs_send(struct xb_req_data *req, struct xsd_sockmsg *msg)
>>> {
>>> - mutex_lock(&xs_state.transaction_mutex);
>>> - atomic_inc(&xs_state.transaction_count);
>>> - mutex_unlock(&xs_state.transaction_mutex);
>>> -}
>>> + bool notify;
>>>
>>> -static void transaction_end(void)
>>> -{
>>> - if (atomic_dec_and_test(&xs_state.transaction_count))
>>> - wake_up(&xs_state.transaction_wq);
>>> -}
>>> + req->msg = *msg;
>>> + req->err = 0;
>>> + req->state = xb_req_state_queued;
>>> + init_waitqueue_head(&req->wq);
>>>
>>> -static void transaction_suspend(void)
>>> -{
>>> - mutex_lock(&xs_state.transaction_mutex);
>>> - wait_event(xs_state.transaction_wq,
>>> - atomic_read(&xs_state.transaction_count) == 0);
>>> -}
>>> + xs_request_enter(req);
>>>
>>> -static void transaction_resume(void)
>>> -{
>>> - mutex_unlock(&xs_state.transaction_mutex);
>>> + req->msg.req_id = xs_request_id++;
>> Is it safe to do this without a lock?
> You are right: I should move this to xs_request_enter() inside the
> lock. I think I'll let return xs_request_enter() the request id.
Then please move xs_request_id's declaration close to xs_state_lock's
declaration (just like you are going to move the two other state variables)
>
>>> +static int xs_reboot_notify(struct notifier_block *nb,
>>> + unsigned long code, void *unused)
>>> {
>>> - struct xs_stored_msg *msg;
>>
>>
>>> + struct xb_req_data *req;
>>> +
>>> + mutex_lock(&xb_write_mutex);
>>> + list_for_each_entry(req, &xs_reply_list, list)
>>> + wake_up(&req->wq);
>>> + list_for_each_entry(req, &xb_write_list, list)
>>> + wake_up(&req->wq);
>> We are waking up waiters here but there is not guarantee that waiting
>> threads will have a chance to run, is there?
> You are right. But this isn't the point. We want to avoid blocking a
> reboot due to some needed thread waiting for xenstore. And this task
> is being accomplished here.
I think it's worth adding a comment mentioning this.
-boris
[toc] | [prev] | [next] | [standalone]
| From | Juergen Gross <jgross@suse.com> |
|---|---|
| Date | 2017-01-11 18:00 +0100 |
| Subject | Re: [PATCH 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses |
| Message-ID | <sYupI-Sq-33@gated-at.bofh.it> |
| In reply to | #1556628 |
On 11/01/17 16:29, Boris Ostrovsky wrote:
>
>>>> +
>>>> +
>>>> +static bool test_reply(struct xb_req_data *req)
>>>> +{
>>>> + if (req->state == xb_req_state_got_reply || !xenbus_ok())
>>>> + return true;
>>>> +
>>>> + /* Make sure to reread req->state each time. */
>>>> + cpu_relax();
>>> I don't think I understand why this is needed.
>> I need a compiler barrier. Otherwise the compiler read req->state only
>> once outside the while loop.
>
>
> Then barrier() looks the right primitive to use here. cpu_relax(), while
> doing what you want, is intended for other purposes.
Hmm, yes, this sounds better.
>>
>>>> +
>>>> + return false;
>>>> +}
>>>> +
>>>
>>>> +static void xs_send(struct xb_req_data *req, struct xsd_sockmsg *msg)
>>>> {
>>>> - mutex_lock(&xs_state.transaction_mutex);
>>>> - atomic_inc(&xs_state.transaction_count);
>>>> - mutex_unlock(&xs_state.transaction_mutex);
>>>> -}
>>>> + bool notify;
>>>>
>>>> -static void transaction_end(void)
>>>> -{
>>>> - if (atomic_dec_and_test(&xs_state.transaction_count))
>>>> - wake_up(&xs_state.transaction_wq);
>>>> -}
>>>> + req->msg = *msg;
>>>> + req->err = 0;
>>>> + req->state = xb_req_state_queued;
>>>> + init_waitqueue_head(&req->wq);
>>>>
>>>> -static void transaction_suspend(void)
>>>> -{
>>>> - mutex_lock(&xs_state.transaction_mutex);
>>>> - wait_event(xs_state.transaction_wq,
>>>> - atomic_read(&xs_state.transaction_count) == 0);
>>>> -}
>>>> + xs_request_enter(req);
>>>>
>>>> -static void transaction_resume(void)
>>>> -{
>>>> - mutex_unlock(&xs_state.transaction_mutex);
>>>> + req->msg.req_id = xs_request_id++;
>>> Is it safe to do this without a lock?
>> You are right: I should move this to xs_request_enter() inside the
>> lock. I think I'll let return xs_request_enter() the request id.
>
>
> Then please move xs_request_id's declaration close to xs_state_lock's
> declaration (just like you are going to move the two other state variables)
Already done. :-)
>>
>>>> +static int xs_reboot_notify(struct notifier_block *nb,
>>>> + unsigned long code, void *unused)
>>>> {
>>>> - struct xs_stored_msg *msg;
>>>
>>>
>>>> + struct xb_req_data *req;
>>>> +
>>>> + mutex_lock(&xb_write_mutex);
>>>> + list_for_each_entry(req, &xs_reply_list, list)
>>>> + wake_up(&req->wq);
>>>> + list_for_each_entry(req, &xb_write_list, list)
>>>> + wake_up(&req->wq);
>>> We are waking up waiters here but there is not guarantee that waiting
>>> threads will have a chance to run, is there?
>> You are right. But this isn't the point. We want to avoid blocking a
>> reboot due to some needed thread waiting for xenstore. And this task
>> is being accomplished here.
>
>
> I think it's worth adding a comment mentioning this.
Okay.
Juergen
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web