Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp7465625ybp; Wed, 16 Oct 2019 09:04:03 -0700 (PDT) X-Google-Smtp-Source: APXvYqz6UuRVAdO8hlXvDq76espCLEuEzL9T2nR2l0S4pTjkDA5QfSIbh4Aw2VkRS/5iBdqlSMty X-Received: by 2002:aa7:db0a:: with SMTP id t10mr19459369eds.113.1571241843834; Wed, 16 Oct 2019 09:04:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571241843; cv=none; d=google.com; s=arc-20160816; b=m12tOJPZsJJnUCH7NAmzBkIapD9A4JPGsj6998R8bwMjcFydyXW7EntLBJjM5W9acM LCcFQmQlcNQFaoANvjxs17u8OWTdRUKerakzaUdi0nUxrCQ2E3aaKlLVIWJl5iesnKKl Qkxh4hzexV3ryZWcX1C4VWnLCsrHvtp8h2ef1MZrKRmC+5l2v1pwfw5Pw9nWm0eN0Rii I9qopBuxcj56Iq81WgGP6LhqM75+O5khMYoSZBllkUNkbs+V3QzflxSYsTSi6VW/qvlc c4VS0QSXJCyGgb8B4ytKZgiLKhNLQ0mJl4+1CxO9lXJVnaYwzwWHrII876s8hjEQJNc+ X8+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:references:cc:to:from:subject; bh=SLevemLx8RMdgJ2Ob2yQ/a12OIPShAQrSePfFgUuCHA=; b=Dle3Xttek1unBkMUOXz0oajK97Og23dqObcs5DlfNCrlU56O2WEBES2zTrmOytI/WT pLCAbKO8FkEw93Y0QzQjH9rrhPAP+yY1C1xtrzWnvvHSYjjg9ccLsd8gHlx4mFyI14I3 pjE1FpHSYJfzdqYQ5CKAxJ0xYLjSkFyexMlK6fLqGAPmWGm5ifmyFsXT4CU7z6EDhnPC xGMbEBYHMxNm5cqjKD6Qgj15suAshyAehyKe82pyP5CrJuplKRVOx1TUnZ9JndpaMNSc gQKl3pcZd9cdgZ9uPIi+I2YAnywwnajXsp8hFMQTXpMYmwYzPuLSb5TN6I47Sll+gejD WkLg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=codethink.co.uk Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id ci21si16045489ejb.320.2019.10.16.09.03.39; Wed, 16 Oct 2019 09:04:03 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=codethink.co.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2393572AbfJPNYq (ORCPT + 99 others); Wed, 16 Oct 2019 09:24:46 -0400 Received: from imap1.codethink.co.uk ([176.9.8.82]:53629 "EHLO imap1.codethink.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729306AbfJPNYq (ORCPT ); Wed, 16 Oct 2019 09:24:46 -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 1iKjI8-0000go-EN; Wed, 16 Oct 2019 14:24:40 +0100 Subject: Re: [Linux-kernel] [PATCH] net: bpf: add static in net/core/filter.c From: Ben Dooks To: Daniel Borkmann Cc: linux-kernel@lists.codethink.co.uk, Song Liu , Jakub Kicinski , Jesper Dangaard Brouer , netdev@vger.kernel.org, John Fastabend , Alexei Starovoitov , Martin KaFai Lau , Yonghong Song , bpf@vger.kernel.org, "David S. Miller" , linux-kernel@vger.kernel.org References: <20191016110446.24622-1-ben.dooks@codethink.co.uk> <20191016122605.GC21367@pc-63.home> <20191016131020.GE21367@pc-63.home> Organization: Codethink Limited. Message-ID: <16a0fe4a-f63a-7e33-62a2-d3dfbccd8f63@codethink.co.uk> Date: Wed, 16 Oct 2019 14:24:39 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 16/10/2019 14:11, Ben Dooks wrote: > 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. Without CONFIG_BPF_SYSCALL, a part of net/core/filter.c is being built but then not declared or used. Should this be split up or the areas not being built be removed? -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html