From mboxrd@z Thu Jan 1 00:00:00 1970 From: Libo Chen Subject: Re: [RFC PATCH net-next 1/4] net: introduce backup_classid to struct skbuff Date: Mon, 6 Jan 2014 16:16:59 +0800 Message-ID: <52CA667B.4090606@huawei.com> References: <52C62A48.1050604@huawei.com> <20140103.003404.1439874071277993396.davem@davemloft.net> <52C656F2.8060803@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <52C656F2.8060803-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: John Fastabend Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, jasowang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kaber-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org, edumazet-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org, ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, David Miller , xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org On 2014/1/3 14:21, John Fastabend wrote: > On 01/02/2014 09:34 PM, David Miller wrote: >> From: Libo Chen >> Date: Fri, 3 Jan 2014 11:11:04 +0800 >> >>> >>> introduce backup_classid to struct skbuff, >>> we can use it to backup sk_classid when net_ns switch. >>> >>> Signed-off-by: Libo Chen >> >> Sorry, no new sk_buff members unless there is absolutely not other >> possible implementation. >> >> sk_buff is too big as-is. > > To get what you want fix the dev_forward_skb() call. But its > not clear to me why you would expect the sock info to be propagated > like this. It seems like an incorrect assumption or a misunderstanding > somewhere. If the virtual link was a physical link you wouldn't expect > to know anything about the senders socket. AFAIK, once the sock is created, sock->sk_classid will be set, see sk_alloc() so I think it is safe. thanks, Libo > > Thanks, > John >