diff options
author | John Levon <john.levon@nutanix.com> | 2021-04-06 15:26:19 +0100 |
---|---|---|
committer | GitHub <noreply@github.com> | 2021-04-06 15:26:19 +0100 |
commit | 996d4f3cdae229fee9b5c8867d87beeb9172b97f (patch) | |
tree | 099dc048724bb0d895c2bbc886e8e0448ab35dc0 /include | |
parent | e97a5e8c911acd8826542b1de30fb834901f4e76 (diff) | |
download | libvfio-user-996d4f3cdae229fee9b5c8867d87beeb9172b97f.zip libvfio-user-996d4f3cdae229fee9b5c8867d87beeb9172b97f.tar.gz libvfio-user-996d4f3cdae229fee9b5c8867d87beeb9172b97f.tar.bz2 |
implement short read/write, EOF handling (#415)
Report any short reads to callers as ECONNRESET, which is the closest we can
meaningfully get right now. This also fixes get_next_command(), which previously
wasn't checking for short reads at all.
When we fail to send or recv from the socket due to the client disappearing in
some manner, call into vfu_reset_ctx() to clean up the connection fd, allowing a
subsequent vfu_attach_ctx() to work.
If we get 0 bytes from recv[msg](), this is reported by the transport as ENOMSG,
and is a normal EOF condition.
We can also get ECONNRESET: this can happen when we've written unacknowledged
data to the socket, the client side socket is closed, and we try a subsequent
read.
Finally, we can get a short read or write. Our handling of these still has
issues, but for now we'll presume this means the client has gone too. It may
in fact be due to a client bug - if it failed to write enough data - but right
now, we can't easily tell that.
Signed-off-by: John Levon <john.levon@nutanix.com>
Reviewed-by: Thanos Makatos <thanos.makatos@nutanix.com>
Diffstat (limited to 'include')
-rw-r--r-- | include/libvfio-user.h | 10 |
1 files changed, 7 insertions, 3 deletions
diff --git a/include/libvfio-user.h b/include/libvfio-user.h index 1048236..925550a 100644 --- a/include/libvfio-user.h +++ b/include/libvfio-user.h @@ -137,18 +137,22 @@ int vfu_get_poll_fd(vfu_ctx_t *vfu_ctx); /** - * Polls the vfu_ctx and processes the command recieved from client. + * Polls the vfu_ctx and processes the command received from client. * - Blocking vfu_ctx: * Blocks until new request is received from client and continues processing * the requests. Exits only in case of error or if the client disconnects. * - Non-blocking vfu_ctx(LIBVFIO_USER_FLAG_ATTACH_NB): * Processes one request from client if it's available, otherwise it - * immediatelly returns and the caller is responsible for periodically + * immediately returns and the caller is responsible for periodically * calling again. * * @vfu_ctx: The libvfio-user context to poll * - * @returns 0 on success, -1 on error. Sets errno. + * @returns 0 on success, -1 on error, with errno set as follows: + * + * EAGAIN/EWOULDBLOCK: no more commands to process + * ENOTCONN: client closed connection, vfu_attach_ctx() should be called again + * Other errno values are also possible. */ int vfu_run_ctx(vfu_ctx_t *vfu_ctx); |