[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <878whzl2cs.fsf@caffeine.danplanet.com>
Date: Tue, 04 Aug 2009 14:02:11 -0700
From: Dan Smith <danms@...ibm.com>
To: "Serge E. Hallyn" <serue@...ibm.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 (v7)
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@...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
Powered by blists - more mailing lists