All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Cc: berrange@redhat.com, farosas@suse.de, steven.sistare@oracle.com,
	qemu-devel@nongnu.org
Subject: Re: [PATCH v4 2/2] io/channel: document how qio_channel_readv_full() handles fds
Date: Wed, 10 Sep 2025 15:56:56 -0400	[thread overview]
Message-ID: <aMHYCBFjrAaVXlG-@x1.local> (raw)
In-Reply-To: <20250910193112.1220763-3-vsementsov@yandex-team.ru>

On Wed, Sep 10, 2025 at 10:31:12PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> The only realization, which may have incoming fds is
> qio_channel_socket_readv() (in io/channel-socket.c).
> qio_channel_socket_readv() do call (through
> qio_channel_socket_copy_fds()) qemu_socket_set_block() and
> qemu_set_cloexec() for each fd.
> 
> Also, qio_channel_socket_copy_fds() is called at the end of
> qio_channel_socket_readv(), on success path.
> 
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>

Maybe I'd just keep the io_readv() one, but drop the extra documents in
qio_channel_readv_full(), because that is almost a duplicate.

Meanwhile, we also have other higher level API that has the @fds
(qio_channel_readv_full_all_eof(), for example) that are not documented,
OTOH..

Totally no strong feelings.

Acked-by: Peter Xu <peterx@redhat.com>

> ---
>  include/io/channel.h | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/include/io/channel.h b/include/io/channel.h
> index 12266256a8..c7f64506f7 100644
> --- a/include/io/channel.h
> +++ b/include/io/channel.h
> @@ -118,6 +118,15 @@ struct QIOChannelClass {
>                           size_t nfds,
>                           int flags,
>                           Error **errp);
> +
> +    /*
> +     * The io_readv handler must guarantee that all
> +     * incoming fds are set BLOCKING (unless
> +     * QIO_CHANNEL_READ_FLAG_FD_PRESERVE_BLOCKING flag is set) and
> +     * CLOEXEC (if available).
> +     * @fds and @nfds are set only on success path, and untouched
> +     * in case of errors.
> +     */
>      ssize_t (*io_readv)(QIOChannel *ioc,
>                          const struct iovec *iov,
>                          size_t niov,
> @@ -125,6 +134,7 @@ struct QIOChannelClass {
>                          size_t *nfds,
>                          int flags,
>                          Error **errp);
> +
>      int (*io_close)(QIOChannel *ioc,
>                      Error **errp);
>      GSource * (*io_create_watch)(QIOChannel *ioc,
> @@ -235,6 +245,13 @@ void qio_channel_set_name(QIOChannel *ioc,
>   * was allocated. It is the callers responsibility
>   * to call close() on each file descriptor and to
>   * call g_free() on the array pointer in @fds.
> + * @fds allocated and set (and @nfds is set too)
> + * _only_ on success path. These parameters are
> + * untouched in case of errors.
> + * qio_channel_readv_full() guarantees that all
> + * incoming fds are set BLOCKING (unless
> + * QIO_CHANNEL_READ_FLAG_FD_PRESERVE_BLOCKING flag
> + * is set) and CLOEXEC (if available).
>   *
>   * It is an error to pass a non-NULL @fds parameter
>   * unless qio_channel_has_feature() returns a true
> -- 
> 2.48.1
> 

-- 
Peter Xu



  reply	other threads:[~2025-09-10 19:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-10 19:31 [PATCH v4 0/2] save qemu-file incoming non-blocking fds Vladimir Sementsov-Ogievskiy
2025-09-10 19:31 ` [PATCH v4 1/2] migration/qemu-file: don't make incoming fds blocking again Vladimir Sementsov-Ogievskiy
2025-09-10 19:42   ` Peter Xu
2025-09-12 16:47   ` Daniel P. Berrangé
2025-09-10 19:31 ` [PATCH v4 2/2] io/channel: document how qio_channel_readv_full() handles fds Vladimir Sementsov-Ogievskiy
2025-09-10 19:56   ` Peter Xu [this message]
2025-09-12 16:48   ` Daniel P. Berrangé

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aMHYCBFjrAaVXlG-@x1.local \
    --to=peterx@redhat.com \
    --cc=berrange@redhat.com \
    --cc=farosas@suse.de \
    --cc=qemu-devel@nongnu.org \
    --cc=steven.sistare@oracle.com \
    --cc=vsementsov@yandex-team.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.