mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Yonghong Song <yhs@fb.com>
To: YueHaibing <yuehaibing@huawei.com>,
	"ast@kernel.org" <ast@kernel.org>,
	"daniel@iogearbox.net" <daniel@iogearbox.net>,
	Martin Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
	"sdf@google.com" <sdf@google.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"bpf@vger.kernel.org" <bpf@vger.kernel.org>
Subject: Re: [PATCH bpf-next] bpf: cgroup: Fix build error without CONFIG_NET
Date: Tue, 2 Jul 2019 16:01:16 +0000	[thread overview]
Message-ID: <5911e346-4b78-3a0c-e71a-38456e04e075@fb.com> (raw)
In-Reply-To: <20190702132913.26060-1-yuehaibing@huawei.com>



On 7/2/19 6:29 AM, YueHaibing wrote:
> If CONFIG_NET is not set, gcc building fails:
> 
> kernel/bpf/cgroup.o: In function `cg_sockopt_func_proto':
> cgroup.c:(.text+0x237e): undefined reference to `bpf_sk_storage_get_proto'
> cgroup.c:(.text+0x2394): undefined reference to `bpf_sk_storage_delete_proto'
> kernel/bpf/cgroup.o: In function `__cgroup_bpf_run_filter_getsockopt':
> (.text+0x2a1f): undefined reference to `lock_sock_nested'
> (.text+0x2ca2): undefined reference to `release_sock'
> kernel/bpf/cgroup.o: In function `__cgroup_bpf_run_filter_setsockopt':
> (.text+0x3006): undefined reference to `lock_sock_nested'
> (.text+0x32bb): undefined reference to `release_sock'
> 
> Add CONFIG_NET dependency to fix this.
> 
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Fixes: 0d01da6afc54 ("bpf: implement getsockopt and setsockopt hooks")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
>   init/Kconfig | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/init/Kconfig b/init/Kconfig
> index e2e51b5..341cf2a 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -998,6 +998,7 @@ config CGROUP_PERF
>   config CGROUP_BPF
>   	bool "Support for eBPF programs attached to cgroups"
>   	depends on BPF_SYSCALL
> +	depends on NET
>   	select SOCK_CGROUP_DATA
>   	help
>   	  Allow attaching eBPF programs to a cgroup using the bpf(2)


Adding CGROUP_BPF depending on CONFIG_NET is not a good idea.
There should be really independent.

How about the following change?

-bash-4.4$ git diff
diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
index 76fa0076f20d..0a00eaca6fae 100644
--- a/kernel/bpf/cgroup.c
+++ b/kernel/bpf/cgroup.c
@@ -939,6 +939,7 @@ int __cgroup_bpf_run_filter_sysctl(struct 
ctl_table_header *head,
  }
  EXPORT_SYMBOL(__cgroup_bpf_run_filter_sysctl);

+#ifdef CONFIG_NET
  static bool __cgroup_bpf_prog_array_is_empty(struct cgroup *cgrp,
                                              enum bpf_attach_type 
attach_type)
  {
@@ -1120,6 +1121,7 @@ int __cgroup_bpf_run_filter_getsockopt(struct sock 
*sk, int level,
         return ret;
  }
  EXPORT_SYMBOL(__cgroup_bpf_run_filter_getsockopt);
+#endif

  static ssize_t sysctl_cpy_dir(const struct ctl_dir *dir, char **bufp,
                               size_t *lenp)
@@ -1386,10 +1388,12 @@ static const struct bpf_func_proto *
  cg_sockopt_func_proto(enum bpf_func_id func_id, const struct bpf_prog 
*prog)
  {
         switch (func_id) {
+#ifdef CONFIG_NET
         case BPF_FUNC_sk_storage_get:
                 return &bpf_sk_storage_get_proto;
         case BPF_FUNC_sk_storage_delete:
                 return &bpf_sk_storage_delete_proto;
+#endif
  #ifdef CONFIG_INET
         case BPF_FUNC_tcp_sock:
                 return &bpf_tcp_sock_proto;

Stanislav, you introduced getsockopt and setsockopt hooks which
have this compilation issues if CONFIG_NET=n.
What do you think for the above change?


      parent reply	other threads:[~2019-07-02 16:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-02 13:29 YueHaibing
2019-07-02 15:53 ` Stanislav Fomichev
2019-07-02 16:04   ` Yonghong Song
2019-07-03  3:26     ` Yuehaibing
2019-07-03  8:26     ` [PATCH v2 " YueHaibing
2019-07-03 14:45       ` Yonghong Song
2019-07-08 15:26       ` Daniel Borkmann
2019-07-03  8:01   ` [PATCH " Yuehaibing
2019-07-02 16:01 ` Yonghong Song [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5911e346-4b78-3a0c-e71a-38456e04e075@fb.com \
    --to=yhs@fb.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=kafai@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=sdf@google.com \
    --cc=songliubraving@fb.com \
    --cc=yuehaibing@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®