10 Jan, 2019
1 commit
-
[ Upstream commit a915b982d8f5e4295f64b8dd37ce753874867e88 ]
If a server side socket is bound to an address, but not in the listening
state yet, incoming connection requests should receive a reset control
packet in response. However, the function used to send the reset
silently drops the reset packet if the sending socket isn't bound
to a remote address (as is the case for a bound socket not yet in
the listening state). This change fixes this by using the src
of the incoming packet as destination for the reset packet in
this case.Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
Reviewed-by: Adit Ranadive
Reviewed-by: Vishnu Dasa
Signed-off-by: Jorgen Hansen
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
22 Aug, 2018
1 commit
-
[ Upstream commit 455f05ecd2b219e9a216050796d30c830d9bc393 ]
syzbot reported that we reinitialize an active delayed
work in vsock_stream_connect():ODEBUG: init active (active state 0) object type: timer_list hint:
delayed_work_timer_fn+0x0/0x90 kernel/workqueue.c:1414
WARNING: CPU: 1 PID: 11518 at lib/debugobjects.c:329
debug_print_object+0x16a/0x210 lib/debugobjects.c:326The pattern is apparently wrong, we should only initialize
the dealyed work once and could repeatly schedule it. So we
have to move out the initializations to allocation side.
And to avoid confusion, we can split the shared dwork
into two, instead of re-using the same one.Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
Reported-by:
Cc: Andy king
Cc: Stefan Hajnoczi
Cc: Jorgen Hansen
Signed-off-by: Cong Wang
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
31 Mar, 2017
1 commit
-
Rather than assign the positive errno values to ret and then
checking if it is positive and flip the sign, just return the
errno value.Detected by CoverityScan, CID#986649 ("Logically Dead Code")
Signed-off-by: Colin Ian King
Reviewed-by: Stefan Hajnoczi
Reviewed-by: Jorgen Hansen
Acked-by: Michael S. Tsirkin
Signed-off-by: David S. Miller
02 Aug, 2016
1 commit
-
The virtio transport will implement graceful shutdown and the related
SO_LINGER socket option. This requires orphaning the sock but keeping
it in the table of connections after .release().This patch adds the vsock_remove_sock() function and leaves it up to the
transport when to remove the sock.Signed-off-by: Stefan Hajnoczi
Signed-off-by: Michael S. Tsirkin
04 May, 2016
1 commit
-
The vsock_transport structure is never modified, so declare it as const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall
Signed-off-by: David S. Miller
20 Apr, 2016
1 commit
-
If skb_recv_datagram returns an skb, we should ignore the err
value returned. Otherwise, datagram receives will return EAGAIN
when they have to wait for a datagram.Acked-by: Adit Ranadive
Signed-off-by: Jorgen Hansen
Signed-off-by: David S. Miller
07 Apr, 2016
1 commit
-
The check in vmci_transport_peer_detach_cb should only allow a
detach when the qp handle of the transport matches the one in
the detach message.Testing: Before this change, a detach from a peer on a different
socket would cause an active stream socket to register a detach.Reviewed-by: George Zhang
Signed-off-by: Jorgen Hansen
Signed-off-by: David S. Miller
05 Nov, 2015
1 commit
-
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
02 Nov, 2015
1 commit
-
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
23 Oct, 2015
1 commit
-
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
22 Oct, 2015
1 commit
-
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
11 May, 2015
1 commit
-
In preparation for changing how struct net is refcounted
on kernel sockets pass the knowledge that we are creating
a kernel socket from sock_create_kern through to sk_alloc.Signed-off-by: "Eric W. Biederman"
Signed-off-by: David S. Miller
03 Mar, 2015
1 commit
-
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
04 Feb, 2015
1 commit
-
Switch from passing msg->iov_iter.iov to passing msg itself
Signed-off-by: Al Viro
10 Dec, 2014
2 commits
-
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
-
... and switch it to memcpy_to_msg()
Signed-off-by: Al Viro
24 Nov, 2014
1 commit
-
Signed-off-by: Al Viro
06 Nov, 2014
1 commit
-
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
19 Jan, 2014
1 commit
-
This is a follow-up patch to f3d3342602f8bc ("net: rework recvmsg
handler msg_name and msg_namelen logic").DECLARE_SOCKADDR validates that the structure we use for writing the
name information to is not larger than the buffer which is reserved
for msg->msg_name (which is 128 bytes). Also use DECLARE_SOCKADDR
consistently in sendmsg code paths.Signed-off-by: Steffen Hurrle
Suggested-by: Hannes Frederic Sowa
Acked-by: Hannes Frederic Sowa
Signed-off-by: David S. Miller
21 Nov, 2013
1 commit
-
This patch now always passes msg->msg_namelen as 0. recvmsg handlers must
set msg_namelen to the proper size
Suggested-by: Eric Dumazet
Signed-off-by: Hannes Frederic Sowa
Signed-off-by: David S. Miller
28 Jul, 2013
1 commit
-
This is useful for other VSOCK transport implemented outside the
net/vmw_vsock/ directory to use these headers.Signed-off-by: Asias He
Acked-by: Andy King
Signed-off-by: David S. Miller
24 Jun, 2013
2 commits
-
Signed-off-by: Asias He
Acked-by: Andy King
Signed-off-by: David S. Miller -
vmci_transport_recv_dgram_cb always return VMCI_SUCESS even if we fail
to allocate skb, return VMCI_ERROR_NO_MEM instead.Signed-off-by: Asias He
Acked-by: Andy King
Signed-off-by: David S. Miller
08 Apr, 2013
2 commits
-
Conflicts:
drivers/nfc/microread/mei.c
net/netfilter/nfnetlink_queue_core.cPull in 'net' to get Eric Biederman's AF_UNIX fix, upon which
some cleanups are going to go on-top.Signed-off-by: David S. Miller
-
In case we received no data on the call to skb_recv_datagram(), i.e.
skb->data is NULL, vmci_transport_dgram_dequeue() will return with 0
without updating msg_namelen leading to net/socket.c leaking the local,
uninitialized sockaddr_storage variable to userland -- 128 bytes of
kernel stack memory.Fix this by moving the already existing msg_namelen assignment a few
lines above.Cc: Andy King
Cc: Dmitry Torokhov
Cc: George Zhang
Signed-off-by: Mathias Krause
Signed-off-by: David S. Miller
03 Apr, 2013
2 commits
-
Pull net into net-next to get the synchronize_net() bug fix in
bonding.Signed-off-by: David S. Miller
-
The VMCI context ID of a virtual machine may change at any time. There
is a VMCI event which signals this but datagrams may be processed before
this is handled. It is therefore necessary to be flexible about the
destination context ID of any datagrams received. (It can be assumed to
be correct because it is provided by the hypervisor.) The context ID on
existing sockets should be updated to reflect how the hypervisor is
currently referring to the system.Signed-off-by: Reilly Grant
Acked-by: Andy King
Signed-off-by: David S. Miller
15 Mar, 2013
1 commit
-
The resource ID used for VM socket control packets (0) is already
used for the VMCI_GET_CONTEXT_ID hypercall so a new ID (15) must be
used when the guest sends these datagrams to the hypervisor.The hypervisor context ID must also be removed from the internal
blacklist.Signed-off-by: Reilly Grant
Acked-by: Andy King
Signed-off-by: David S. Miller
19 Feb, 2013
1 commit
-
This is the default behavior for a looooooong time.
Acked-by: Andy King
Signed-off-by: Dmitry Torokhov
Signed-off-by: David S. Miller
11 Feb, 2013
1 commit
-
VM Sockets allows communication between virtual machines and the hypervisor.
User level applications both in a virtual machine and on the host can use the
VM Sockets API, which facilitates fast and efficient communication between
guest virtual machines and their host. A socket address family, designed to be
compatible with UDP and TCP at the interface level, is provided.Today, VM Sockets is used by various VMware Tools components inside the guest
for zero-config, network-less access to VMware host services. In addition to
this, VMware's users are using VM Sockets for various applications, where
network access of the virtual machine is restricted or non-existent. Examples
of this are VMs communicating with device proxies for proprietary hardware
running as host applications and automated testing of applications running
within virtual machines.The VMware VM Sockets are similar to other socket types, like Berkeley UNIX
socket interface. The VM Sockets module supports both connection-oriented
stream sockets like TCP, and connectionless datagram sockets like UDP. The VM
Sockets protocol family is defined as "AF_VSOCK" and the socket operations
split for SOCK_DGRAM and SOCK_STREAM.For additional information about the use of VM Sockets, please refer to the
VM Sockets Programming Guide available at:https://www.vmware.com/support/developer/vmci-sdk/
Signed-off-by: George Zhang
Signed-off-by: Dmitry Torokhov
Signed-off-by: Andy king
Signed-off-by: David S. Miller
