SH> Does this re-use of tmp make sense? (It only would if SH> dev_alloc_skb() did a generic prealloc for any subsequent SH> skb_clone() which i don't think is the case) No, this is cruft. SH> Also, do you need any kind of lock on the queue to make this walk SH> safe, or do ensure below (sorry i'm slow and haven't gotten there) SH> that all tasks with an open fd for either end of this sock are SH> frozen? Hmm, it seems that holding the lock while processing the queue isn't really the way to go. Perhaps comparing the pid of the other end of the socket against the list in the context is best? SH> what about UNIXCB(skb).creds and .secid? Yep, okay. SH> It looks like the above provides a way around needing SH> CAP_NET_ADMIN to set SOCK_DBG in sock->sk_flags? You can probably SH> fix that by masking it out here, and if a flag in the checkpoint SH> image says it was on originally, then set it below through SH> setsockopt. Yep, okay. SH> Sanity checking on sk_type, sk_state, backlog etc should probably SH> also be added. I check type and state on restart globally and per-protocol. Backlog could use it though too, yeah. Thanks! -- Dan Smith IBM Linux Technology Center email: danms@xxxxxxxxxx _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
