From: Oren Laadan <orenl@librato.com>
To: Dan Smith <danms@us.ibm.com>
Cc: containers@lists.osdl.org, Alexey Dobriyan <adobriyan@gmail.com>,
netdev@vger.kernel.org
Subject: Re: [PATCH 5/5] c/r: Add AF_UNIX support (v6)
Date: Tue, 04 Aug 2009 04:27:27 -0400 [thread overview]
Message-ID: <4A77F0EF.9090602@librato.com> (raw)
In-Reply-To: <878wi6yxui.fsf@caffeine.danplanet.com>
Dan Smith wrote:
> OL> Hmm.. then what happens when you have a circular dependency ? For
> OL> example, three dgram sockets, A, B and C where: A->B, B->C and
> OL> C->A ('->' means connected).
>
> So, I've been cooking up changes to the patch and a test for this
> case. However, it seems like it's not valid, unless I'm missing
> something. The man page for connect() says:
>
> If the socket sockfd is of type SOCK_DGRAM then serv_addr is the
> address to which datagrams are sent by default, and the only address
> from which datagrams are received.
>
> So, even though you can connect() a DGRAM socket and then sendto()
> datagrams to a different location, it doesn't appear that the
> relationship between A and B is really valid, at least the connection
> between A and B is not functional. In fact, in my testing, if you try
> to connect() C back to A, you get "Operation not permitted" because A
> is already connected elsewhere.
Weird ... I have a faint memory of seeing that happen (which is
why I brought it up).
Does this mean that a situation of A->B and B->C is valid only as
long as A->B is done first, otherwise A->B will fail because B will
already be connected to C ?
Then, the other problem is to restore correctly you need to mimic
the behavior of sendto() because of the way the skb references the
original socket for the write-buf accounting :(
In turn, this means that during checkpoint you need to record the
_origin_ of each buffer in the queue of afunix dgram sockets :((
Sigh :(((
Oren.
next prev parent reply other threads:[~2009-08-04 8:27 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1248295301-30930-1-git-send-email-danms@us.ibm.com>
2009-07-22 20:41 ` [PATCH 5/5] c/r: Add AF_UNIX support (v6) Dan Smith
[not found] ` <1248295301-30930-6-git-send-email-danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-07-28 16:54 ` Oren Laadan
2009-07-28 20:34 ` Dan Smith
2009-07-28 21:18 ` Oren Laadan
2009-07-29 13:36 ` Serge E. Hallyn
2009-07-29 14:49 ` Dan Smith
2009-07-29 14:59 ` Serge E. Hallyn
2009-07-29 15:03 ` Dan Smith
2009-07-29 15:34 ` Oren Laadan
2009-07-29 18:37 ` Dan Smith
2009-07-30 15:49 ` Dan Smith
2009-07-30 22:10 ` John Dykstra
2009-07-30 22:12 ` John Dykstra
2009-07-30 22:14 ` Dan Smith
2009-08-04 8:27 ` Oren Laadan [this message]
2009-08-04 15:16 ` Dan Smith
2009-08-04 17:05 ` Oren Laadan
2009-08-04 17:13 ` Dan Smith
2009-07-29 1:56 ` Serge E. Hallyn
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=4A77F0EF.9090602@librato.com \
--to=orenl@librato.com \
--cc=adobriyan@gmail.com \
--cc=containers@lists.osdl.org \
--cc=danms@us.ibm.com \
--cc=netdev@vger.kernel.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).