From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 05F98FA372A for ; Wed, 16 Oct 2019 13:11:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DB5BA20663 for ; Wed, 16 Oct 2019 13:11:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390042AbfJPNL6 (ORCPT ); Wed, 16 Oct 2019 09:11:58 -0400 Received: from imap1.codethink.co.uk ([176.9.8.82]:53124 "EHLO imap1.codethink.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391688AbfJPNL6 (ORCPT ); Wed, 16 Oct 2019 09:11:58 -0400 Received: from [167.98.27.226] (helo=[10.35.5.173]) by imap1.codethink.co.uk with esmtpsa (Exim 4.84_2 #1 (Debian)) id 1iKj5l-0000Ji-Ct; Wed, 16 Oct 2019 14:11:53 +0100 Subject: Re: [PATCH] net: bpf: add static in net/core/filter.c To: Daniel Borkmann Cc: linux-kernel@lists.codethink.co.uk, Alexei Starovoitov , Martin KaFai Lau , Song Liu , Yonghong Song , "David S. Miller" , Jakub Kicinski , Jesper Dangaard Brouer , John Fastabend , netdev@vger.kernel.org, bpf@vger.kernel.org, linux-kernel@vger.kernel.org References: <20191016110446.24622-1-ben.dooks@codethink.co.uk> <20191016122605.GC21367@pc-63.home> <20191016131020.GE21367@pc-63.home> From: Ben Dooks Organization: Codethink Limited. Message-ID: Date: Wed, 16 Oct 2019 14:11:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20191016131020.GE21367@pc-63.home> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On 16/10/2019 14:10, Daniel Borkmann wrote: > On Wed, Oct 16, 2019 at 02:02:31PM +0100, Ben Dooks wrote: >> On 16/10/2019 13:26, Daniel Borkmann wrote: >>> On Wed, Oct 16, 2019 at 12:04:46PM +0100, Ben Dooks (Codethink) wrote: >>>> There are a number of structs in net/core/filter.c >>>> that are not exported or declared outside of the >>>> file. Fix the following warnings by making these >>>> all static: >>>> >>>> net/core/filter.c:8465:31: warning: symbol 'sk_filter_verifier_ops' was not declared. Should it be static? >>>> net/core/filter.c:8472:27: warning: symbol 'sk_filter_prog_ops' was not declared. Should it be static? >>> [...] >>>> net/core/filter.c:8935:27: warning: symbol 'sk_reuseport_prog_ops' was not declared. Should it be static? >>>> >>>> Signed-off-by: Ben Dooks >>>> --- >>>> Cc: Alexei Starovoitov >>>> Cc: Daniel Borkmann >>>> Cc: Martin KaFai Lau >>>> Cc: Song Liu >>>> Cc: Yonghong Song >>>> Cc: "David S. Miller" >>>> Cc: Jakub Kicinski >>>> Cc: Jesper Dangaard Brouer >>>> Cc: John Fastabend >>>> Cc: netdev@vger.kernel.org >>>> Cc: bpf@vger.kernel.org >>>> Cc: linux-kernel@vger.kernel.org >>>> --- >>>> net/core/filter.c | 60 +++++++++++++++++++++++------------------------ >>>> 1 file changed, 30 insertions(+), 30 deletions(-) >>>> >>>> diff --git a/net/core/filter.c b/net/core/filter.c >>>> index ed6563622ce3..f7338fee41f8 100644 >>>> --- a/net/core/filter.c >>>> +++ b/net/core/filter.c >>>> @@ -8462,18 +8462,18 @@ static u32 sk_msg_convert_ctx_access(enum bpf_access_type type, >>>> return insn - insn_buf; >>>> } >>>> -const struct bpf_verifier_ops sk_filter_verifier_ops = { >>>> +static const struct bpf_verifier_ops sk_filter_verifier_ops = { >>>> .get_func_proto = sk_filter_func_proto, >>>> .is_valid_access = sk_filter_is_valid_access, >>>> .convert_ctx_access = bpf_convert_ctx_access, >>>> .gen_ld_abs = bpf_gen_ld_abs, >>>> }; >>> >>> Big obvious NAK. I'm puzzled that you try to fix a compile warning, but without >>> even bothering to compile the result after your patch ... >> >> builds fine. maybe some effort to stop this happening again should be made. > > It doesn't build, because they are used/needed outside: Hmm, your config it does, I get /none/ of these warnings. I guess a lot of this is being built whether or not is then used. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html