netdev - Re: [PATCH 5/5] c/r: Add AF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87vdlbmj2k.fsf@caffeine.danplanet.com>
Date:	Wed, 29 Jul 2009 11:37:39 -0700
From:	Dan Smith <danms@...ibm.com>
To:	Oren Laadan <orenl@...rato.com>
Cc:	containers@...ts.osdl.org, Alexey Dobriyan <adobriyan@...il.com>,
	netdev@...r.kernel.org
Subject: Re: [PATCH 5/5] c/r: Add AF_UNIX support (v6)

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@...ibm.com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html