From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756688AbbCMRJ0 (ORCPT ); Fri, 13 Mar 2015 13:09:26 -0400 Received: from mail-ie0-f172.google.com ([209.85.223.172]:34689 "EHLO mail-ie0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752730AbbCMRJY (ORCPT ); Fri, 13 Mar 2015 13:09:24 -0400 Message-ID: <550319C1.50209@plumgrid.com> Date: Fri, 13 Mar 2015 10:09:21 -0700 From: Alexei Starovoitov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Daniel Borkmann , "David S. Miller" CC: Thomas Graf , linux-api@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next 1/2] bpf: allow extended BPF programs access skb fields References: <1426213271-8363-1-git-send-email-ast@plumgrid.com> <1426213271-8363-2-git-send-email-ast@plumgrid.com> <5502B48B.7040909@iogearbox.net> <55030ED8.4020209@plumgrid.com> <550313B6.2080701@iogearbox.net> In-Reply-To: <550313B6.2080701@iogearbox.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/13/15 9:43 AM, Daniel Borkmann wrote: > On 03/13/2015 05:22 PM, Alexei Starovoitov wrote: >> On 3/13/15 2:57 AM, Daniel Borkmann wrote: >>> On 03/13/2015 03:21 AM, Alexei Starovoitov wrote: >>>> introduce user accessible mirror of in-kernel 'struct sk_buff': >>> >>> For each member, I'd also add BUILD_BUG_ON()s similarly as we have in >>> convert_bpf_extensions(). That way, people won't forget to adjust the >>> code. >> >> I thought about it, but didn't add it, since we already have them >> in the same file several lines above this spot. >> I think one build error per .c file should be enough to attract >> attention. >> Though I'll add a comment to convert_bpf_extensions() that build_bug_on >> errors should be addressed in two places. > > My concern would be that in case the code gets changed, this spot > could easily be overlooked by someone possibly unfamiliar with the > code, since no build error triggers there. > > So I guess it wouldn't hurt or cost us much to also adding the > BUILD_BUG_ON()s there instead of a comment. I think it's overkill, but fine, it's minor. Will add another set of build_bug_ons and see how it looks.