All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Ottlik <ottlik@fzi.de>
To: Eric Blake <eblake@redhat.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	Anthony Liguori <aliguori@us.ibm.com>,
	qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v3 1/5] util: add socket_set_fast_reuse function which will replace setting SO_REUSEADDR
Date: Tue, 10 Sep 2013 18:23:17 +0200	[thread overview]
Message-ID: <522F4775.1070606@fzi.de> (raw)
In-Reply-To: <522F412F.9030205@redhat.com>

On 10.09.2013 17:56, Eric Blake wrote:
> On 09/10/2013 07:26 AM, Sebastian Ottlik wrote:
>> If a socket is closed it remains in TIME_WAIT state for some time. On operating
>> systems using BSD sockets the endpoint of the socket may not be reused while in
>> this state unless SO_REUSEADDR was set on the socket. On windows on the other
>> hand the default behaviour is to allow reuse (i.e. identical to SO_REUSEADDR on
>> other operating systems) and setting SO_REUSEADDR on a socket allows it to be
>> bound to a endpoint even if the endpoint is already used by another socket
>> independently of the other sockets state. This can even result in undefined
>> behaviour.
>>
>> Many sockets used by QEMU should not block the use of their endpoint after being
>> closed while they are still in TIME_WAIT state. Currently QEMU sets SO_REUSEADDR
>> for such sockets, which can lead to problems on Windows. This patch introduces
>> the function socket_set_fast_reuse that should be used instead of setting
>> SO_REUSEADDR and does the right thing on all operating systems.
>>
>> Signed-off-by: Sebastian Ottlik <ottlik@fzi.de>
>> ---
>> +int socket_set_fast_reuse(int fd)
>> +{
>> +    int val = 1, ret;
>> +
>> +    ret = setsockopt(fd, SOL_SOCKET, SO_REUSEADDR,
>> +                     (const char *)&val, sizeof(val));
>> +
>> +    if (ret < 0) {
>> +        perror("setsockopt(SOL_SOCKET, SO_REUSEADDR)");
>> +    }
> This would be the first use of perror in this file; I'm not sure if that
> is the right function, or if there is a better thing to be using (in
> fact, returning -1 and letting the client decide whether to issue a
> warning may even be better).
>
When I started writing the patch I was going to return the error and lat 
the client handle the issue. But the code in net/socket.c then becomes:

     ret = socket_set_fast_reuse(fd);
     if (ret < 0) {
         perror("setsockopt(SOL_SOCKET, SO_REUSEADDR)");
         closesocket(fd);
         return -1;
     }

Which looked unclean to me, as the code implies assumptions about the 
implementation of socket_set_fast_reuse. One could also call 
perror("socket_set_fast_reuse()") but this would break the convention in 
the surrounding code of passing for the function that failed to perror.

As both approaches were not so great, I moved the error message to 
socket_set_fast_reuse and accepted the side effect, that the other 
places output an error message if something goes wrong. I agree I should 
have been mentioned this change in the commit messages. Also it is 
unlikely the function will fail during normal use of QEMU.

Another approach would be to indeed let the client decide what to do 
with the error and use other error reporting facilities. But I am not 
sure what would be appropriate and how to handle errno in this case, 
which could provide some useful insights.

  reply	other threads:[~2013-09-10 16:23 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-10 13:26 [Qemu-devel] [PATCH v3 0/5] Do not set SO_REUSEADDR on Windows Sebastian Ottlik
2013-09-10 13:26 ` [Qemu-devel] [PATCH v3 1/5] util: add socket_set_fast_reuse function which will replace setting SO_REUSEADDR Sebastian Ottlik
2013-09-10 15:56   ` Eric Blake
2013-09-10 16:23     ` Sebastian Ottlik [this message]
2013-09-10 16:34       ` Eric Blake
2013-09-10 16:39         ` Sebastian Ottlik
2013-09-10 13:26 ` [Qemu-devel] [PATCH v3 2/5] gdbstub: call socket_set_fast_reuse instead of " Sebastian Ottlik
2013-09-10 13:26 ` [Qemu-devel] [PATCH v3 3/5] net: " Sebastian Ottlik
2013-09-10 15:53   ` Eric Blake
2013-09-10 13:26 ` [Qemu-devel] [PATCH v3 4/5] slirp: " Sebastian Ottlik
2013-09-10 15:58   ` Eric Blake
2013-09-10 13:26 ` [Qemu-devel] [PATCH v3 5/5] util: " Sebastian Ottlik

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=522F4775.1070606@fzi.de \
    --to=ottlik@fzi.de \
    --cc=aliguori@us.ibm.com \
    --cc=eblake@redhat.com \
    --cc=jan.kiszka@siemens.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /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.