lkml.org 
[lkml]   [2023]   [Jul]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectHyper-V vsock streams do not fill the supplied buffer in full
    When a vsock stream is called with recvmsg with a buffer, it only fills
    the buffer with data from the first single VM packet. Even if there are
    more VM packets at the time and the buffer is still not completely
    filled, it will just leave the buffer partially filled.

    This causes some issues when in WSLD which uses the vsock in
    non-blocking mode and uses epoll.

    For stream-oriented sockets, the epoll man page [1] says that

    > For stream-oriented files (e.g., pipe, FIFO, stream socket),
    > the condition that the read/write I/O space is exhausted can
    > also be detected by checking the amount of data read from /
    > written to the target file descriptor. For example, if you
    > call read(2) by asking to read a certain amount of data and
    > read(2) returns a lower number of bytes, you can be sure of
    > having exhausted the read I/O space for the file descriptor.

    This has been used as an optimisation in the wild for reducing number
    of syscalls required for stream sockets (by asserting that the socket
    will not have to polled to EAGAIN in edge-trigger mode, if the buffer
    given to recvmsg is not filled completely). An example is Tokio, which
    starting in v1.21.0 [2].

    When this optimisation combines with the behaviour of Hyper-V vsock, it
    causes issue in this scenario:
    * the VM host send data to the guest, and it's splitted into multiple
    VM packets
    * sk_data_ready is called and epoll returns, notifying the userspace
    that the socket is ready
    * userspace call recvmsg with a buffer, and it's partially filled
    * userspace assumes that the stream socket is depleted, and if new data
    arrives epoll will notify it again.
    * kernel always considers the socket to be ready, and since it's in
    edge-trigger mode, the epoll instance will never be notified again.

    This different realisation of the readiness causes the userspace to
    block forever.

    [0] https://github.com/nbdd0121/wsld/issues/32
    [1] https://man7.org/linux/man-pages/man7/epoll.7.html#:~:text=For%20stream%2Doriented%20files
    [2] https://github.com/tokio-rs/tokio/pull/4840

    \
     
     \ /
      Last update: 2023-07-05 00:46    [W:5.133 / U:0.872 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site