From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xen.org
Cc: linux-kernel@vger.kernel.org, jgross@suse.com,
Stefano Stabellini <stefano@aporeto.com>
Subject: Re: [PATCH v5 08/13] xen/pvcalls: implement accept command
Date: Tue, 17 Oct 2017 14:34:17 -0400 [thread overview]
Message-ID: <eed60ea1-1dcc-c942-ccd6-7c9d46415bd6@oracle.com> (raw)
In-Reply-To: <1507336227-20477-8-git-send-email-sstabellini@kernel.org>
On 10/06/2017 08:30 PM, Stefano Stabellini wrote:
> Introduce a waitqueue to allow only one outstanding accept command at
> any given time and to implement polling on the passive socket. Introduce
> a flags field to keep track of in-flight accept and poll commands.
>
> Send PVCALLS_ACCEPT to the backend. Allocate a new active socket. Make
> sure that only one accept command is executed at any given time by
> setting PVCALLS_FLAG_ACCEPT_INFLIGHT and waiting on the
> inflight_accept_req waitqueue.
>
> Convert the new struct sock_mapping pointer into an uint64_t and use it
> as id for the new socket to pass to the backend.
>
> Check if the accept call is non-blocking: in that case after sending the
> ACCEPT command to the backend store the sock_mapping pointer of the new
> struct and the inflight req_id then return -EAGAIN (which will respond
> only when there is something to accept). Next time accept is called,
> we'll check if the ACCEPT command has been answered, if so we'll pick up
> where we left off, otherwise we return -EAGAIN again.
>
> Note that, differently from the other commands, we can use
> wait_event_interruptible (instead of wait_event) in the case of accept
> as we are able to track the req_id of the ACCEPT response that we are
> waiting.
>
> Signed-off-by: Stefano Stabellini <stefano@aporeto.com>
> CC: boris.ostrovsky@oracle.com
> CC: jgross@suse.com
> ---
> drivers/xen/pvcalls-front.c | 146 ++++++++++++++++++++++++++++++++++++++++++++
> drivers/xen/pvcalls-front.h | 3 +
> 2 files changed, 149 insertions(+)
>
> diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
> index 5433fae..8958e74 100644
> --- a/drivers/xen/pvcalls-front.c
> +++ b/drivers/xen/pvcalls-front.c
> @@ -77,6 +77,16 @@ struct sock_mapping {
> #define PVCALLS_STATUS_BIND 1
> #define PVCALLS_STATUS_LISTEN 2
> uint8_t status;
> + /*
> + * Internal state-machine flags.
> + * Only one accept operation can be inflight for a socket.
> + * Only one poll operation can be inflight for a given socket.
> + */
> +#define PVCALLS_FLAG_ACCEPT_INFLIGHT 0
> + uint8_t flags;
> + uint32_t inflight_req_id;
> + struct sock_mapping *accept_map;
> + wait_queue_head_t inflight_accept_req;
> } passive;
> };
> };
> @@ -392,6 +402,8 @@ int pvcalls_front_bind(struct socket *sock, struct sockaddr *addr, int addr_len)
> memcpy(req->u.bind.addr, addr, sizeof(*addr));
> req->u.bind.len = addr_len;
>
> + init_waitqueue_head(&map->passive.inflight_accept_req);
> +
> map->active_socket = false;
>
> bedata->ring.req_prod_pvt++;
> @@ -470,6 +482,140 @@ int pvcalls_front_listen(struct socket *sock, int backlog)
> return ret;
> }
>
> +int pvcalls_front_accept(struct socket *sock, struct socket *newsock, int flags)
> +{
> + struct pvcalls_bedata *bedata;
> + struct sock_mapping *map;
> + struct sock_mapping *map2 = NULL;
> + struct xen_pvcalls_request *req;
> + int notify, req_id, ret, evtchn, nonblock;
> +
> + pvcalls_enter();
> + if (!pvcalls_front_dev) {
> + pvcalls_exit();
> + return -ENOTCONN;
> + }
> + bedata = dev_get_drvdata(&pvcalls_front_dev->dev);
> +
> + map = (struct sock_mapping *) sock->sk->sk_send_head;
> + if (!map) {
> + pvcalls_exit();
> + return -ENOTSOCK;
> + }
> +
> + if (map->passive.status != PVCALLS_STATUS_LISTEN) {
> + pvcalls_exit();
> + return -EINVAL;
> + }
> +
> + nonblock = flags & SOCK_NONBLOCK;
> + /*
> + * Backend only supports 1 inflight accept request, will return
> + * errors for the others
> + */
> + if (test_and_set_bit(PVCALLS_FLAG_ACCEPT_INFLIGHT,
> + (void *)&map->passive.flags)) {
> + req_id = READ_ONCE(map->passive.inflight_req_id);
> + if (req_id != PVCALLS_INVALID_ID &&
> + READ_ONCE(bedata->rsp[req_id].req_id) == req_id) {
READ_ONCE (especially the second one)? I know I may sound fixated on
this but I really don't understand how compiler may do anything wrong if
straight reads were used.
For the first case, I guess, theoretically the compiler may decide to
re-fetch map->passive.inflight_req_id. But even if it did, would that be
a problem? Both of these READ_ONCE targets are updated below before
PVCALLS_FLAG_ACCEPT_INFLIGHT is cleared so there should not be any
change between re-fetching, I think. (The only exception is the noblock
case, which does WRITE_ONCE that don't understand either)
> + map2 = map->passive.accept_map;
> + goto received;
> + }
> + if (nonblock) {
> + pvcalls_exit();
> + return -EAGAIN;
> + }
> + if (wait_event_interruptible(map->passive.inflight_accept_req,
> + !test_and_set_bit(PVCALLS_FLAG_ACCEPT_INFLIGHT,
> + (void *)&map->passive.flags))) {
> + pvcalls_exit();
> + return -EINTR;
> + }
> + }
> +
> + spin_lock(&bedata->socket_lock);
> + ret = get_request(bedata, &req_id);
> + if (ret < 0) {
> + clear_bit(PVCALLS_FLAG_ACCEPT_INFLIGHT,
> + (void *)&map->passive.flags);
> + spin_unlock(&bedata->socket_lock);
> + pvcalls_exit();
> + return ret;
> + }
> + map2 = kzalloc(sizeof(*map2), GFP_KERNEL);
> + if (map2 == NULL) {
> + clear_bit(PVCALLS_FLAG_ACCEPT_INFLIGHT,
> + (void *)&map->passive.flags);
> + spin_unlock(&bedata->socket_lock);
> + pvcalls_exit();
> + return -ENOMEM;
> + }
> + ret = create_active(map2, &evtchn);
> + if (ret < 0) {
> + kfree(map2);
> + clear_bit(PVCALLS_FLAG_ACCEPT_INFLIGHT,
> + (void *)&map->passive.flags);
> + spin_unlock(&bedata->socket_lock);
> + pvcalls_exit();
> + return -ENOMEM;
Why not ret?
-boris
> + }
> + list_add_tail(&map2->list, &bedata->socket_mappings);
> +
> + req = RING_GET_REQUEST(&bedata->ring, req_id);
> + req->req_id = req_id;
> + req->cmd = PVCALLS_ACCEPT;
> + req->u.accept.id = (uint64_t) map;
> + req->u.accept.ref = map2->active.ref;
> + req->u.accept.id_new = (uint64_t) map2;
> + req->u.accept.evtchn = evtchn;
> + map->passive.accept_map = map2;
> +
> + bedata->ring.req_prod_pvt++;
> + RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(&bedata->ring, notify);
> + spin_unlock(&bedata->socket_lock);
> + if (notify)
> + notify_remote_via_irq(bedata->irq);
> + /* We could check if we have received a response before returning. */
> + if (nonblock) {
> + WRITE_ONCE(map->passive.inflight_req_id, req_id);
> + pvcalls_exit();
> + return -EAGAIN;
> + }
> +
> + if (wait_event_interruptible(bedata->inflight_req,
> + READ_ONCE(bedata->rsp[req_id].req_id) == req_id)) {
> + pvcalls_exit();
> + return -EINTR;
> + }
> + /* read req_id, then the content */
> + smp_rmb();
> +
> +received:
> + map2->sock = newsock;
> + newsock->sk = kzalloc(sizeof(*newsock->sk), GFP_KERNEL);
> + if (!newsock->sk) {
> + bedata->rsp[req_id].req_id = PVCALLS_INVALID_ID;
> + map->passive.inflight_req_id = PVCALLS_INVALID_ID;
> + clear_bit(PVCALLS_FLAG_ACCEPT_INFLIGHT,
> + (void *)&map->passive.flags);
> + pvcalls_front_free_map(bedata, map2);
> + kfree(map2);
> + pvcalls_exit();
> + return -ENOMEM;
> + }
> + newsock->sk->sk_send_head = (void *)map2;
> +
> + ret = bedata->rsp[req_id].ret;
> + bedata->rsp[req_id].req_id = PVCALLS_INVALID_ID;
> + map->passive.inflight_req_id = PVCALLS_INVALID_ID;
> +
> + clear_bit(PVCALLS_FLAG_ACCEPT_INFLIGHT, (void *)&map->passive.flags);
> + wake_up(&map->passive.inflight_accept_req);
> +
> + pvcalls_exit();
> + return ret;
> +}
> +
> static const struct xenbus_device_id pvcalls_front_ids[] = {
> { "pvcalls" },
> { "" }
> diff --git a/drivers/xen/pvcalls-front.h b/drivers/xen/pvcalls-front.h
> index aa8fe10..ab4f1da 100644
> --- a/drivers/xen/pvcalls-front.h
> +++ b/drivers/xen/pvcalls-front.h
> @@ -10,5 +10,8 @@ int pvcalls_front_bind(struct socket *sock,
> struct sockaddr *addr,
> int addr_len);
> int pvcalls_front_listen(struct socket *sock, int backlog);
> +int pvcalls_front_accept(struct socket *sock,
> + struct socket *newsock,
> + int flags);
>
> #endif
>
next prev parent reply other threads:[~2017-10-17 18:32 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-07 0:30 [PATCH v5 00/13] introduce the Xen PV Calls frontend:wq Stefano Stabellini
2017-10-07 0:30 ` [PATCH v5 01/13] xen/pvcalls: introduce the pvcalls xenbus frontend Stefano Stabellini
2017-10-07 0:30 ` [PATCH v5 02/13] xen/pvcalls: implement frontend disconnect Stefano Stabellini
2017-10-17 16:01 ` Boris Ostrovsky
2017-10-23 22:44 ` Stefano Stabellini
2017-10-07 0:30 ` [PATCH v5 03/13] xen/pvcalls: connect to the backend Stefano Stabellini
2017-10-07 0:30 ` [PATCH v5 04/13] xen/pvcalls: implement socket command and handle events Stefano Stabellini
2017-10-17 16:59 ` Boris Ostrovsky
2017-10-20 1:26 ` Stefano Stabellini
2017-10-20 14:24 ` Boris Ostrovsky
2017-10-07 0:30 ` [PATCH v5 05/13] xen/pvcalls: implement connect command Stefano Stabellini
2017-10-07 0:30 ` [PATCH v5 06/13] xen/pvcalls: implement bind command Stefano Stabellini
2017-10-17 17:39 ` Boris Ostrovsky
2017-10-20 1:31 ` Stefano Stabellini
2017-10-20 14:40 ` Boris Ostrovsky
2017-10-07 0:30 ` [PATCH v5 07/13] xen/pvcalls: implement listen command Stefano Stabellini
2017-10-07 0:30 ` [PATCH v5 08/13] xen/pvcalls: implement accept command Stefano Stabellini
2017-10-17 18:34 ` Boris Ostrovsky [this message]
2017-10-23 23:03 ` Stefano Stabellini
2017-10-24 13:52 ` Boris Ostrovsky
2017-10-24 16:42 ` Stefano Stabellini
2017-10-07 0:30 ` [PATCH v5 09/13] xen/pvcalls: implement sendmsg Stefano Stabellini
2017-10-17 21:06 ` Boris Ostrovsky
2017-10-20 1:41 ` Stefano Stabellini
2017-10-20 14:44 ` Boris Ostrovsky
2017-10-07 0:30 ` [PATCH v5 10/13] xen/pvcalls: implement recvmsg Stefano Stabellini
2017-10-17 21:35 ` Boris Ostrovsky
2017-10-20 1:38 ` Stefano Stabellini
2017-10-20 14:43 ` Boris Ostrovsky
2017-10-07 0:30 ` [PATCH v5 11/13] xen/pvcalls: implement poll command Stefano Stabellini
2017-10-17 22:15 ` Boris Ostrovsky
2017-10-23 23:06 ` Stefano Stabellini
2017-10-24 14:02 ` Boris Ostrovsky
2017-10-07 0:30 ` [PATCH v5 12/13] xen/pvcalls: implement release command Stefano Stabellini
2017-10-24 14:17 ` Boris Ostrovsky
2017-10-24 17:17 ` Stefano Stabellini
2017-10-07 0:30 ` [PATCH v5 13/13] xen: introduce a Kconfig option to enable the pvcalls frontend Stefano Stabellini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=eed60ea1-1dcc-c942-ccd6-7c9d46415bd6@oracle.com \
--to=boris.ostrovsky@oracle.com \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sstabellini@kernel.org \
--cc=stefano@aporeto.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®