From: Dan Smith <danms@us.ibm.com>
To: Oren Laadan <orenl@librato.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: Wed, 29 Jul 2009 11:37:39 -0700 [thread overview]
Message-ID: <87vdlbmj2k.fsf@caffeine.danplanet.com> (raw)
In-Reply-To: 4A6F6B19.9010508@librato.com
OL> Hmmm.. what about splice_direct_to_actor() ?
The comments (and code) for that function define that we can't splice
between non-regular files. For now, this would work, but would fail
if you pass a socket as the checkpoint descriptor, as might be the
case in a migration.
OL> Still need to keep it in mind for inet when including those
OL> lingering sockets that don't belong to anyone.
Yep.
OL> This also means that a peer (of a dgram socket) that was closed
OL> will not be checkpointed, so restoring the rcvbuf of the remaining
OL> dgram socket wouldn't work.
Actually, the new algorithm creates the pair when finding the first
socket instead of the second, so I think it will still work. However,
I'll test it and apply some thought to what will happen to the socket
we created to represent the dead one (I think it will die when the
objhash is freed).
OL> Hmm.. then what happens when you have a circular dependency ?
OL> For example, three dgram sockets, A, B and C where: A->B, B->C
OL> and C->A ('->' means connected).
Hmm, hadn't thought of that.
OL> I suspect that sock_unix_restore_connect() will fail, because
OL> neither:
OL> + if (!IS_ERR(this) && !IS_ERR(peer)) {
OL> nor
OL> + } else if ((PTR_ERR(this) == -EINVAL) && (PTR_ERR(peer) == -EINVAL)) {
OL> will hold true, therefore:
OL> + } else {
OL> + ckpt_debug("Order Error\n");
OL> + ret = PTR_ERR(this);
OL> + goto out;
OL> + }
Yeah, but I don't think it will be too hard to add another case to
that condition to handle this. I'll check into it.
--
Dan Smith
IBM Linux Technology Center
email: danms@us.ibm.com
next prev parent reply other threads:[~2009-07-29 18:37 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 [this message]
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
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=87vdlbmj2k.fsf@caffeine.danplanet.com \
--to=danms@us.ibm.com \
--cc=adobriyan@gmail.com \
--cc=containers@lists.osdl.org \
--cc=netdev@vger.kernel.org \
--cc=orenl@librato.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).