search for: tcp_established

...letionToken core_tcp_write: Sending 227 bytes tcp transmit failed, Access Denied Meanwhile on the OVMF side I could get these debug logs: Tcb (3F296898) state TCP_CLOSED --> TCP_SYN_SENT TcpToSendData: set RTT measure sequence 464107706 for TCB 3F296898 Tcb (3F296898) state TCP_SYN_SENT --> TCP_ESTABLISHED TcpComputeRtt: new RTT for TCB 3F296898 computed SRTT: 0 RTTVAR: 0 RTO: 5 TcpInput: connection established for TCB 3F296898 in SYN_SENT TcpInput: connection reset for TCB 3F296898 Tcb (3F296898) state TCP_ESTABLISHED --> TCP_CLOSED Tcb (3F296898) state TCP_CLOSED --> TCP_CLOSED So now it see...

...Bobby Eshleman wrote: >> > @@ -1241,19 +1252,34 @@ static int vsock_dgram_connect(struct socket *sock, >> > >> > memcpy(&vsk->remote_addr, remote_addr, sizeof(vsk->remote_addr)); >> > sock->state = SS_CONNECTED; >> > + sk->sk_state = TCP_ESTABLISHED; >> > >> > out: >> > release_sock(sk); >> > return err; >> > } >> >> >> How is this related? Maybe add a comment to explain? Does >> TCP_ESTABLISHED make sense for all types of sockets? >> > >Hey Michael, definit...

...net/vmw_vsock/af_vsock.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c > index 2ab43b2bba31..27df57c2024b 100644 > --- a/net/vmw_vsock/af_vsock.c > +++ b/net/vmw_vsock/af_vsock.c > @@ -83,6 +83,10 @@ > * TCP_ESTABLISHED - connected > * TCP_CLOSING - disconnecting > * TCP_LISTEN - listening > + * > + * - Half-closed socket is supported only on the guest side. recv() on the host > + * side should return EOF when the guest closes a connection, also if some > + * data is still in the receive...

