netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Changli Gao <xiaosuo@gmail.com>
To: Neil Brown <neilb@suse.de>
Cc: David Miller <davem@davemloft.net>,
	shemminger@vyatta.com, netdev@vger.kernel.org
Subject: Re: Undefined behaviour of connect(fd, NULL, 0);
Date: Thu, 1 Apr 2010 12:16:43 +0800	[thread overview]
Message-ID: <x2j412e6f7f1003312116rd3b3ba96t31267545efe7660f@mail.gmail.com> (raw)
In-Reply-To: <20100401143805.1f83a161@notabene.brown>

On Thu, Apr 1, 2010 at 11:38 AM, Neil Brown <neilb@suse.de> wrote:
> I'm not sure I'd say that I "want" any particular patch.
> I just want to know what "connect(fd, NULL, 0)" is supposed to do, and to
> have the kernel be consistent in its behaviour.  I'm not really fussed what
> the behaviour is.
>
> I suspect the customer wants that patch you have supplied as it would mean
> they don't need to change their code.  But I only want it if it is "right".
>
> The patch you have provided does what I had assumed Stephen's patch did
> before I actually read it properly.
>
> My feeling is that this patch might be more useful than Stephen's as having
> connect(fd, NULL, 0) do what the customer expects seems useful, where as
> having it do the same as setting AF_UNSPEC doesn't add anything.
>
> I've googled around a bit but cannot find any evidence of anyone passing NULL
> to connect like this, and what documentation I can find doesn't really
> address the issue at all.
>

I found this from man page for connect(2)

       Generally, connection-based protocol sockets may successfully connect()
       only once; connectionless protocol sockets may use  connect()  multiple
       times to change their association.  Connectionless sockets may dissolve
       the association by connecting to an address with the  sa_family  member
       of sockaddr set to AF_UNSPEC (supported on Linux since kernel 2.2).

It only said the meaning of AF_UNSPEC for connectionless sockets, but
not connection sockets like TCP. It means that the behavior of
disconnecting the socket when AF_UNSEPC family address is met is also
undocumented.

The connect() API is a little different. If you try to call connect()
in non-blocking mode, and the API can't connect instantly, it will
return the error code for 'Operation In Progress'. When you call
connect() again, later, it may tell you 'Operation Already In
Progress' to let you know that it's still trying to connect, or it may
give you a successful return code, telling you that the connect has
been made.
from: http://www.scottklement.com/rpg/socktut/nonblocking.html

Someone may use connect() to check if the connection is established or
not. But there is no spec about the addr and addr_len value when
connect(2) is used  this way. Since there is no limit of addr and
addr_len, and we supports addr is NULL to check the status of socket
(Although it is buggy). I think we should treat it like a feature, and
the problem Neil reported is a bug.

-- 
Regards,
Changli Gao(xiaosuo@gmail.com)

  reply	other threads:[~2010-04-01  4:17 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-31 11:36 Undefined behaviour of connect(fd, NULL, 0); Neil Brown
2010-03-31 18:49 ` Stephen Hemminger
2010-03-31 20:24   ` Neil Brown
2010-03-31 21:14     ` Stephen Hemminger
2010-03-31 21:17     ` David Miller
2010-03-31 22:07       ` Neil Brown
2010-04-01  3:00         ` Changli Gao
2010-04-01  3:38           ` Neil Brown
2010-04-01  4:16             ` Changli Gao [this message]
2010-04-01  5:50               ` Changli Gao
2010-04-01  7:23               ` David Miller
2010-04-05  9:23                 ` Changli Gao
2010-04-05 15:56                   ` Eric Dumazet
2010-04-05 16:25                     ` Andreas Schwab
2010-04-05 19:25                   ` David Miller

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=x2j412e6f7f1003312116rd3b3ba96t31267545efe7660f@mail.gmail.com \
    --to=xiaosuo@gmail.com \
    --cc=davem@davemloft.net \
    --cc=neilb@suse.de \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@vyatta.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 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).