linux.git/net/vmw_vsock, branch v4.5-rc2

Revert "Merge branch 'vsock-virtio'"

2015-12-09T02:55:49+00:00

This reverts commit 0d76d6e8b2507983a2cae4c09880798079007421 and merge
commit c402293bd76fbc93e52ef8c0947ab81eea3ae019, reversing changes made
to c89359a42e2a49656451569c382eed63e781153c.

The virtio-vsock device specification is not finalized yet.  Michael
Tsirkin voiced concerned about merging this code when the hardware
interface (and possibly the userspace interface) could still change.

Signed-off-by: Stefan Hajnoczi 
Signed-off-by: David S. Miller

VSOCK: Add Makefile and Kconfig

2015-12-03T20:05:55+00:00

Enable virtio-vsock and vhost-vsock.

Signed-off-by: Asias He 
Signed-off-by: Stefan Hajnoczi 
Signed-off-by: David S. Miller

VSOCK: Introduce virtio-vsock.ko

2015-12-03T20:05:55+00:00

VM sockets virtio transport implementation. This module runs in guest
kernel.

Signed-off-by: Asias He 
Signed-off-by: Stefan Hajnoczi 
Signed-off-by: David S. Miller

VSOCK: Introduce virtio-vsock-common.ko

2015-12-03T20:05:55+00:00

This module contains the common code and header files for the following
virtio-vsock and virtio-vhost kernel modules.

Signed-off-by: Asias He 
Signed-off-by: Stefan Hajnoczi 
Signed-off-by: David S. Miller

VSOCK: Introduce vsock_find_unbound_socket and vsock_bind_dgram_generic

2015-12-03T20:05:54+00:00

Signed-off-by: Asias He 
Signed-off-by: Stefan Hajnoczi 
Signed-off-by: David S. Miller

VSOCK: constify vmci_transport_notify_ops structures

2015-11-23T20:49:29+00:00

The vmci_transport_notify_ops structures are never modified, so declare
them as const.

Done with the help of Coccinelle.

Signed-off-by: Julia Lawall 
Signed-off-by: David S. Miller

VSOCK: call sk->sk_data_ready() on accept()

2015-11-05T03:03:10+00:00

When a listen socket enqueues a connection for userspace to accept(),
the sk->sk_data_ready() callback should be invoked.  In-kernel socket
users rely on this callback to detect when incoming connections are
available.

Currently the sk->sk_state_change() callback is invoked by
vmci_transport.c.  This happens to work for userspace applications since
sk->sk_state_change = sock_def_wakeup() and sk->sk_data_ready =
sock_def_readable() both wake up the accept() waiter.  In-kernel socket
users, on the other hand, fail to detect incoming connections.

Signed-off-by: Stefan Hajnoczi 
Signed-off-by: David S. Miller

VSOCK: define VSOCK_SS_LISTEN once only

2015-11-01T17:14:47+00:00

The SS_LISTEN socket state is defined by both af_vsock.c and
vmci_transport.c.  This is risky since the value could be changed in one
file and the other would be out of sync.

Rename from SS_LISTEN to VSOCK_SS_LISTEN since the constant is not part
of enum socket_state (SS_CONNECTED, ...).  This way it is clear that the
constant is vsock-specific.

The big text reflow in af_vsock.c was necessary to keep to the maximum
line length.  Text is unchanged except for s/SS_LISTEN/VSOCK_SS_LISTEN/.

Signed-off-by: Stefan Hajnoczi 
Signed-off-by: David S. Miller

VSOCK: Fix lockdep issue.

2015-10-23T01:26:29+00:00

The recent fix for the vsock sock_put issue used the wrong
initializer for the transport spin_lock causing an issue when
running with lockdep checking.

Testing: Verified fix on kernel with lockdep enabled.

Reviewed-by: Thomas Hellstrom 
Signed-off-by: Jorgen Hansen 
Signed-off-by: David S. Miller

VSOCK: sock_put wasn't safe to call in interrupt context

2015-10-22T14:21:05+00:00

In the vsock vmci_transport driver, sock_put wasn't safe to call
in interrupt context, since that may call the vsock destructor
which in turn calls several functions that should only be called
from process context. This change defers the callling of these
functions  to a worker thread. All these functions were
deallocation of resources related to the transport itself.

Furthermore, an unused callback was removed to simplify the
cleanup.

Multiple customers have been hitting this issue when using
VMware tools on vSphere 2015.

Also added a version to the vmci transport module (starting from
1.0.2.0-k since up until now it appears that this module was
sharing version with vsock that is currently at 1.0.1.0-k).

Reviewed-by: Aditya Asarwade 
Reviewed-by: Thomas Hellstrom 
Signed-off-by: Jorgen Hansen 
Signed-off-by: David S. Miller