kernel.git/net/vmw_vsock, branch linux-4.1.y

vsock: use new wait API for vsock_stream_sendmsg()

2017-12-08T23:01:01Z

[ Upstream commit 499fde662f1957e3cb8d192a94a099ebe19c714b ] As reported by Michal, vsock_stream_sendmsg() could still sleep at vsock_stream_has_space() after prepare_to_wait(): vsock_stream_has_space vmci_transport_stream_has_space vmci_qpair_produce_free_space qp_lock qp_acquire_queue_mutex mutex_lock Just switch to the new wait API like we did for commit d9dc8b0f8b4e ("net: fix sleeping for sk_wait_event()"). Reported-by: Michal Kubecek Cc: Stefan Hajnoczi Cc: Jorgen Hansen Cc: "Michael S. Tsirkin" Cc: Claudio Imbrenda Signed-off-by: Cong Wang Reviewed-by: Stefan Hajnoczi Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

AF_VSOCK: Shrink the area influenced by prepare_to_wait

2017-12-08T23:01:00Z

[ Upstream commit f7f9b5e7f8eccfd68ffa7b8d74b07c478bb9e7f0 ] When a thread is prepared for waiting by calling prepare_to_wait, sleeping is not allowed until either the wait has taken place or finish_wait has been called. The existing code in af_vsock imposed unnecessary no-sleep assumptions to a broad list of backend functions. This patch shrinks the influence of prepare_to_wait to the area where it is strictly needed, therefore relaxing the no-sleep restriction there. Signed-off-by: Claudio Imbrenda Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

VSOCK: do not disconnect socket when peer has shutdown SEND only

2016-07-11T03:07:25Z

[ Upstream commit dedc58e067d8c379a15a8a183c5db318201295bb ] The peer may be expecting a reply having sent a request and then done a shutdown(SHUT_WR), so tearing down the whole socket at this point seems wrong and breaks for me with a client which does a SHUT_WR. Looking at other socket family's stream_recvmsg callbacks doing a shutdown here does not seem to be the norm and removing it does not seem to have had any adverse effects that I can see. I'm using Stefan's RFC virtio transport patches, I'm unsure of the impact on the vmci transport. Signed-off-by: Ian Campbell Cc: "David S. Miller" Cc: Stefan Hajnoczi Cc: Claudio Imbrenda Cc: Andy King Cc: Dmitry Torokhov Cc: Jorgen Hansen Cc: Adit Ranadive Cc: netdev@vger.kernel.org Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

net: Remove iocb argument from sendmsg and recvmsg

2015-03-02T18:06:31Z

After TIPC doesn't depend on iocb argument in its internal implementations of sendmsg() and recvmsg() hooks defined in proto structure, no any user is using iocb argument in them at all now. Then we can drop the redundant iocb argument completely from kinds of implementations of both sendmsg() and recvmsg() in the entire networking stack. Cc: Christoph Hellwig Suggested-by: Al Viro Signed-off-by: Ying Xue Signed-off-by: David S. Miller

vmci: propagate msghdr all way down to __qp_memcpy_to_queue()

2015-02-04T06:34:14Z

Switch from passing msg->iov_iter.iov to passing msg itself Signed-off-by: Al Viro

put iov_iter into msghdr

2014-12-09T21:29:03Z

Note that the code _using_ ->msg_iter at that point will be very unhappy with anything other than unshifted iovec-backed iov_iter. We still need to convert users to proper primitives. Signed-off-by: Al Viro

vmci: propagate msghdr all way down to __qp_memcpy_from_queue()

2014-12-09T21:28:23Z

... and switch it to memcpy_to_msg() Signed-off-by: Al Viro

vmci_transport: switch ->enqeue_dgram, ->enqueue_stream and ->dequeue_stream to msghdr

2014-11-24T10:16:42Z

Signed-off-by: Al Viro

net: Add and use skb_copy_datagram_msg() helper.

2014-11-05T21:46:40Z

This encapsulates all of the skb_copy_datagram_iovec() callers with call argument signature "skb, offset, msghdr->msg_iov, length". When we move to iov_iters in the networking, the iov_iter object will sit in the msghdr. Having a helper like this means there will be less places to touch during that transformation. Based upon descriptions and patch from Al Viro. Signed-off-by: David S. Miller

vsock: Make transport the proto owner

2014-05-05T17:13:50Z

Right now the core vsock module is the owner of the proto family. This means there's nothing preventing the transport module from unloading if there are open sockets, which results in a panic. Fix that by allowing the transport to be the owner, which will refcount it properly. Includes version bump to 1.0.1.0-k Passes checkpatch this time, I swear... Acked-by: Dmitry Torokhov Signed-off-by: Andy King Signed-off-by: David S. Miller