...cting to. */ - memcpy(&vsk->remote_addr, remote_addr, - sizeof(vsk->remote_addr)); - err = vsock_auto_bind(vsk); if (err) goto out; @@ -1586,7 +1651,7 @@ static int vsock_stream_sendmsg(struct socket *sock, struct msghdr *msg, goto out; } - if (sk->sk_state != TCP_ESTABLISHED || + if (!transport || sk->sk_state != TCP_ESTABLISHED || !vsock_addr_bound(&vsk->local_addr)) { err = -ENOTCONN; goto out; @@ -1712,7 +1777,7 @@ vsock_stream_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, lock_sock(sk); - if (sk->sk_state != TCP_ESTABLI...

...cting to. */ - memcpy(&vsk->remote_addr, remote_addr, - sizeof(vsk->remote_addr)); - err = vsock_auto_bind(vsk); if (err) goto out; @@ -1572,7 +1630,7 @@ static int vsock_stream_sendmsg(struct socket *sock, struct msghdr *msg, goto out; } - if (sk->sk_state != TCP_ESTABLISHED || + if (!transport || sk->sk_state != TCP_ESTABLISHED || !vsock_addr_bound(&vsk->local_addr)) { err = -ENOTCONN; goto out; @@ -1698,7 +1756,7 @@ vsock_stream_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, lock_sock(sk); - if (sk->sk_state != TCP_ESTABLI...

...socket OPS */ +static int vmchannel_sock_release(struct socket *sock) +{ + struct sock *sk = sock->sk; + struct vmchannel_sock *vmc = vmchannel_sk(sk); + + if (!sk) + return 0; + + vmchannel_sock_unlink(&vmchannel_sk_list, sk); + + sock_orphan(sk); + lock_sock(sk); + if (sk->sk_state == TCP_ESTABLISHED) { + sk->sk_state = TCP_CLOSE; + sk->sk_shutdown |= SEND_SHUTDOWN | RCV_SHUTDOWN; + sk->sk_err = ECONNRESET; + sk->sk_state_change(sk); + skb_queue_purge(&vmc->backlog_skb_q); + } + release_sock(sk); + sock_put(sk); + return 0; +} + +/* Bind an unbound socket */ +static int...

...socket OPS */ +static int vmchannel_sock_release(struct socket *sock) +{ + struct sock *sk = sock->sk; + struct vmchannel_sock *vmc = vmchannel_sk(sk); + + if (!sk) + return 0; + + vmchannel_sock_unlink(&vmchannel_sk_list, sk); + + sock_orphan(sk); + lock_sock(sk); + if (sk->sk_state == TCP_ESTABLISHED) { + sk->sk_state = TCP_CLOSE; + sk->sk_shutdown |= SEND_SHUTDOWN | RCV_SHUTDOWN; + sk->sk_err = ECONNRESET; + sk->sk_state_change(sk); + skb_queue_purge(&vmc->backlog_skb_q); + } + release_sock(sk); + sock_put(sk); + return 0; +} + +/* Bind an unbound socket */ +static int...

We are implementing a test suite for the VSOCK sockets and we discovered that vmci_transport never allowed half-closed socket on the host side. As Jorgen explained [1] this is due to the implementation of VMCI. Since we want to have the same behaviour across all transports, this series adds a section in the "Implementation notes" to exaplain this behaviour, and changes the

We are implementing a test suite for the VSOCK sockets and we discovered that vmci_transport never allowed half-closed socket on the host side. As Jorgen explained [1] this is due to the implementation of VMCI. Since we want to have the same behaviour across all transports, this series adds a section in the "Implementation notes" to exaplain this behaviour, and changes the

...:45.85 | 0.18) 03:24:16 : H 3 : I 18 : P 35 : snmp_counter:outpackets(.1.3..1.4): -> buffer(): 17 (time P:99.65 | 0.2) 03:24:16 : H 3 : I 19 : P 35 : snmp_counter:outpackets(.1.3..1.5): -> buffer(): 18 (time P:91.52 | 0.21) 03:24:16 : H 3 : I 21 : P 35 : snmp_counter:tcp_established(.1.3..9.0): 3 -> buffer(): 19 (time P:46.5 | 0.19) 03:24:16 : H 3 : I 18 : P 40 : snmp_counter:outputerrors(.1.3..0.4): 527 -> buffer(): 20 (time P:47.91 | 0.2) 03:24:16 : H 3 : I 19 : P 40 : snmp_counter:outputerrors(.1.3..0.5): 0 -> buffer(): 21 (time P:47.89 | 0.22) 03:2...

Hello, I'm trying to find out how to pxe boot with syslinux.efi on QEMU with OVMF. After getting through the initial hurdle caused by the iPXE based option ROM included with QEMU having a problem as described in these threads: http://www.syslinux.org/archives/2014-November/022804.html http://sourceforge.net/p/edk2/mailman/message/33236100/ I'm now getting further to almost being able

...lla <sgarzare at redhat.com> --- net/vmw_vsock/af_vsock.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c index 2ab43b2bba31..27df57c2024b 100644 --- a/net/vmw_vsock/af_vsock.c +++ b/net/vmw_vsock/af_vsock.c @@ -83,6 +83,10 @@ * TCP_ESTABLISHED - connected * TCP_CLOSING - disconnecting * TCP_LISTEN - listening + * + * - Half-closed socket is supported only on the guest side. recv() on the host + * side should return EOF when the guest closes a connection, also if some + * data is still in the receive queue. */ #include <li...

...c1a7c6623fe at syzkaller.appspotmail.com > Fixes: 408624af4c89 ("vsock: use local transport when it is loaded") > > For information about bisection process see: https://goo.gl/tpsmEJ#bisection > I'll take a look. At first glance it seems strange, because if sk_state is TCP_ESTABLISHED, the transport shouldn't be NULL, that's why we didn't put the check. Stefano

...;+++ b/net/vmw_vsock/af_vsock.c >@@ -1462,7 +1462,7 @@ static int vsock_connect(struct socket *sock, struct sockaddr *addr, > vsock_transport_cancel_pkt(vsk); > vsock_remove_connected(vsk); > goto out_wait; >- } else if (timeout == 0) { >+ } else if ((sk->sk_state != TCP_ESTABLISHED) && (timeout == 0)) { > err = -ETIMEDOUT; > sk->sk_state = TCP_CLOSE; > sock->state = SS_UNCONNECTED; >-- >2.27.0 >

...;+++ b/net/vmw_vsock/af_vsock.c >@@ -1462,7 +1462,7 @@ static int vsock_connect(struct socket *sock, struct sockaddr *addr, > vsock_transport_cancel_pkt(vsk); > vsock_remove_connected(vsk); > goto out_wait; >- } else if (timeout == 0) { >+ } else if ((sk->sk_state != TCP_ESTABLISHED) && (timeout == 0)) { > err = -ETIMEDOUT; > sk->sk_state = TCP_CLOSE; > sock->state = SS_UNCONNECTED; >-- >2.27.0 >

Most of the patches are reviewed by Dexuan, Stefan, and Jorgen. The following patches need reviews: - [11/15] vsock: add multi-transports support - [12/15] vsock/vmci: register vmci_transport only when VMCI guest/host are active - [15/15] vhost/vsock: refuse CID assigned to the guest->host transport RFC: https://patchwork.ozlabs.org/cover/1168442/ v1:

Hi all, this series adds the multi-transports support to vsock, following this proposal: https://www.spinics.net/lists/netdev/msg575792.html With the multi-transports support, we can use vsock with nested VMs (using also different hypervisors) loading both guest->host and host->guest transports at the same time. Before this series, vmci-transport supported this behavior but only using

Hi all, this series adds the multi-transports support to vsock, following this proposal: https://www.spinics.net/lists/netdev/msg575792.html With the multi-transports support, we can use vsock with nested VMs (using also different hypervisors) loading both guest->host and host->guest transports at the same time. Before this series, vmci-transport supported this behavior but only using

This series adds the multi-transports support to vsock, following this proposal: https://www.spinics.net/lists/netdev/msg575792.html With the multi-transports support, we can use VSOCK with nested VMs (using also different hypervisors) loading both guest->host and host->guest transports at the same time. Before this series, vmci-transport supported this behavior but only using VMware

This series adds the multi-transports support to vsock, following this proposal: https://www.spinics.net/lists/netdev/msg575792.html With the multi-transports support, we can use VSOCK with nested VMs (using also different hypervisors) loading both guest->host and host->guest transports at the same time. Before this series, vmci-transport supported this behavior but only using VMware