xenbus: track caller request id

Commit fd8aa9095a95 ("xen: optimize xenbus driver for multiple concurrent xenstore accesses") optimized xenbus concurrent accesses but in doing so broke UABI of /dev/xen/xenbus. Through /dev/xen/xenbus applications are in charge of xenbus message exchange with the correct header and body. Now, after the mentioned commit the replies received by application will no longer have the header req_id echoed back as it was on request (see specification below for reference), because that particular field is being overwritten by kernel. struct xsd_sockmsg { uint32_t type; /* XS_??? */ uint32_t req_id;/* Request identifier, echoed in daemon's response. */ uint32_t tx_id; /* Transaction id (0 if not related to a transaction). */ uint32_t len; /* Length of data following this. */ /* Generally followed by nul-terminated string(s). */ }; Before there was only one request at a time so req_id could simply be forwarded back and forth. To allow simultaneous requests we need a different req_id for each message thus kernel keeps a monotonic increasing counter for this field and is written on every request irrespective of userspace value. Forwarding again the req_id on userspace requests is not a solution because we would open the possibility of userspace-generated req_id colliding with kernel ones. So this patch instead takes another route which is to artificially keep user req_id while keeping the xenbus logic as is. We do that by saving the original req_id before xs_send(), use the private kernel counter as req_id and then once reply comes and was validated, we restore back the original req_id.

Joao Martins committed 8 years ago

Commit 29fee6e1 parent 1e3510b3 files · +5 −0Browse files

Unified · Split

3 files

drivers/xen/xenbus/xenbus.h +1 −0
drivers/xen/xenbus/xenbus_comms.c +1 −0
drivers/xen/xenbus/xenbus_xs.c +3 −0

drivers/xen/xenbus/xenbus.h+1−0

@@ -76,6 +76,7 @@ struct xb_req_data { · 75 unmodified lines
76	76	struct list_head list;
77	77	wait_queue_head_t wq;
78	78	struct xsd_sockmsg msg;
	79	+ uint32_t caller_req_id;
79	80	enum xsd_sockmsg_type type;
80	81	char *body;
81	82	const struct kvec *vec;

drivers/xen/xenbus/xenbus_comms.c+1−0

@@ -309,6 +309,7 @@ static int process_msg(void) · 308 unmodified lines
309	309	goto out;
310	310
311	311	if (req->state == xb_req_state_wait_reply) {
	312	+ req->msg.req_id = req->caller_req_id;
312	313	req->msg.type = state.msg.type;
313	314	req->msg.len = state.msg.len;
314	315	req->body = state.body;

drivers/xen/xenbus/xenbus_xs.c+3−0

@@ -227,6 +227,8 @@ static void xs_send(struct xb_req_data req, struct xsd_sockmsg msg) · 226 unmodified lines
227	227	req->state = xb_req_state_queued;
228	228	init_waitqueue_head(&req->wq);
229	229
	230	+ /* Save the caller req_id and restore it later in the reply */
	231	+ req->caller_req_id = req->msg.req_id;
230	232	req->msg.req_id = xs_request_enter(req);
231	233
232	234	mutex_lock(&xb_write_mutex);
@@ -310,6 +312,7 @@ static void *xs_talkv(struct xenbus_transaction t, · 77 unmodified lines
310	312	req->num_vecs = num_vecs;
311	313	req->cb = xs_wake_up;
312	314
	315	+ msg.req_id = 0;
313	316	msg.tx_id = t.id;
314	317	msg.type = type;
315	318	msg.len = 0;