qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Zihan Yang <whois.zihan.yang@gmail.com>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: qemu-devel@nongnu.org,
	Hitoshi Mitake <mitake.hitoshi@lab.ntt.co.jp>,
	Liu Yuan <namei.unix@gmail.com>, Jeff Cody <jcody@redhat.com>,
	Kevin Wolf <kwolf@redhat.com>, Max Reitz <mreitz@redhat.com>,
	"Richard W.M. Jones" <rjones@redhat.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	"open list:Sheepdog" <qemu-block@nongnu.org>,
	"open list:Sheepdog" <sheepdog@lists.wpkg.org>
Subject: [Qemu-devel] Fwd: [RFC 2/4] qemu-socket: Allow custom socket options in socket_connect
Date: Wed, 31 Jan 2018 23:20:16 +0800	[thread overview]
Message-ID: <CAKwiv-hsjACjNqPSz36JGPv17UAQr0Utga7Krw7iZ-iCEC9gmQ@mail.gmail.com> (raw)
In-Reply-To: <20180131095118.GE3255@redhat.com>

Hi, Daniel

>You've added all this extra functionality to pass arbitrary
>options, but then not used it in any of the later patches.
>We've been trying to remove complexity from this code, so
>I'm not in favour of adding new functionality that is not
>even used.

You are right, unused functionality should not be added. I was thinking
about future usage, but that seems really unnecessary now.

>I'm not seeing the point of adding the support for the O_NONBLOCK
>in the listener socket either - that can easily be turned on after
>you have the listener socket created.

I don't quite understand how I can turn it on in socket_listen, because
socket_listen will create a listener socket inside it, then bind and listen.
Are there other ways than passing some kind of 'config parameter'?

>The O_NONBLOCK functionality makes more sense in this context
>but the implementation is really broken.

Well.. sorry for the broken implementation, I guess I need more practice.

>These functions do hostname lookups, so can never do non-blocking
>mode correctly as the hostname lookup itself does blocking I/O
>to the nameserver(s).  Ignoring that, the way you handle the
>connect() is wrong too. You're iterating over many addresses
>returned by getaddrinfo() and doing a non-blocking connect
>on each of them. These will essentially all fail with EAGAIN
>and you'll skip onto the next address which is wrong.

Why would the hostname lookup affect the listener socket
afterwards? The socket is created after the lookup procedure is done.
Therefore, the config should only affect the listener socket, not the
hostname lookup process. Would you explain in more detail? I'm not
an expert in socket programming, so I'm confused.

Also, connect() indeed could return EAGAIN, however, the continue
expression is inside the do-while loop of inet_connect_addr(),
rather than the for loop inside inet_connect_saddr(), which is the
caller of inet_connect_addr(). So it would just try to connect again
instead of skipping to next address.

I know this is not a well-written patch, but if you forget about the broken
implementation for a while, it actually won't fail them all. I did a little
test
by connecting two VMs through socket, and they can ping each other.
The docker test fails because I missed the NULL pointer check for sconf,
which I ignored in the ping test above, but it is irrelevant to the problem
here. After I fix it, the test passes.

>This code used to have support for O_NONBLOCK but it was removed
>because the DNS problem means that any code relying on it was
>already broken.  The rest of the QEMU codebase has been converted
>to use QIOChannelSocket instead which can handle non-blocking
>DNS properly

I didn't know this, thanks for clarifying it. Do you mean if I want to use
non-blocking socket, it's better to use QIOChannelSocket instead of
socket_listen/socket_connect? If I want to set some other
options, do I have to use the bind/listen/connect series functions
directly? That seems the way in some functions in net/socket.c.

Anyway, thanks for your comment, it helps clarify things. I had
intended to get start with this task, but it seems to have already been
fully explored before. I guess I need to review my patches throughly,

Regards
Zihan

  reply	other threads:[~2018-01-31 15:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-29 19:13 [Qemu-devel] [RFC 0/4] Allow custom socket option in socket_listen and socket_connect Zihan Yang
2018-01-29 19:13 ` [Qemu-devel] [RFC 1/4] qemu-socket: Allow custom socket option in socket_listen Zihan Yang
2018-01-31  9:47   ` Daniel P. Berrangé
2018-01-29 19:13 ` [Qemu-devel] [RFC 2/4] qemu-socket: Allow custom socket options in socket_connect Zihan Yang
2018-01-31  9:51   ` Daniel P. Berrangé
2018-01-31 15:20     ` Zihan Yang [this message]
2018-01-31 15:26       ` [Qemu-devel] Fwd: " Daniel P. Berrangé
2018-01-29 19:13 ` [Qemu-devel] [RFC 3/4] net/socket: change net_socket_listen_init to use functions in include/qemu/sockets.h Zihan Yang
2018-01-29 19:13 ` [Qemu-devel] [RFC 4/4] net/socket: change net_socket_connect_init to use functions in sockets.h Zihan Yang
2018-01-29 19:47 ` [Qemu-devel] [RFC 0/4] Allow custom socket option in socket_listen and socket_connect no-reply
2018-01-29 20:19 ` no-reply

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=CAKwiv-hsjACjNqPSz36JGPv17UAQr0Utga7Krw7iZ-iCEC9gmQ@mail.gmail.com \
    --to=whois.zihan.yang@gmail.com \
    --cc=berrange@redhat.com \
    --cc=jcody@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mitake.hitoshi@lab.ntt.co.jp \
    --cc=mreitz@redhat.com \
    --cc=namei.unix@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=rjones@redhat.com \
    --cc=sheepdog@lists.wpkg.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).