search for: tcp_closing

A recent commit (3b4477d2dcf2) converted the sk_state to use TCP constants. In that change, vmci_transport_handle_detach was changed such that sk->sk_state was set to TCP_CLOSE before we test whether it is TCP_SYN_SENT. This change moves the sk_state change back to the original locations in that function. Signed-off-by: Jorgen Hansen <jhansen at vmware.com> ---

A recent commit (3b4477d2dcf2) converted the sk_state to use TCP constants. In that change, vmci_transport_handle_detach was changed such that sk->sk_state was set to TCP_CLOSE before we test whether it is TCP_SYN_SENT. This change moves the sk_state change back to the original locations in that function. Signed-off-by: Jorgen Hansen <jhansen at vmware.com> ---

On Tue, 7 Apr 2015, Laszlo Ersek wrote: > Whereas syslinux.efi apparently uses the embedded gpxe/ tree, and that > one uses TCP timestamps. See tcp_xmit() in gpxe/src/net/tcp.c: Actually syslinux.efi seems to be using the implementation calling into UEFI via these functions: http://git.kernel.org/cgit/boot/syslinux/syslinux.git/tree/efi/tcp.c I've tried to add debug messages to these

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

...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. > */ > > #incl...

Hello, I''ve got several kernel panic on a domU under network activity (multiple rsync using rsh). I didn''t manage to reproduce it manually, but it happened 5times during the last month. Each time, it is the same kernel trace. I am using Debian 5.0.8 with kernel/hypervisor : ii linux-image-2.6.32-bpo.5-amd64 2.6.32-30~bpo50+1 Linux 2.6.32 for 64-bit PCs ii

Hello, I''ve got several kernel panic on a domU under network activity (multiple rsync using rsh). I didn''t manage to reproduce it manually, but it happened 5times during the last month. Each time, it is the same kernel trace. I am using Debian 5.0.8 with kernel/hypervisor : ii linux-image-2.6.32-bpo.5-amd64 2.6.32-30~bpo50+1 Linux 2.6.32 for 64-bit PCs ii

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

...--- 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 <linux/types.h> -- 2.21.0

...onnected(struct sock *sk, if (le32_to_cpu(pkt->hdr.flags) & VIRTIO_VSOCK_SHUTDOWN_SEND) vsk->peer_shutdown |= SEND_SHUTDOWN; if (vsk->peer_shutdown == SHUTDOWN_MASK && - vsock_stream_has_data(vsk) <= 0) { - sock_set_flag(sk, SOCK_DONE); - sk->sk_state = TCP_CLOSING; + vsock_stream_has_data(vsk) <= 0 && + !sock_flag(sk, SOCK_DONE)) { + (void)virtio_transport_reset(vsk, NULL); + + virtio_transport_do_close(vsk, true); } if (le32_to_cpu(pkt->hdr.flags)) sk->sk_state_change(sk); -- 2.21.0

Hi, thanks for the patch, the change LGTM, but I have the following suggestions: Please avoid "bugfix" in the subject, "fix" should be enough: https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html#describe-your-changes Anyway, I suggest to change the subject in "vsock: avoid to close connected socket after the timeout" On Wed, May 10, 2023 at

> From: Stefano Garzarella [mailto:sgarzare at redhat.com] > Sent: Wednesday, October 23, 2019 11:56 AM > Subject: [PATCH net-next 07/14] vsock: handle buffer_size sockopts in the > core > > virtio_transport and vmci_transport handle the buffer_size sockopts in a > very similar way. > > In order to support multiple transports, this patch moves this handling in the >

On Thu, May 11, 2023 at 07:34:30PM +0800, Zhuang Shengen wrote: >When client and server establish a connection through vsock, >the client send a request to the server to initiate the connection, >then start a timer to wait for the server's response. When the server's >RESPONSE message arrives, the timer also times out and exits. The >server's RESPONSE message is

When using the host personality, VMCI will grab a mutex for any queue pair access. In the detach callback for the vmci vsock transport, we call vsock_stream_has_data while holding a spinlock, and vsock_stream_has_data will access a queue pair. To avoid this, we can simply omit calling vsock_stream_has_data for host side queue pairs, since the QPs are empty per default when the guest has detached.

When using the host personality, VMCI will grab a mutex for any queue pair access. In the detach callback for the vmci vsock transport, we call vsock_stream_has_data while holding a spinlock, and vsock_stream_has_data will access a queue pair. To avoid this, we can simply omit calling vsock_stream_has_data for host side queue pairs, since the QPs are empty per default when the guest has detached.

The current vsock code for removal of socket from the list is both subject to race and inefficient. It takes the lock, checks whether the socket is in the list, drops the lock and if the socket was on the list, deletes it from the list. This is subject to race because as soon as the lock is dropped once it is checked for presence, that condition cannot be relied upon for any decision. It is also

The current vsock code for removal of socket from the list is both subject to race and inefficient. It takes the lock, checks whether the socket is in the list, drops the lock and if the socket was on the list, deletes it from the list. This is subject to race because as soon as the lock is dropped once it is checked for presence, that condition cannot be relied upon for any decision. It is also

virtio_transport and vmci_transport handle the buffer_size sockopts in a very similar way. In order to support multiple transports, this patch moves this handling in the core to allow the user to change the options also if the socket is not yet assigned to any transport. This patch also adds the '.notify_buffer_size' callback in the 'struct virtio_transport' in order to inform

virtio_transport and vmci_transport handle the buffer_size sockopts in a very similar way. In order to support multiple transports, this patch moves this handling in the core to allow the user to change the options also if the socket is not yet assigned to any transport. This patch also adds the '.notify_buffer_size' callback in the 'struct virtio_transport' in order to inform