* Re: [PATCH net-next v4 1/2] bpf/tracing: allow user space to query prog array on the same tp
From: Alexei Starovoitov @ 2017-12-11 19:55 UTC (permalink / raw)
To: Yonghong Song; +Cc: peterz, ast, daniel, netdev, kernel-team
In-Reply-To: <20171211193903.2428317-2-yhs@fb.com>
On Mon, Dec 11, 2017 at 11:39:02AM -0800, Yonghong Song wrote:
> Commit e87c6bc3852b ("bpf: permit multiple bpf attachments
> for a single perf event") added support to attach multiple
> bpf programs to a single perf event.
> Although this provides flexibility, users may want to know
> what other bpf programs attached to the same tp interface.
> Besides getting visibility for the underlying bpf system,
> such information may also help consolidate multiple bpf programs,
> understand potential performance issues due to a large array,
> and debug (e.g., one bpf program which overwrites return code
> may impact subsequent program results).
>
> Commit 2541517c32be ("tracing, perf: Implement BPF programs
> attached to kprobes") utilized the existing perf ioctl
> interface and added the command PERF_EVENT_IOC_SET_BPF
> to attach a bpf program to a tracepoint. This patch adds a new
> ioctl command, given a perf event fd, to query the bpf program
> array attached to the same perf tracepoint event.
>
> The new uapi ioctl command:
> PERF_EVENT_IOC_QUERY_BPF
>
> The new uapi/linux/perf_event.h structure:
> struct perf_event_query_bpf {
> __u32 ids_len;
> __u32 prog_cnt;
> __u32 ids[0];
> };
>
> User space provides buffer "ids" for kernel to copy to.
> When returning from the kernel, the number of available
> programs in the array is set in "prog_cnt".
>
> The usage:
> struct perf_event_query_bpf *query = malloc(...);
> query.ids_len = ids_len;
> err = ioctl(pmu_efd, PERF_EVENT_IOC_QUERY_BPF, &query);
> if (err == 0) {
> /* query.prog_cnt is the number of available progs,
> * number of progs in ids: (ids_len == 0) ? 0 : query.prog_cnt
> */
> } else if (errno == ENOSPC) {
> /* query.ids_len number of progs copied,
> * query.prog_cnt is the number of available progs
> */
> } else {
> /* other errors */
> }
>
> Signed-off-by: Yonghong Song <yhs@fb.com>
> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Alexei Starovoitov <ast@kernel.org>
^ permalink raw reply
* Re: [PATCH net-next v2 5/6] net: qualcomm: rmnet: Allow to configure flags for new devices
From: Dan Williams @ 2017-12-11 19:54 UTC (permalink / raw)
To: Subash Abhinov Kasiviswanathan, davem, netdev
In-Reply-To: <1512853110-4893-6-git-send-email-subashab@codeaurora.org>
On Sat, 2017-12-09 at 13:58 -0700, Subash Abhinov Kasiviswanathan
wrote:
> Add an option to configure the rmnet aggregation and command features
> on device creation. This is achieved by using the vlan flags option.
Still seems kinda odd to overload IFLA_VLAN_FLAGS to carry
RMNET_INGRESS/EGRESS_FORMAT_* flags, but I'll leave that decision to
others...
Dan
> Signed-off-by: Subash Abhinov Kasiviswanathan
> <subashab@codeaurora.org>
> ---
> drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c | 16
> +++++++++++++---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c
> b/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c
> index 5e530db..2f5f661 100644
> --- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c
> +++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c
> @@ -177,11 +177,20 @@ static int rmnet_newlink(struct net *src_net,
> struct net_device *dev,
> if (err)
> goto err2;
>
> - netdev_dbg(dev, "data format [ingress 0x%08X]\n",
> ingress_format);
> - port->ingress_data_format = ingress_format;
> port->rmnet_mode = mode;
>
> hlist_add_head_rcu(&ep->hlnode, &port->muxed_ep[mux_id]);
> +
> + if (data[IFLA_VLAN_FLAGS]) {
> + struct ifla_vlan_flags *flags;
> +
> + flags = nla_data(data[IFLA_VLAN_FLAGS]);
> + ingress_format = flags->flags & flags->mask;
> + }
> +
> + netdev_dbg(dev, "data format [ingress 0x%08X]\n",
> ingress_format);
> + port->ingress_data_format = ingress_format;
> +
> return 0;
>
> err2:
> @@ -312,7 +321,8 @@ static int rmnet_rtnl_validate(struct nlattr
> *tb[], struct nlattr *data[],
>
> static size_t rmnet_get_size(const struct net_device *dev)
> {
> - return nla_total_size(2); /* IFLA_VLAN_ID */
> + return nla_total_size(2) /* IFLA_VLAN_ID */ +
> + nla_total_size(sizeof(struct ifla_vlan_flags)); /*
> IFLA_VLAN_FLAGS */
> }
>
> struct rtnl_link_ops rmnet_link_ops __read_mostly = {
^ permalink raw reply
* Re: [PATCH] selftests: bpf: Adding config fragment CONFIG_CGROUP_BPF=y
From: Roman Gushchin @ 2017-12-11 19:41 UTC (permalink / raw)
To: Naresh Kamboju; +Cc: netdev, shuahkh, shuah, linux-kselftest
In-Reply-To: <1513020323-29591-1-git-send-email-naresh.kamboju@linaro.org>
Hi Naresh,
Looks good!
Thanks!
On Tue, Dec 12, 2017 at 12:55:23AM +0530, Naresh Kamboju wrote:
> CONFIG_CGROUP_BPF=y is required for test_dev_cgroup test case.
>
> Signed-off-by: Naresh Kamboju <naresh.kamboju@linaro.org>
> ---
> tools/testing/selftests/bpf/config | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tools/testing/selftests/bpf/config b/tools/testing/selftests/bpf/config
> index 52d53ed..9d48973 100644
> --- a/tools/testing/selftests/bpf/config
> +++ b/tools/testing/selftests/bpf/config
> @@ -3,3 +3,4 @@ CONFIG_BPF_SYSCALL=y
> CONFIG_NET_CLS_BPF=m
> CONFIG_BPF_EVENTS=y
> CONFIG_TEST_BPF=m
> +CONFIG_CGROUP_BPF=y
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH] Revert "ravb: add workaround for clock when resuming with WoL enabled"
From: Sergei Shtylyov @ 2017-12-11 19:39 UTC (permalink / raw)
To: Geert Uytterhoeven, David S . Miller, Niklas Söderlund
Cc: netdev, linux-renesas-soc
In-Reply-To: <1512982449-11051-1-git-send-email-geert+renesas@glider.be>
Hello!
On 12/11/2017 11:54 AM, Geert Uytterhoeven wrote:
> This reverts commit fbf3d034f2ff6264183cfa6845770e8cc2a986c8.
>
> As of commit 560869100b99a3da ("clk: renesas: cpg-mssr: Restore module
> clocks during resume"), the workaround is no longer needed.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH net-next v4 1/2] bpf/tracing: allow user space to query prog array on the same tp
From: Yonghong Song @ 2017-12-11 19:39 UTC (permalink / raw)
To: peterz, ast, daniel, netdev; +Cc: kernel-team
In-Reply-To: <20171211193903.2428317-1-yhs@fb.com>
Commit e87c6bc3852b ("bpf: permit multiple bpf attachments
for a single perf event") added support to attach multiple
bpf programs to a single perf event.
Although this provides flexibility, users may want to know
what other bpf programs attached to the same tp interface.
Besides getting visibility for the underlying bpf system,
such information may also help consolidate multiple bpf programs,
understand potential performance issues due to a large array,
and debug (e.g., one bpf program which overwrites return code
may impact subsequent program results).
Commit 2541517c32be ("tracing, perf: Implement BPF programs
attached to kprobes") utilized the existing perf ioctl
interface and added the command PERF_EVENT_IOC_SET_BPF
to attach a bpf program to a tracepoint. This patch adds a new
ioctl command, given a perf event fd, to query the bpf program
array attached to the same perf tracepoint event.
The new uapi ioctl command:
PERF_EVENT_IOC_QUERY_BPF
The new uapi/linux/perf_event.h structure:
struct perf_event_query_bpf {
__u32 ids_len;
__u32 prog_cnt;
__u32 ids[0];
};
User space provides buffer "ids" for kernel to copy to.
When returning from the kernel, the number of available
programs in the array is set in "prog_cnt".
The usage:
struct perf_event_query_bpf *query = malloc(...);
query.ids_len = ids_len;
err = ioctl(pmu_efd, PERF_EVENT_IOC_QUERY_BPF, &query);
if (err == 0) {
/* query.prog_cnt is the number of available progs,
* number of progs in ids: (ids_len == 0) ? 0 : query.prog_cnt
*/
} else if (errno == ENOSPC) {
/* query.ids_len number of progs copied,
* query.prog_cnt is the number of available progs
*/
} else {
/* other errors */
}
Signed-off-by: Yonghong Song <yhs@fb.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
include/linux/bpf.h | 4 ++++
include/uapi/linux/perf_event.h | 22 ++++++++++++++++++++++
kernel/bpf/core.c | 21 +++++++++++++++++++++
kernel/events/core.c | 3 +++
kernel/trace/bpf_trace.c | 23 +++++++++++++++++++++++
5 files changed, 73 insertions(+)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index e55e425..f812ac5 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -254,6 +254,7 @@ typedef unsigned long (*bpf_ctx_copy_t)(void *dst, const void *src,
u64 bpf_event_output(struct bpf_map *map, u64 flags, void *meta, u64 meta_size,
void *ctx, u64 ctx_size, bpf_ctx_copy_t ctx_copy);
+int bpf_event_query_prog_array(struct perf_event *event, void __user *info);
int bpf_prog_test_run_xdp(struct bpf_prog *prog, const union bpf_attr *kattr,
union bpf_attr __user *uattr);
@@ -285,6 +286,9 @@ int bpf_prog_array_copy_to_user(struct bpf_prog_array __rcu *progs,
void bpf_prog_array_delete_safe(struct bpf_prog_array __rcu *progs,
struct bpf_prog *old_prog);
+int bpf_prog_array_copy_info(struct bpf_prog_array __rcu *array,
+ __u32 __user *prog_ids, u32 request_cnt,
+ __u32 __user *prog_cnt);
int bpf_prog_array_copy(struct bpf_prog_array __rcu *old_array,
struct bpf_prog *exclude_prog,
struct bpf_prog *include_prog,
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index b9a4953..7695336 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -418,6 +418,27 @@ struct perf_event_attr {
__u16 __reserved_2; /* align to __u64 */
};
+/*
+ * Structure used by below PERF_EVENT_IOC_QUERY_BPF command
+ * to query bpf programs attached to the same perf tracepoint
+ * as the given perf event.
+ */
+struct perf_event_query_bpf {
+ /*
+ * The below ids array length
+ */
+ __u32 ids_len;
+ /*
+ * Set by the kernel to indicate the number of
+ * available programs
+ */
+ __u32 prog_cnt;
+ /*
+ * User provided buffer to store program ids
+ */
+ __u32 ids[0];
+};
+
#define perf_flags(attr) (*(&(attr)->read_format + 1))
/*
@@ -433,6 +454,7 @@ struct perf_event_attr {
#define PERF_EVENT_IOC_ID _IOR('$', 7, __u64 *)
#define PERF_EVENT_IOC_SET_BPF _IOW('$', 8, __u32)
#define PERF_EVENT_IOC_PAUSE_OUTPUT _IOW('$', 9, __u32)
+#define PERF_EVENT_IOC_QUERY_BPF _IOWR('$', 10, struct perf_event_query_bpf *)
enum perf_event_ioc_flags {
PERF_IOC_FLAG_GROUP = 1U << 0,
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 86b50aa..b16c6f8 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -1462,6 +1462,8 @@ int bpf_prog_array_copy_to_user(struct bpf_prog_array __rcu *progs,
rcu_read_lock();
prog = rcu_dereference(progs)->progs;
for (; *prog; prog++) {
+ if (*prog == &dummy_bpf_prog.prog)
+ continue;
id = (*prog)->aux->id;
if (copy_to_user(prog_ids + i, &id, sizeof(id))) {
rcu_read_unlock();
@@ -1545,6 +1547,25 @@ int bpf_prog_array_copy(struct bpf_prog_array __rcu *old_array,
return 0;
}
+int bpf_prog_array_copy_info(struct bpf_prog_array __rcu *array,
+ __u32 __user *prog_ids, u32 request_cnt,
+ __u32 __user *prog_cnt)
+{
+ u32 cnt = 0;
+
+ if (array)
+ cnt = bpf_prog_array_length(array);
+
+ if (copy_to_user(prog_cnt, &cnt, sizeof(cnt)))
+ return -EFAULT;
+
+ /* return early if user requested only program count or nothing to copy */
+ if (!request_cnt || !cnt)
+ return 0;
+
+ return bpf_prog_array_copy_to_user(array, prog_ids, request_cnt);
+}
+
static void bpf_prog_free_deferred(struct work_struct *work)
{
struct bpf_prog_aux *aux;
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 4df5b69..53c65fb 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -4723,6 +4723,9 @@ static long _perf_ioctl(struct perf_event *event, unsigned int cmd, unsigned lon
rcu_read_unlock();
return 0;
}
+
+ case PERF_EVENT_IOC_QUERY_BPF:
+ return bpf_event_query_prog_array(event, (void __user *)arg);
default:
return -ENOTTY;
}
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index 0ce99c3..b143f2a 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -820,3 +820,26 @@ void perf_event_detach_bpf_prog(struct perf_event *event)
unlock:
mutex_unlock(&bpf_event_mutex);
}
+
+int bpf_event_query_prog_array(struct perf_event *event, void __user *info)
+{
+ struct perf_event_query_bpf __user *uquery = info;
+ struct perf_event_query_bpf query = {};
+ int ret;
+
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM;
+ if (event->attr.type != PERF_TYPE_TRACEPOINT)
+ return -EINVAL;
+ if (copy_from_user(&query, uquery, sizeof(query)))
+ return -EFAULT;
+
+ mutex_lock(&bpf_event_mutex);
+ ret = bpf_prog_array_copy_info(event->tp_event->prog_array,
+ uquery->ids,
+ query.ids_len,
+ &uquery->prog_cnt);
+ mutex_unlock(&bpf_event_mutex);
+
+ return ret;
+}
--
2.9.5
^ permalink raw reply related
* [PATCH net-next v4 2/2] bpf/tracing: add a bpf test for new ioctl query interface
From: Yonghong Song @ 2017-12-11 19:39 UTC (permalink / raw)
To: peterz, ast, daniel, netdev; +Cc: kernel-team
In-Reply-To: <20171211193903.2428317-1-yhs@fb.com>
Added a subtest in test_progs. The tracepoint is
sched/sched_switch. Multiple bpf programs are attached to
this tracepoint and the query interface is exercised.
Signed-off-by: Yonghong Song <yhs@fb.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
tools/include/uapi/linux/perf_event.h | 22 +++++
tools/testing/selftests/bpf/Makefile | 2 +-
tools/testing/selftests/bpf/test_progs.c | 134 ++++++++++++++++++++++++++
tools/testing/selftests/bpf/test_tracepoint.c | 26 +++++
4 files changed, 183 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/bpf/test_tracepoint.c
diff --git a/tools/include/uapi/linux/perf_event.h b/tools/include/uapi/linux/perf_event.h
index b9a4953..7695336 100644
--- a/tools/include/uapi/linux/perf_event.h
+++ b/tools/include/uapi/linux/perf_event.h
@@ -418,6 +418,27 @@ struct perf_event_attr {
__u16 __reserved_2; /* align to __u64 */
};
+/*
+ * Structure used by below PERF_EVENT_IOC_QUERY_BPF command
+ * to query bpf programs attached to the same perf tracepoint
+ * as the given perf event.
+ */
+struct perf_event_query_bpf {
+ /*
+ * The below ids array length
+ */
+ __u32 ids_len;
+ /*
+ * Set by the kernel to indicate the number of
+ * available programs
+ */
+ __u32 prog_cnt;
+ /*
+ * User provided buffer to store program ids
+ */
+ __u32 ids[0];
+};
+
#define perf_flags(attr) (*(&(attr)->read_format + 1))
/*
@@ -433,6 +454,7 @@ struct perf_event_attr {
#define PERF_EVENT_IOC_ID _IOR('$', 7, __u64 *)
#define PERF_EVENT_IOC_SET_BPF _IOW('$', 8, __u32)
#define PERF_EVENT_IOC_PAUSE_OUTPUT _IOW('$', 9, __u32)
+#define PERF_EVENT_IOC_QUERY_BPF _IOWR('$', 10, struct perf_event_query_bpf *)
enum perf_event_ioc_flags {
PERF_IOC_FLAG_GROUP = 1U << 0,
diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
index f309ab9..b177c55 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -29,7 +29,7 @@ TEST_GEN_PROGS = test_verifier test_tag test_maps test_lru_map test_lpm_map test
TEST_GEN_FILES = test_pkt_access.o test_xdp.o test_l4lb.o test_tcp_estats.o test_obj_id.o \
test_pkt_md_access.o test_xdp_redirect.o test_xdp_meta.o sockmap_parse_prog.o \
- sockmap_verdict_prog.o dev_cgroup.o sample_ret0.o
+ sockmap_verdict_prog.o dev_cgroup.o sample_ret0.o test_tracepoint.o
TEST_PROGS := test_kmod.sh test_xdp_redirect.sh test_xdp_meta.sh \
test_offload.py
diff --git a/tools/testing/selftests/bpf/test_progs.c b/tools/testing/selftests/bpf/test_progs.c
index 6942753..1e0479a 100644
--- a/tools/testing/selftests/bpf/test_progs.c
+++ b/tools/testing/selftests/bpf/test_progs.c
@@ -21,8 +21,10 @@ typedef __u16 __sum16;
#include <linux/ipv6.h>
#include <linux/tcp.h>
#include <linux/filter.h>
+#include <linux/perf_event.h>
#include <linux/unistd.h>
+#include <sys/ioctl.h>
#include <sys/wait.h>
#include <sys/resource.h>
#include <sys/types.h>
@@ -617,6 +619,137 @@ static void test_obj_name(void)
}
}
+static void test_tp_attach_query(void)
+{
+ const int num_progs = 3;
+ int i, j, bytes, efd, err, prog_fd[num_progs], pmu_fd[num_progs];
+ __u32 duration = 0, info_len, saved_prog_ids[num_progs];
+ const char *file = "./test_tracepoint.o";
+ struct perf_event_query_bpf *query;
+ struct perf_event_attr attr = {};
+ struct bpf_object *obj[num_progs];
+ struct bpf_prog_info prog_info;
+ char buf[256];
+
+ snprintf(buf, sizeof(buf),
+ "/sys/kernel/debug/tracing/events/sched/sched_switch/id");
+ efd = open(buf, O_RDONLY, 0);
+ if (CHECK(efd < 0, "open", "err %d errno %d\n", efd, errno))
+ return;
+ bytes = read(efd, buf, sizeof(buf));
+ close(efd);
+ if (CHECK(bytes <= 0 || bytes >= sizeof(buf),
+ "read", "bytes %d errno %d\n", bytes, errno))
+ return;
+
+ attr.config = strtol(buf, NULL, 0);
+ attr.type = PERF_TYPE_TRACEPOINT;
+ attr.sample_type = PERF_SAMPLE_RAW | PERF_SAMPLE_CALLCHAIN;
+ attr.sample_period = 1;
+ attr.wakeup_events = 1;
+
+ query = (struct perf_event_query_bpf *)malloc(sizeof(struct perf_event_query_bpf) +
+ sizeof(__u32) * num_progs);
+ for (i = 0; i < num_progs; i++) {
+ err = bpf_prog_load(file, BPF_PROG_TYPE_TRACEPOINT, &obj[i],
+ &prog_fd[i]);
+ if (CHECK(err, "prog_load", "err %d errno %d\n", err, errno))
+ goto cleanup1;
+
+ bzero(&prog_info, sizeof(prog_info));
+ prog_info.jited_prog_len = 0;
+ prog_info.xlated_prog_len = 0;
+ prog_info.nr_map_ids = 0;
+ info_len = sizeof(prog_info);
+ err = bpf_obj_get_info_by_fd(prog_fd[i], &prog_info, &info_len);
+ if (CHECK(err, "bpf_obj_get_info_by_fd", "err %d errno %d\n",
+ err, errno))
+ goto cleanup1;
+ saved_prog_ids[i] = prog_info.id;
+
+ pmu_fd[i] = syscall(__NR_perf_event_open, &attr, -1 /* pid */,
+ 0 /* cpu 0 */, -1 /* group id */,
+ 0 /* flags */);
+ if (CHECK(pmu_fd[i] < 0, "perf_event_open", "err %d errno %d\n",
+ pmu_fd[i], errno))
+ goto cleanup2;
+ err = ioctl(pmu_fd[i], PERF_EVENT_IOC_ENABLE, 0);
+ if (CHECK(err, "perf_event_ioc_enable", "err %d errno %d\n",
+ err, errno))
+ goto cleanup3;
+
+ if (i == 0) {
+ /* check NULL prog array query */
+ query->ids_len = num_progs;
+ err = ioctl(pmu_fd[i], PERF_EVENT_IOC_QUERY_BPF, query);
+ if (CHECK(err || query->prog_cnt != 0,
+ "perf_event_ioc_query_bpf",
+ "err %d errno %d query->prog_cnt %u\n",
+ err, errno, query->prog_cnt))
+ goto cleanup3;
+ }
+
+ err = ioctl(pmu_fd[i], PERF_EVENT_IOC_SET_BPF, prog_fd[i]);
+ if (CHECK(err, "perf_event_ioc_set_bpf", "err %d errno %d\n",
+ err, errno))
+ goto cleanup3;
+
+ if (i == 1) {
+ /* try to get # of programs only */
+ query->ids_len = 0;
+ err = ioctl(pmu_fd[i], PERF_EVENT_IOC_QUERY_BPF, query);
+ if (CHECK(err || query->prog_cnt != 2,
+ "perf_event_ioc_query_bpf",
+ "err %d errno %d query->prog_cnt %u\n",
+ err, errno, query->prog_cnt))
+ goto cleanup3;
+
+ /* try a few negative tests */
+ /* invalid query pointer */
+ err = ioctl(pmu_fd[i], PERF_EVENT_IOC_QUERY_BPF,
+ (struct perf_event_query_bpf *)0x1);
+ if (CHECK(!err || errno != EFAULT,
+ "perf_event_ioc_query_bpf",
+ "err %d errno %d\n", err, errno))
+ goto cleanup3;
+
+ /* no enough space */
+ query->ids_len = 1;
+ err = ioctl(pmu_fd[i], PERF_EVENT_IOC_QUERY_BPF, query);
+ if (CHECK(!err || errno != ENOSPC || query->prog_cnt != 2,
+ "perf_event_ioc_query_bpf",
+ "err %d errno %d query->prog_cnt %u\n",
+ err, errno, query->prog_cnt))
+ goto cleanup3;
+ }
+
+ query->ids_len = num_progs;
+ err = ioctl(pmu_fd[i], PERF_EVENT_IOC_QUERY_BPF, query);
+ if (CHECK(err || query->prog_cnt != (i + 1),
+ "perf_event_ioc_query_bpf",
+ "err %d errno %d query->prog_cnt %u\n",
+ err, errno, query->prog_cnt))
+ goto cleanup3;
+ for (j = 0; j < i + 1; j++)
+ if (CHECK(saved_prog_ids[j] != query->ids[j],
+ "perf_event_ioc_query_bpf",
+ "#%d saved_prog_id %x query prog_id %x\n",
+ j, saved_prog_ids[j], query->ids[j]))
+ goto cleanup3;
+ }
+
+ i = num_progs - 1;
+ for (; i >= 0; i--) {
+ cleanup3:
+ ioctl(pmu_fd[i], PERF_EVENT_IOC_DISABLE);
+ cleanup2:
+ close(pmu_fd[i]);
+ cleanup1:
+ bpf_object__close(obj[i]);
+ }
+ free(query);
+}
+
int main(void)
{
struct rlimit rinf = { RLIM_INFINITY, RLIM_INFINITY };
@@ -630,6 +763,7 @@ int main(void)
test_bpf_obj_id();
test_pkt_md_access();
test_obj_name();
+ test_tp_attach_query();
printf("Summary: %d PASSED, %d FAILED\n", pass_cnt, error_cnt);
return error_cnt ? EXIT_FAILURE : EXIT_SUCCESS;
diff --git a/tools/testing/selftests/bpf/test_tracepoint.c b/tools/testing/selftests/bpf/test_tracepoint.c
new file mode 100644
index 0000000..04bf084
--- /dev/null
+++ b/tools/testing/selftests/bpf/test_tracepoint.c
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2017 Facebook
+
+#include <linux/bpf.h>
+#include "bpf_helpers.h"
+
+/* taken from /sys/kernel/debug/tracing/events/sched/sched_switch/format */
+struct sched_switch_args {
+ unsigned long long pad;
+ char prev_comm[16];
+ int prev_pid;
+ int prev_prio;
+ long long prev_state;
+ char next_comm[16];
+ int next_pid;
+ int next_prio;
+};
+
+SEC("tracepoint/sched/sched_switch")
+int oncpu(struct sched_switch_args *ctx)
+{
+ return 0;
+}
+
+char _license[] SEC("license") = "GPL";
+__u32 _version SEC("version") = 1; /* ignored by tracepoints, required by libbpf.a */
--
2.9.5
^ permalink raw reply related
* [PATCH net-next v4 0/2] bpf/tracing: allow user space to query prog array on the same tp
From: Yonghong Song @ 2017-12-11 19:39 UTC (permalink / raw)
To: peterz, ast, daniel, netdev; +Cc: kernel-team
Commit e87c6bc3852b ("bpf: permit multiple bpf attachments
for a single perf event") added support to attach multiple
bpf programs to a single perf event. Given a perf event
(kprobe, uprobe, or kernel tracepoint), the perf ioctl interface
is used to query bpf programs attached to the same trace event.
There already exists a BPF_PROG_QUERY command for introspection
currently used by cgroup+bpf. We did have an implementation for
querying tracepoint+bpf through the same interface. However, it
looks cleaner to use ioctl() style of api here, since attaching
bpf prog to tracepoint/kuprobe is also done via ioctl.
Patch #1 had the core implementation and patch #2 added
a test case in tools bpf selftests suite.
Changelogs:
v3 -> v4:
- Fix a compilation error with newer gcc like 6.3.1 while
old gcc 4.8.5 is okay. I was using &uquery->ids to represent
the address to the ids array to make it explicit that the
address is passed, and this syntax is rightly rejected
by gcc 6.3.1.
v2 -> v3:
- Change uapi structure perf_event_query_bpf to be more
clearer based on Peter's suggestion, and adjust
other codes accordingly.
v1 -> v2:
- Rebase on top of net-next.
- Use existing bpf_prog_array_length function instead of
implementing the same functionality in function
bpf_prog_array_copy_info.
Yonghong Song (2):
bpf/tracing: allow user space to query prog array on the same tp
bpf/tracing: add a bpf test for new ioctl query interface
include/linux/bpf.h | 4 +
include/uapi/linux/perf_event.h | 22 +++++
kernel/bpf/core.c | 21 ++++
kernel/events/core.c | 3 +
kernel/trace/bpf_trace.c | 23 +++++
tools/include/uapi/linux/perf_event.h | 22 +++++
tools/testing/selftests/bpf/Makefile | 2 +-
tools/testing/selftests/bpf/test_progs.c | 134 ++++++++++++++++++++++++++
tools/testing/selftests/bpf/test_tracepoint.c | 26 +++++
9 files changed, 256 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/bpf/test_tracepoint.c
--
2.9.5
^ permalink raw reply
* Re: [PATCH next] ipvlan: add L2 check for packets arriving via virtual devices
From: Mahesh Bandewar (महेश बंडेवार) @ 2017-12-11 19:38 UTC (permalink / raw)
To: David Miller; +Cc: mahesh, linux-netdev, Eric Dumazet, amit.sikka
In-Reply-To: <20171211.111523.656092715140972680.davem@davemloft.net>
On Mon, Dec 11, 2017 at 8:15 AM, David Miller <davem@davemloft.net> wrote:
> From: Mahesh Bandewar <mahesh@bandewar.net>
> Date: Thu, 7 Dec 2017 15:15:43 -0800
>
>> From: Mahesh Bandewar <maheshb@google.com>
>>
>> Packets that don't have dest mac as the mac of the master device should
>> not be entertained by the IPvlan rx-handler. This is mostly true as the
>> packet path mostly takes care of that, except when the master device is
>> a virtual device. As demonstrated in the following case -
> ...
>> This patch adds that missing check in the IPvlan rx-handler.
>>
>> Reported-by: Amit Sikka <amit.sikka@ericsson.com>
>> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
>
> Applied, but it's a shame that the data plane takes on this new MAC
> compare operation.
Your comment made me think little more about this and a discussion
with Eric kind of put things in perspective. eth_type_trans() does the
right thing and sets the packet_type correctly (when .ndo_xmit of veth
is called). However IPvlan is over-aggressive in packet scrubbing and
that scrub changes packet type. This causes the actual problem. It's
not clear to me why skb_scrub_packet() changes the packet type to
PACKET_HOST unconditionally? But that's another issue.
I'll send another patch to remove excessive scrubbing in IPvlan and
revert of this patch so that this additional comparison (though not
expensive!) can be avoided.
Thanks,
--mahesh..
^ permalink raw reply
* Re: RFC(v2): Audit Kernel Container IDs
From: Steve Grubb @ 2017-12-11 19:37 UTC (permalink / raw)
To: linux-audit-H+wXaHxf7aLQT0dZR+AlfA
Cc: Eric Paris, Casey Schaufler, Mickaël Salaün,
Richard Guy Briggs, cgroups-u79uwXL29TY76Z2rM5mHXA,
Linux Containers, Linux API, Linux FS Devel, Linux Kernel,
Linux Network Development
In-Reply-To: <1513009857.6310.337.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Monday, December 11, 2017 11:30:57 AM EST Eric Paris wrote:
> > Because a container doesn't have to use namespaces to be a container
> > you still need a mechanism for a process to declare that it is in
> > fact
> > in a container, and to identify the container.
>
> I like the idea but I'm still tossing it around in my head (and
> thinking about Casey's statement too). Lets say we have a 'docker-like'
> container with pid=100 netns=X,userns=Y,mountns=Z. If I'm on the host
> in all init namespaces and I run
> nsenter -t 100 -n ip link set eth0 promisc on
> How should this be logged?
If it is a normal process, then everything would match the init name space and
you wouldn't have entered a container. If it were a container, any generated
event should have the container ID from registration attached to it.
> Did this command run in it's own 'container' unrelated to the 'docker-like'
> container?
That should be determined by what's in the task struct.
-Steve
^ permalink raw reply
* Re: [PATCH v2] vsock.7: document VSOCK socket address family
From: Michael Kerrisk (man-pages) @ 2017-12-11 19:32 UTC (permalink / raw)
To: Jorgen S. Hansen, Stefan Hajnoczi
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w,
linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
G. Branden Robinson, Dexuan Cui
In-Reply-To: <19A05993-CB7C-4A7F-8ECF-CE55B1EE9619-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
On 12/06/2017 03:06 PM, Jorgen S. Hansen wrote:
>
>> On Dec 5, 2017, at 11:56 AM, Stefan Hajnoczi <stefanha-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>
>> The AF_VSOCK address family has been available since Linux 3.9 without a
>> corresponding man page.
>>
>> This patch adds vsock.7 and describes its use along the same lines as
>> existing ip.7, unix.7, and netlink.7 man pages.
>>
>> CC: Jorgen Hansen <jhansen-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
>> CC: Dexuan Cui <decui-0li6OtcxBFHby3iVrkZq2A@public.gmane.org>
>> Signed-off-by: Stefan Hajnoczi <stefanha-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> ---
>> man7/vsock.7 | 180 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 180 insertions(+)
>> create mode 100644 man7/vsock.7
>>
>> diff --git a/man7/vsock.7 b/man7/vsock.7
>> new file mode 100644
>> index 000000000..46dc561f5
>> --- /dev/null
>> +++ b/man7/vsock.7
>> @@ -0,0 +1,180 @@
>> +.TH VSOCK 7 2017-11-30 "Linux" "Linux Programmer's Manual"
>> +.SH NAME
>> +vsock \- Linux VSOCK address family
>> +.SH SYNOPSIS
>> +.B #include <sys/socket.h>
>> +.br
>> +.B #include <linux/vm_sockets.h>
>> +.PP
>> +.IB stream_socket " = socket(AF_VSOCK, SOCK_STREAM, 0);"
>> +.br
>> +.IB datagram_socket " = socket(AF_VSOCK, SOCK_DGRAM, 0);"
>> +.SH DESCRIPTION
>> +The VSOCK address family facilitates communication between virtual machines and
>> +the host they are running on. This address family is used by guest agents and
>> +hypervisor services that need a communications channel that is independent of
>> +virtual machine network configuration.
>> +.PP
>> +Valid socket types are
>> +.B SOCK_STREAM
>> +and
>> +.BR SOCK_DGRAM .
>> +.B SOCK_STREAM
>> +provides connection-oriented byte streams with guaranteed, in-order delivery.
>> +.B SOCK_DGRAM
>> +provides a connectionless datagram packet service with best-effort delivery and
>> +best-effort ordering. Availability of these socket types is dependent on the
>> +underlying hypervisor.
>> +.PP
>> +A new socket is created with
>> +.PP
>> + socket(AF_VSOCK, socket_type, 0);
>> +.PP
>> +When a process wants to establish a connection it calls
>> +.BR connect (2)
>> +with a given destination socket address. The socket is automatically bound to
>> +a free port if unbound.
>> +.PP
>> +A process can listen for incoming connections by first binding to a socket
>> +address using
>> +.BR bind (2)
>> +and then calling
>> +.BR listen (2).
>> +.PP
>> +Data is transferred using the usual
>> +.BR send (2)
>> +and
>> +.BR recv (2)
>> +family of socket system calls.
>> +.SS Address format
>> +A socket address is defined as a combination of a 32-bit Context Identifier
>> +(CID) and a 32-bit port number. The CID identifies the source or destination,
>> +which is either a virtual machine or the host. The port number differentiates
>> +between multiple services running on a single machine.
>> +.PP
>> +.in +4n
>> +.EX
>> +struct sockaddr_vm {
>> + sa_family_t svm_family; /* address family: AF_VSOCK */
>> + unsigned short svm_reserved1;
>> + unsigned int svm_port; /* port in native byte order */
>> + unsigned int svm_cid; /* address in native byte order */
>> +};
>> +.EE
>> +.in
>> +.PP
>> +.I svm_family
>> +is always set to
>> +.BR AF_VSOCK .
>> +.I svm_reserved1
>> +is always set to 0.
>> +.I svm_port
>> +contains the port in native byte order.
>> +The port numbers below 1024 are called
>> +.IR "privileged ports" .
>> +Only a process with
>> +.B CAP_NET_BIND_SERVER
>> +capability may
>> +.BR bind (2)
>> +to these port numbers.
>> +.PP
>> +There are several special addresses:
>> +.B VMADDR_CID_ANY
>> +(-1U)
>> +means any address for binding;
>> +.B VMADDR_CID_HYPERVISOR
>> +(0) is reserved for services built into the hypervisor;
>> +.B VMADDR_CID_RESERVED
>> +(1) must not be used;
>> +.B VMADDR_CID_HOST
>> +(2)
>> +is the well-known address of the host.
>> +.PP
>> +The special constant
>> +.B VMADDR_PORT_ANY
>> +(-1U)
>> +means any port number for binding.
>> +.SS Live migration
>> +Sockets are affected by live migration of virtual machines. Connected
>> +.B SOCK_STREAM
>> +sockets become disconnected when the virtual machine migrates to a new host.
>> +Applications must reconnect when this happens.
>> +.PP
>> +The local CID may change across live migration if the old CID is not available
>> +on the new host. Bound sockets are automatically updated to the new CID.
>> +.SS Ioctls
>> +.TP
>> +.B IOCTL_VM_SOCKETS_GET_LOCAL_CID
>> +Get the CID of the local machine. The argument is a pointer to an unsigned int.
>> +.IP
>> +.in +4n
>> +.EX
>> +.IB error " = ioctl(" socket ", " IOCTL_VM_SOCKETS_GET_LOCAL_CID ", " &cid ");"
>> +.EE
>> +.in
>> +.IP
>> +Consider using
>> +.B VMADDR_CID_ANY
>> +when binding instead of getting the local CID with
>> +.BR IOCTL_VM_SOCKETS_GET_LOCAL_CID .
>> +.SH ERRORS
>> +.TP
>> +.B EACCES
>> +Unable to bind to a privileged port without the
>> +.B CAP_NET_BIND_SERVICE
>> +capability.
>> +.TP
>> +.B EINVAL
>> +Invalid parameters. This includes:
>> +attempting to bind a socket that is already bound, providing an invalid struct
>> +.BR sockaddr_vm ,
>> +and other input validation errors.
>> +.TP
>> +.B EOPNOTSUPP
>> +Operation not supported. This includes:
>> +the
>> +.B MSG_OOB
>> +flag that is not implemented for
>> +.BR sendmsg (2)
>> +and
>> +.B MSG_PEEK
>> +for
>> +.BR recvmsg (2).
>> +.TP
>> +.B EADDRINUSE
>> +Unable to bind to a port that is already in use.
>> +.TP
>> +.B EADDRNOTAVAIL
>> +Unable to find a free port for binding or unable to bind to a non-local CID.
>> +.TP
>> +.B ENOTCONN
>> +Unable to perform operation on an unconnected socket.
>> +.TP
>> +.B ENOPROTOOPT
>> +Invalid socket option in
>> +.BR setsockopt (2)
>> +or
>> +.BR getsockopt (2).
>> +.TP
>> +.B EPROTONOSUPPORT
>> +Invalid socket protocol number. Protocol should always be 0.
>> +.TP
>> +.B ESOCKTNOSUPPORT
>> +Unsupported socket type in
>> +.BR socket (2).
>> +Only
>> +.B SOCK_STREAM
>> +and
>> +.B SOCK_DGRAM
>> +are valid.
>> +.SH VERSIONS
>> +Support for VMware (VMCI) has been available since Linux 3.9. KVM (virtio) is
>> +supported since Linux 4.8. Hyper-V is supported since 4.14.
>> +.SH SEE ALSO
>> +.BR socket (2),
>> +.BR bind (2),
>> +.BR connect (2),
>> +.BR listen (2),
>> +.BR send (2),
>> +.BR recv (2),
>> +.BR capabilities (7)
>> --
>> 2.14.3
>>
>
> Looks great to me. Thanks for doing this. I don’t have anything to add.
>
> Reviewed-by: Jorgen Hansen <jhansen-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
Thanks, Jorgen!
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] vsock.7: document VSOCK socket address family
From: Michael Kerrisk (man-pages) @ 2017-12-11 19:32 UTC (permalink / raw)
To: Stefan Hajnoczi, linux-man-u79uwXL29TY76Z2rM5mHXA
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, Jorgen Hansen, G. Branden Robinson,
Dexuan Cui
In-Reply-To: <20171205105618.30049-1-stefanha-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Hello Stefan,
Thanks for this page!
I have applied your patch, and made a few tweaks, but
I have some minor questions. Please see below.
On 12/05/2017 11:56 AM, Stefan Hajnoczi wrote:
> The AF_VSOCK address family has been available since Linux 3.9 without a
> corresponding man page.
>
> This patch adds vsock.7 and describes its use along the same lines as
> existing ip.7, unix.7, and netlink.7 man pages.
>
> CC: Jorgen Hansen <jhansen-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
> CC: Dexuan Cui <decui-0li6OtcxBFHby3iVrkZq2A@public.gmane.org>
> Signed-off-by: Stefan Hajnoczi <stefanha-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
> man7/vsock.7 | 180 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 180 insertions(+)
> create mode 100644 man7/vsock.7
>
> diff --git a/man7/vsock.7 b/man7/vsock.7
> new file mode 100644
> index 000000000..46dc561f5
> --- /dev/null
> +++ b/man7/vsock.7
> @@ -0,0 +1,180 @@
> +.TH VSOCK 7 2017-11-30 "Linux" "Linux Programmer's Manual"
> +.SH NAME
> +vsock \- Linux VSOCK address family
> +.SH SYNOPSIS
> +.B #include <sys/socket.h>
> +.br
> +.B #include <linux/vm_sockets.h>
> +.PP
> +.IB stream_socket " = socket(AF_VSOCK, SOCK_STREAM, 0);"
> +.br
> +.IB datagram_socket " = socket(AF_VSOCK, SOCK_DGRAM, 0);"
> +.SH DESCRIPTION
> +The VSOCK address family facilitates communication between virtual machines and
> +the host they are running on. This address family is used by guest agents and
> +hypervisor services that need a communications channel that is independent of
> +virtual machine network configuration.
> +.PP
> +Valid socket types are
> +.B SOCK_STREAM
> +and
> +.BR SOCK_DGRAM .
> +.B SOCK_STREAM
> +provides connection-oriented byte streams with guaranteed, in-order delivery.
> +.B SOCK_DGRAM
> +provides a connectionless datagram packet service with best-effort delivery and
> +best-effort ordering. Availability of these socket types is dependent on the
> +underlying hypervisor.
> +.PP
> +A new socket is created with
> +.PP
> + socket(AF_VSOCK, socket_type, 0);
> +.PP
> +When a process wants to establish a connection it calls
> +.BR connect (2)
> +with a given destination socket address. The socket is automatically bound to
> +a free port if unbound.
> +.PP
> +A process can listen for incoming connections by first binding to a socket
> +address using
> +.BR bind (2)
> +and then calling
> +.BR listen (2).
> +.PP
> +Data is transferred using the usual
> +.BR send (2)
> +and
> +.BR recv (2)
Or equally, write(2) and read(2), right? By failing to mention those, the
text subtly implies that send(2) and recv(2) are preferred, but I don't
suppose that is true.
> +family of socket system calls.
> +.SS Address format
> +A socket address is defined as a combination of a 32-bit Context Identifier
> +(CID) and a 32-bit port number. The CID identifies the source or destination,
> +which is either a virtual machine or the host. The port number differentiates
> +between multiple services running on a single machine.
> +.PP
> +.in +4n
> +.EX
> +struct sockaddr_vm {
> + sa_family_t svm_family; /* address family: AF_VSOCK */
> + unsigned short svm_reserved1;
> + unsigned int svm_port; /* port in native byte order */
> + unsigned int svm_cid; /* address in native byte order */
> +};
> +.EE
> +.in
> +.PP
> +.I svm_family
> +is always set to
> +.BR AF_VSOCK .
> +.I svm_reserved1
> +is always set to 0.
> +.I svm_port
> +contains the port in native byte order.
> +The port numbers below 1024 are called
> +.IR "privileged ports" .
> +Only a process with
> +.B CAP_NET_BIND_SERVER
> +capability may
> +.BR bind (2)
> +to these port numbers.
> +.PP
> +There are several special addresses:
> +.B VMADDR_CID_ANY
> +(-1U)
> +means any address for binding;
> +.B VMADDR_CID_HYPERVISOR
> +(0) is reserved for services built into the hypervisor;
> +.B VMADDR_CID_RESERVED
> +(1) must not be used;
> +.B VMADDR_CID_HOST
> +(2)
> +is the well-known address of the host.
> +.PP
> +The special constant
> +.B VMADDR_PORT_ANY
> +(-1U)
> +means any port number for binding.
> +.SS Live migration
> +Sockets are affected by live migration of virtual machines. Connected
> +.B SOCK_STREAM
> +sockets become disconnected when the virtual machine migrates to a new host.
> +Applications must reconnect when this happens.
> +.PP
> +The local CID may change across live migration if the old CID is not available
> +on the new host. Bound sockets are automatically updated to the new CID.
> +.SS Ioctls
> +.TP
> +.B IOCTL_VM_SOCKETS_GET_LOCAL_CID
> +Get the CID of the local machine. The argument is a pointer to an unsigned int.
> +.IP
> +.in +4n
> +.EX
> +.IB error " = ioctl(" socket ", " IOCTL_VM_SOCKETS_GET_LOCAL_CID ", " &cid ");"
> +.EE
> +.in
> +.IP
> +Consider using
> +.B VMADDR_CID_ANY
> +when binding instead of getting the local CID with
> +.BR IOCTL_VM_SOCKETS_GET_LOCAL_CID .
> +.SH ERRORS
> +.TP
> +.B EACCES
> +Unable to bind to a privileged port without the
> +.B CAP_NET_BIND_SERVICE
> +capability.
> +.TP
> +.B EINVAL
> +Invalid parameters. This includes:
> +attempting to bind a socket that is already bound, providing an invalid struct
> +.BR sockaddr_vm ,
> +and other input validation errors.
> +.TP
> +.B EOPNOTSUPP
> +Operation not supported. This includes:
> +the
> +.B MSG_OOB
> +flag that is not implemented for
> +.BR sendmsg (2)
> +and
> +.B MSG_PEEK
> +for
> +.BR recvmsg (2).
So these errors might also occur for send() and recv(), right?
> +.TP
> +.B EADDRINUSE
> +Unable to bind to a port that is already in use.
> +.TP
> +.B EADDRNOTAVAIL
> +Unable to find a free port for binding or unable to bind to a non-local CID.
> +.TP
> +.B ENOTCONN
> +Unable to perform operation on an unconnected socket.
> +.TP
> +.B ENOPROTOOPT
> +Invalid socket option in
> +.BR setsockopt (2)
> +or
> +.BR getsockopt (2).
> +.TP
> +.B EPROTONOSUPPORT
> +Invalid socket protocol number. Protocol should always be 0.
> +.TP
> +.B ESOCKTNOSUPPORT
> +Unsupported socket type in
> +.BR socket (2).
> +Only
> +.B SOCK_STREAM
> +and
> +.B SOCK_DGRAM
> +are valid.
> +.SH VERSIONS
> +Support for VMware (VMCI) has been available since Linux 3.9. KVM (virtio) is
> +supported since Linux 4.8. Hyper-V is supported since 4.14.
> +.SH SEE ALSO
> +.BR socket (2),
> +.BR bind (2),
> +.BR connect (2),
> +.BR listen (2),
> +.BR send (2),
> +.BR recv (2),
> +.BR capabilities (7)
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] selftests: bpf: Adding config fragment CONFIG_CGROUP_BPF=y
From: Naresh Kamboju @ 2017-12-11 19:25 UTC (permalink / raw)
To: netdev; +Cc: guro, shuahkh, shuah, linux-kselftest
CONFIG_CGROUP_BPF=y is required for test_dev_cgroup test case.
Signed-off-by: Naresh Kamboju <naresh.kamboju@linaro.org>
---
tools/testing/selftests/bpf/config | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/testing/selftests/bpf/config b/tools/testing/selftests/bpf/config
index 52d53ed..9d48973 100644
--- a/tools/testing/selftests/bpf/config
+++ b/tools/testing/selftests/bpf/config
@@ -3,3 +3,4 @@ CONFIG_BPF_SYSCALL=y
CONFIG_NET_CLS_BPF=m
CONFIG_BPF_EVENTS=y
CONFIG_TEST_BPF=m
+CONFIG_CGROUP_BPF=y
--
2.7.4
^ permalink raw reply related
* [PATCH] net/tls: Fix inverted error codes to avoid endless loop
From: r.hering @ 2017-12-11 18:56 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
sendfile() calls can hang endless with using Kernel TLS if a socket error
occurs.
Socket error codes must be inverted by Kernel TLS before returning because
they are stored with positive sign. If returned non-inverted they are
interpreted as number of bytes sent, causing endless looping of the
splice mechanic behind sendfile().
Signed-off-by: Robert Hering <r.hering@avm.de>
---
diff --git a/include/net/tls.h b/include/net/tls.h
index 936cfc5..9185e53 100644
--- a/include/net/tls.h
+++ b/include/net/tls.h
@@ -170,7 +170,7 @@ static inline bool tls_is_pending_open_record(struct
tls_context *tls_ctx)
static inline void tls_err_abort(struct sock *sk)
{
- sk->sk_err = -EBADMSG;
+ sk->sk_err = EBADMSG;
sk->sk_error_report(sk);
}
diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index 73d1921..9773571 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -391,7 +391,7 @@ int tls_sw_sendmsg(struct sock *sk, struct msghdr
*msg, size_t size)
while (msg_data_left(msg)) {
if (sk->sk_err) {
- ret = sk->sk_err;
+ ret = -sk->sk_err;
goto send_end;
}
@@ -544,7 +544,7 @@ int tls_sw_sendpage(struct sock *sk, struct page
*page,
size_t copy, required_size;
if (sk->sk_err) {
- ret = sk->sk_err;
+ ret = -sk->sk_err;
goto sendpage_end;
}
^ permalink raw reply related
* Re: [PATCH net-next 2/2 v8] net: ethernet: Add a driver for Gemini gigabit ethernet
From: David Miller @ 2017-12-11 19:16 UTC (permalink / raw)
To: linus.walleij
Cc: netdev, mirq-linux, janos.dev, paulius.zaleckas, linux-arm-kernel,
ulli.kroll, f.fainelli, tobias.waldvogel
In-Reply-To: <20171210224558.27122-2-linus.walleij@linaro.org>
From: Linus Walleij <linus.walleij@linaro.org>
Date: Sun, 10 Dec 2017 23:45:58 +0100
> diff --git a/drivers/net/ethernet/cortina/Kconfig b/drivers/net/ethernet/cortina/Kconfig
> new file mode 100644
> index 000000000000..7d279ac4357d
> --- /dev/null
> +++ b/drivers/net/ethernet/cortina/Kconfig
> @@ -0,0 +1,24 @@
> +# SPDX-License-Identifier: GPL-2.0
> +# Cortina ethernet devices
> +
> +config NET_VENDOR_CORTINA
> + bool "Cortina Gemini devices"
> + depends on (ARM || COMPILE_TEST)
> + default ARCH_GEMINI
> + ---help---
> + If you have a network (Ethernet) card belonging to this class, say Y
> + and read the Ethernet-HOWTO, available from
> + <http://www.tldp.org/docs.html#howto>.
Vendor Kconfig guards should default to 'y'. Remove the depends guard.
> +
> +if NET_VENDOR_CORTINA
> +
> +config GEMINI_ETHERNET
> + tristate "Gemini Gigabit Ethernet support"
> + depends on ARCH_GEMINI
> + depends on OF
> + select PHYLIB
> + select CRC32
> + ---help---
> + This driver supports StorLink SL351x (Gemini) dual Gigabit Ethernet.
Make this driver buildable anywhere, you don't use any platform architecture
specific features.
Otherwise your driver will have bad build coverage and will likely
stop building when core APIs are changed.
^ permalink raw reply
* [PATCH] net: igmp: Use correct source address on IGMPv3 reports
From: Kevin Cernekee @ 2017-12-11 19:13 UTC (permalink / raw)
To: davem, kuznet, yoshfuji; +Cc: netdev, andrew, linux-kernel
Closing a multicast socket after the final IPv4 address is deleted
from an interface can generate a membership report that uses the
source IP from a different interface. The following test script, run
from an isolated netns, reproduces the issue:
#!/bin/bash
ip link add dummy0 type dummy
ip link add dummy1 type dummy
ip link set dummy0 up
ip link set dummy1 up
ip addr add 10.1.1.1/24 dev dummy0
ip addr add 192.168.99.99/24 dev dummy1
tcpdump -U -i dummy0 &
socat EXEC:"sleep 2" \
UDP4-DATAGRAM:239.101.1.68:8889,ip-add-membership=239.0.1.68:10.1.1.1 &
sleep 1
ip addr del 10.1.1.1/24 dev dummy0
sleep 5
kill %tcpdump
RFC 3376 specifies that the report must be sent with a valid IP source
address from the destination subnet, or from address 0.0.0.0. Add an
extra check to make sure this is the case.
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
---
net/ipv4/igmp.c | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index d1f8f302dbf3..0672264c9d93 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -89,6 +89,7 @@
#include <linux/rtnetlink.h>
#include <linux/times.h>
#include <linux/pkt_sched.h>
+#include <linux/byteorder/generic.h>
#include <net/net_namespace.h>
#include <net/arp.h>
@@ -321,6 +322,23 @@ igmp_scount(struct ip_mc_list *pmc, int type, int gdeleted, int sdeleted)
return scount;
}
+/* source address selection per RFC 3376 section 4.2.13 */
+static __be32 igmpv3_get_srcaddr(struct net_device *dev,
+ const struct flowi4 *fl4)
+{
+ struct in_device *in_dev = __in_dev_get_rcu(dev);
+
+ if (!in_dev)
+ return htonl(INADDR_ANY);
+
+ for_ifa(in_dev) {
+ if (inet_ifa_match(fl4->saddr, ifa))
+ return fl4->saddr;
+ } endfor_ifa(in_dev);
+
+ return htonl(INADDR_ANY);
+}
+
static struct sk_buff *igmpv3_newpack(struct net_device *dev, unsigned int mtu)
{
struct sk_buff *skb;
@@ -368,7 +386,7 @@ static struct sk_buff *igmpv3_newpack(struct net_device *dev, unsigned int mtu)
pip->frag_off = htons(IP_DF);
pip->ttl = 1;
pip->daddr = fl4.daddr;
- pip->saddr = fl4.saddr;
+ pip->saddr = igmpv3_get_srcaddr(dev, &fl4);
pip->protocol = IPPROTO_IGMP;
pip->tot_len = 0; /* filled in later */
ip_select_ident(net, skb, NULL);
--
2.15.1.424.g9478a66081-goog
^ permalink raw reply related
* Re: [PATCH net] fou: fix some member types in guehdr
From: David Miller @ 2017-12-11 19:10 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, therbert
In-Reply-To: <5e022d6a50c6a9f8de5e12bbd2018217475ba6c3.1512896160.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Sun, 10 Dec 2017 16:56:00 +0800
> guehdr struct is used to build or parse gue packets, which
> are always in big endian. It's better to define all guehdr
> members as __beXX types.
>
> Also, in validate_gue_flags it's not good to use a __be32
> variable for both Standard flags(__be16) and Private flags
> (__be32), and pass it to other funcions.
>
> This patch could fix a bunch of sparse warnings from fou.
>
> Fixes: 5024c33ac354 ("gue: Add infrastructure for flags and options")
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Looks good, applied, thanks.
^ permalink raw reply
* Re: [PATCH net] sctp: make sure stream nums can match optlen in sctp_setsockopt_reset_streams
From: David Miller @ 2017-12-11 19:09 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, nhorman, syzkaller
In-Reply-To: <a6c86b9cb13c2b6e2ed2539c028557a6b1a713ef.1512891651.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Sun, 10 Dec 2017 15:40:51 +0800
> Now in sctp_setsockopt_reset_streams, it only does the check
> optlen < sizeof(*params) for optlen. But it's not enough, as
> params->srs_number_streams should also match optlen.
>
> If the streams in params->srs_stream_list are less than stream
> nums in params->srs_number_streams, later when dereferencing
> the stream list, it could cause a slab-out-of-bounds crash, as
> reported by syzbot.
>
> This patch is to fix it by also checking the stream numbers in
> sctp_setsockopt_reset_streams to make sure at least it's not
> greater than the streams in the list.
>
> Fixes: 7f9d68ac944e ("sctp: implement sender-side procedures for SSN Reset Request Parameter")
> Reported-by: Dmitry Vyukov <dvyukov@google.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] net: ipv4: fix for a race condition in raw_sendmsg
From: David Miller @ 2017-12-11 19:05 UTC (permalink / raw)
To: simo.ghannam; +Cc: netdev
In-Reply-To: <5a2caf2e.4ce61c0a.5017a.575f@mx.google.com>
From: simo.ghannam@gmail.com
Date: Sun, 10 Dec 2017 03:50:58 +0000
> From: Mohamed Ghannam <simo.ghannam@gmail.com>
>
> inet->hdrincl is racy, and could lead to uninitialized stack pointer
> usage, so its value should be read only once.
>
> Signed-off-by: Mohamed Ghannam <simo.ghannam@gmail.com>
Applied and queued up for -stable with Fixes: tag from Eric Dumazet added.
Thanks.
^ permalink raw reply
* Re: [PATCH 27/45] net: remove duplicate includes
From: Pablo Neira Ayuso @ 2017-12-11 19:04 UTC (permalink / raw)
To: Pravin Shedge
Cc: netdev, netfilter-devel, coreteam, davem, andrew, vivien.didelot,
f.fainelli, kadlec, fw, jhs, xiyou.wangcong, mingo, rmk+kernel,
linux-kernel
In-Reply-To: <1513010386-3394-1-git-send-email-pravin.shedge4linux@gmail.com>
On Mon, Dec 11, 2017 at 10:09:46PM +0530, Pravin Shedge wrote:
> These duplicate includes have been found with scripts/checkincludes.pl but
> they have been removed manually to avoid removing false positives.
>
> Signed-off-by: Pravin Shedge <pravin.shedge4linux@gmail.com>
For the Netfilter chunk.
Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>
Thanks.
^ permalink raw reply
* Re: [PATCHv2 net-next 1/1] forcedeth: remove unnecessary structure member
From: David Miller @ 2017-12-11 19:04 UTC (permalink / raw)
To: yanjun.zhu; +Cc: netdev, keescook
In-Reply-To: <1512875246-28258-1-git-send-email-yanjun.zhu@oracle.com>
From: Zhu Yanjun <yanjun.zhu@oracle.com>
Date: Sat, 9 Dec 2017 22:07:26 -0500
> Since both tx_ring and first_tx are the head of tx ring, it not
> necessary to use two structure members to statically indicate
> the head of tx ring. So first_tx is removed.
>
> CC: Srinivas Eeda <srinivas.eeda@oracle.com>
> CC: Joe Jin <joe.jin@oracle.com>
> CC: Junxiao Bi <junxiao.bi@oracle.com>
> Signed-off-by: Zhu Yanjun <yanjun.zhu@oracle.com>
I suspect this extraneous member was meant to be used for multiqueue
support or something like that.
But, it never got really used, and your change is correct.
Applied, thanks.
^ permalink raw reply
* Re: [RFC PATCH 0/9] ethtool netlink interface (WiP)
From: Florian Fainelli @ 2017-12-11 19:03 UTC (permalink / raw)
To: David Miller, jiri; +Cc: mkubecek, netdev, linux-kernel
In-Reply-To: <20171211.120144.1060832843526341781.davem@davemloft.net>
On 12/11/2017 09:01 AM, David Miller wrote:
> From: Jiri Pirko <jiri@resnulli.us>
> Date: Mon, 11 Dec 2017 17:32:46 +0100
>
>> I think that it does not make sense to convert ethtool->netlink_ethtool
>> 1:1 feature wise. Now we have devlink, ritch switch representation
>> model, tc offload and many others. Lot of things that are in
>> ethtool, should be done in devlink. Also, there are couple of things
>> that should just die - nice example is ethtool --config-ntuple - we
>> should use tc for that.
>
> Whilst I do agree that devlink is probably a good place for this stuff
> (we want to be able to do ethetool things on objects that lack a netdev)
> I do not agree with the tc angle.
>
> It is entirely appropriate to set the ntuple settings of a driver
> without being required to use TC or similar.
>
> All you are going to do with your suggestion is make people keep using
> the existing ethtool ioctl, because they'll say "screw this, I'm not
> using TC I have something which works just fine already". And that's
> not the goal of putting this stuff into netlink, we want people to
> use the new facilities and move off of the ioctl.
I agree, we can't walk away from that feature today, there are many more
drivers implementing ethtool::ntuple (counting 22) than there are
implementing cls_flower (counting 6), also they are not strictly
equivalent feature wise, one thing critically missing in cls_flower
(last I looked) is the ability to either auto-place (RX_CLS_LOC_ANY) a
matching rule, or select a particular location. For specifying what to
match in a packet and how, cls_flower is superior.
We can probably advise people not to use that feature and request their
driver provider to switch over to cls_flower, but considering how many
more LOCs are needed in the driver to implement that (as opposed to
ethtool ntuple), I just don't see it being something people will be
thrilled to do.
Writing a shim that converts from ethtool ntuple to the equivalent in
kernel space representation of the same call through cls_flower would be
reasonably easy, but same thing, that still requires migrating your
kernel driver over to the cls_flower interface, which is the harder part.
That being said, we should probably discourage implementing both for new
drivers, since they are likely to use the same centralized HW resources
towards the same goals: match + actions, with no visibility into one
another (can't see rules set-up in ethtool via cls_flower and vice
versa) and that just sucks.
--
Florian
^ permalink raw reply
* Re: [PATCH] net: dsa: allow XAUI phy interface mode
From: Russell King - ARM Linux @ 2017-12-11 19:02 UTC (permalink / raw)
To: David Miller; +Cc: andrew, vivien.didelot, f.fainelli, netdev
In-Reply-To: <20171211.135403.1074292653549923685.davem@davemloft.net>
On Mon, Dec 11, 2017 at 01:54:03PM -0500, David Miller wrote:
> From: Russell King <rmk+kernel@armlinux.org.uk>
> Date: Fri, 08 Dec 2017 16:04:59 +0000
>
> > XGMII is a 32-bit bus plus two clock signals per direction. XAUI is
> > four serial lanes per direction. The 88e6190 supports XAUI but not
> > XGMII as it doesn't have enough pins. The same is true of 88e6176.
> >
> > Match on PHY_INTERFACE_MODE_XAUI for the XAUI port type, but keep
> > accepting XGMII for backwards compatibility.
> >
> > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
>
> Based upon the discussion of this patch I am expecting to receive
> a DT patch that replaces this one, and some time in the future the
> XGMII case statement providing backwards compatibility will be
> removed.
>
> Please let me know if this is not the case.
That's something like it - asked Andrew via IRC on Saturday:
Do we want to do the XAUI thing as one patch to avoid any breakage, and
if so via whom?
and haven't had a response. Normally arm-soc folk want patches
touching arch/arm/boot/dts to go via their tree.
So, until I know what to do, I can't proceed with this... and I've
soo many outstanding net patches now that I'm losing track of where
each patch I've sent out is. Sorry, I'm failing.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* Re: Linux 4.15-rc3 (uml + bpf_perf_event.h)
From: Randy Dunlap @ 2017-12-11 18:56 UTC (permalink / raw)
To: Richard Weinberger, Daniel Borkmann
Cc: netdev@vger.kernel.org, Linus Torvalds, Linux Kernel Mailing List,
alexei.starovoitov, brueckner
In-Reply-To: <1879970.PcO3yMVeYC@blindfold>
On 12/11/2017 10:49 AM, Richard Weinberger wrote:
> Am Montag, 11. Dezember 2017, 11:19:54 CET schrieb Daniel Borkmann:
>> Hi Randy, hi Richard, [ +Hendrik for c895f6f703ad7dd2f ]
>>
>> On 12/11/2017 09:32 AM, Richard Weinberger wrote:
>>> Randy,
>>>
>>> Am Montag, 11. Dezember 2017, 03:42:12 CET schrieb Randy Dunlap:
>>>> On 12/10/2017 06:08 PM, Linus Torvalds wrote:
>>>>> Another week, another rc.
>>>>
>>>> um (uml) won't build on i386 or x86_64:
>>>> CC init/main.o
>>>>
>>>> In file included from ../include/linux/perf_event.h:18:0,
>>>>
>>>> from ../include/linux/trace_events.h:10,
>>>> from ../include/trace/syscall.h:7,
>>>> from ../include/linux/syscalls.h:82,
>>>>
>>>> from ../init/main.c:20:
>>>> ../include/uapi/linux/bpf_perf_event.h:11:32: fatal error:
>>>> asm/bpf_perf_event.h: No such file or directory #include
>>>> <asm/bpf_perf_event.h>
>>>>
>>>> ^
>>>>
>>>> compilation terminated.
>>>> ../scripts/Makefile.build:310: recipe for target 'init/main.o' failed
>>>
>>> How do you trigger that build failure?
>>> Can you share your .config?
>>
>> Hmm, too bad kbuild bot doesn't catch issues on uml. I'm not too familiar
>> with uml, but looks like it's the only special case where there's no
>> arch/um/include/uapi/asm/. What is the usual convention to pull in such
>> headers in this case? Something like the below, would that fix it for you?
>>
>> Thanks for your help,
>> Daniel
>>
>> arch/um/include/asm/bpf_perf_event.h | 1 +
>> include/asm-generic/bpf_perf_event.h | 1 +
>> 2 files changed, 2 insertions(+)
>> create mode 100644 arch/um/include/asm/bpf_perf_event.h
>> create mode 100644 include/asm-generic/bpf_perf_event.h
>>
>> diff --git a/arch/um/include/asm/bpf_perf_event.h
>> b/arch/um/include/asm/bpf_perf_event.h new file mode 100644
>> index 0000000..3097758
>> --- /dev/null
>> +++ b/arch/um/include/asm/bpf_perf_event.h
>> @@ -0,0 +1 @@
>> +#include <asm-generic/bpf_perf_event.h>
>> diff --git a/include/asm-generic/bpf_perf_event.h
>> b/include/asm-generic/bpf_perf_event.h new file mode 100644
>> index 0000000..67112e5
>> --- /dev/null
>> +++ b/include/asm-generic/bpf_perf_event.h
>> @@ -0,0 +1 @@
>> +#include <uapi/asm-generic/bpf_perf_event.h>
>
> Hmm, what about this?
>
> diff --git a/arch/um/include/asm/Kbuild b/arch/um/include/asm/Kbuild
> index 50a32c33d729..fb35ec000433 100644
> --- a/arch/um/include/asm/Kbuild
> +++ b/arch/um/include/asm/Kbuild
> @@ -27,3 +27,4 @@ generic-y += trace_clock.h
> generic-y += word-at-a-time.h
> generic-y += xor.h
> generic-y += kprobes.h
> +generic-y += bpf_perf_event.h
>
That also works for arch/um.
thanks,
--
~Randy
^ permalink raw reply
* Re: [PATCH] net: dsa: allow XAUI phy interface mode
From: David Miller @ 2017-12-11 18:54 UTC (permalink / raw)
To: rmk+kernel; +Cc: andrew, vivien.didelot, f.fainelli, netdev
In-Reply-To: <E1eNL91-0007uX-Ig@rmk-PC.armlinux.org.uk>
From: Russell King <rmk+kernel@armlinux.org.uk>
Date: Fri, 08 Dec 2017 16:04:59 +0000
> XGMII is a 32-bit bus plus two clock signals per direction. XAUI is
> four serial lanes per direction. The 88e6190 supports XAUI but not
> XGMII as it doesn't have enough pins. The same is true of 88e6176.
>
> Match on PHY_INTERFACE_MODE_XAUI for the XAUI port type, but keep
> accepting XGMII for backwards compatibility.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Based upon the discussion of this patch I am expecting to receive
a DT patch that replaces this one, and some time in the future the
XGMII case statement providing backwards compatibility will be
removed.
Please let me know if this is not the case.
THanks.
^ permalink raw reply
* Re: Linux 4.15-rc3 (uml + bpf_perf_event.h)
From: Richard Weinberger @ 2017-12-11 18:49 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Randy Dunlap, netdev@vger.kernel.org, Linus Torvalds,
Linux Kernel Mailing List, alexei.starovoitov, brueckner
In-Reply-To: <ea01fc20-a122-e6d3-e147-2de7f9fa7e47@iogearbox.net>
Am Montag, 11. Dezember 2017, 11:19:54 CET schrieb Daniel Borkmann:
> Hi Randy, hi Richard, [ +Hendrik for c895f6f703ad7dd2f ]
>
> On 12/11/2017 09:32 AM, Richard Weinberger wrote:
> > Randy,
> >
> > Am Montag, 11. Dezember 2017, 03:42:12 CET schrieb Randy Dunlap:
> >> On 12/10/2017 06:08 PM, Linus Torvalds wrote:
> >>> Another week, another rc.
> >>
> >> um (uml) won't build on i386 or x86_64:
> >> CC init/main.o
> >>
> >> In file included from ../include/linux/perf_event.h:18:0,
> >>
> >> from ../include/linux/trace_events.h:10,
> >> from ../include/trace/syscall.h:7,
> >> from ../include/linux/syscalls.h:82,
> >>
> >> from ../init/main.c:20:
> >> ../include/uapi/linux/bpf_perf_event.h:11:32: fatal error:
> >> asm/bpf_perf_event.h: No such file or directory #include
> >> <asm/bpf_perf_event.h>
> >>
> >> ^
> >>
> >> compilation terminated.
> >> ../scripts/Makefile.build:310: recipe for target 'init/main.o' failed
> >
> > How do you trigger that build failure?
> > Can you share your .config?
>
> Hmm, too bad kbuild bot doesn't catch issues on uml. I'm not too familiar
> with uml, but looks like it's the only special case where there's no
> arch/um/include/uapi/asm/. What is the usual convention to pull in such
> headers in this case? Something like the below, would that fix it for you?
>
> Thanks for your help,
> Daniel
>
> arch/um/include/asm/bpf_perf_event.h | 1 +
> include/asm-generic/bpf_perf_event.h | 1 +
> 2 files changed, 2 insertions(+)
> create mode 100644 arch/um/include/asm/bpf_perf_event.h
> create mode 100644 include/asm-generic/bpf_perf_event.h
>
> diff --git a/arch/um/include/asm/bpf_perf_event.h
> b/arch/um/include/asm/bpf_perf_event.h new file mode 100644
> index 0000000..3097758
> --- /dev/null
> +++ b/arch/um/include/asm/bpf_perf_event.h
> @@ -0,0 +1 @@
> +#include <asm-generic/bpf_perf_event.h>
> diff --git a/include/asm-generic/bpf_perf_event.h
> b/include/asm-generic/bpf_perf_event.h new file mode 100644
> index 0000000..67112e5
> --- /dev/null
> +++ b/include/asm-generic/bpf_perf_event.h
> @@ -0,0 +1 @@
> +#include <uapi/asm-generic/bpf_perf_event.h>
Hmm, what about this?
diff --git a/arch/um/include/asm/Kbuild b/arch/um/include/asm/Kbuild
index 50a32c33d729..fb35ec000433 100644
--- a/arch/um/include/asm/Kbuild
+++ b/arch/um/include/asm/Kbuild
@@ -27,3 +27,4 @@ generic-y += trace_clock.h
generic-y += word-at-a-time.h
generic-y += xor.h
generic-y += kprobes.h
+generic-y += bpf_perf_event.h
--
sigma star gmbh - Eduard-Bodem-Gasse 6 - 6020 Innsbruck - Austria
ATU66964118 - FN 374287y
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox