Re: [PATCH v5 10/13] xen/pvcalls: implement recvmsg

[Boris Ostrovsky]

> +
> +int pvcalls_front_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
> +		     int flags)
> +{
> +	struct pvcalls_bedata *bedata;
> +	int ret;
> +	struct sock_mapping *map;
> +
> +	if (flags & (MSG_CMSG_CLOEXEC|MSG_ERRQUEUE|MSG_OOB|MSG_TRUNC))
> +		return -EOPNOTSUPP;
> +
> +	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;
> +	}
> +
> +	mutex_lock(&map->active.in_mutex);
> +	if (len > XEN_FLEX_RING_SIZE(PVCALLS_RING_ORDER))
> +		len = XEN_FLEX_RING_SIZE(PVCALLS_RING_ORDER);
> +
> +	while (!(flags & MSG_DONTWAIT) && !pvcalls_front_read_todo(map)) {
> +		wait_event_interruptible(map->active.inflight_conn_req,
> +					 pvcalls_front_read_todo(map));
> +	}
> +	ret = __read_ring(map->active.ring, &map->active.data,
> +			  &msg->msg_iter, len, flags);
> +
> +	if (ret > 0)
> +		notify_remote_via_irq(map->active.irq);
> +	if (ret == 0)
> +		ret = -EAGAIN;

Why not 0? The manpage says:

       EAGAIN or EWOULDBLOCK
              The  socket  is  marked nonblocking and the receive
operation would block, or a receive timeout
              had been set and the timeout expired before data was
received.  POSIX.1 allows either error  to
              be  returned  for  this case, and does not require these
constants to have the same value, so a
              portable application should check for both possibilities.


I don't think either of these conditions is true here.

(Again, should have noticed this earlier, sorry)

-boris


> +	if (ret == -ENOTCONN)
> +		ret = 0;
> +
> +	mutex_unlock(&map->active.in_mutex);
> +	pvcalls_exit();
> +	return ret;
> +}