[PATCH 3/3] Store socket owner with buffers
danms at us.ibm.com
Wed Aug 26 14:44:28 PDT 2009
OL> The concern I raised above is about manipulated checkpoint data
OL> that attempts to make a connected socket to have data from another
OL> (not peer) socket.
OL> Then I realized that since you use the usual send functions, this
OL> _should_ be covered by the existing checks in the unix networking
OL> code itself.
OL> So I wondered if it's worth a comment somewhere, just to let
OL> readers of the code know that this scenario was considered. (Of
OL> course, after verifying that my statement is indeed correct :)
Correct, the checks in sendmsg() and recvmsg() should properly protect
us from sending buffers to sockets that aren't supposed to receive
them (i.e. ones that are connected elsewhere).
OL> Regarding DEAD sockets - the may still be needed if they are the
OL> source of skb's, no ? (of course, whatever they had in receive
OL> buffer should have been discarded).
Right, that's what I'm saying I've updated since this post.
OL> Maybe I need to read the code again. My impression was that when
OL> you checkpoint socket A, and you need B, then you call
OL> checkpoint_obj() on B, from within the processing of
OL> restart-obj() - it gets called automatically when ckpt_read_obj()
OL> sees an object of type CKPT_HDR_OBJREF; there is never an explicit
OL> call. That's why I assumed that it will be called for A and then,
OL> while processing A, it will be called for B, since A will read in
OL> data and the ckpt_obj_read() will see the shared object.
Correct, it's the circular dependency between the sockets and their
buffers that the problem arises.
OL> So I guess it works because you explicitly ckpt_obj_insert() the
OL> sockets to the objhash; Then later restart_obj() inserts them (or
OL> something) again, but the second instance is never actually found
OL> in a lookup/fetch - the first instance is always returned.
I think we've resolved this on IRC just now, or at least, are close to
IBM Linux Technology Center
email: danms at us.ibm.com
More information about the Containers