Re: [PATCH] vsock: bugfix port residue in server

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, May 11, 2023 at 03:03:24PM +0800, Zhuang Shengen wrote:
Hi Stefano:

在 2023/5/10 23:23, Stefano Garzarella 写道:
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"

thanks for your suggestion, I will change the subject
On Wed, May 10, 2023 at 10:25:02PM +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 processed first, and the connection is
established. However, the client's timer also times out, the original
processing logic of the client is to directly set the state of this vsock
to CLOSE and return ETIMEDOUT, User will release the port. It will not

What to you mean with "User" here?

The User means Client, I will delete the statement "User will release the por", it indeed difficult to understand
notify the server when the port is released, causing the server port remain


Can we remove this blank line?

OK
when client's vsock_conqnect timeout,it should check sk state is

The remote peer can't trust the other peer, indeed it will receive an
error after sending the first message and it will remove the connection,
right?

If this situation happend, the server will response a RST? Anyway the connection will not established before timeout, The sk state wont be ESTABLISHED.
ESTABLISHED or not. if sk state is ESTABLISHED, it means the connection
is established, the client should not set the sk state to CLOSE

Note: I encountered this issue on kernel-4.18, which can be fixed by
this patch. Then I checked the latest code in the community
and found similar issue.


In order to backport it to the stable kernels, we should add a Fixes tag:
https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html#describe-your-changes


OK, I add a Fixes: d021c344051a ("VSOCK: Introduce VM Sockets") in the new patch.

I put the new patch with v2 title in the attachment, please check.

LGTM (great to have added the net tag!), but please post as plain text like v1.

Thanks,
Stefano

_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization




[Index of Archives]     [KVM Development]     [Libvirt Development]     [Libvirt Users]     [CentOS Virtualization]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux