Re: [PATCH bpf] tools/bpftool: copy uapi/linux/tc_act/tc_bpf.h to tools directory
On 11/8/2018 9:00 AM, Yonghong Song wrote:
Commit f6f3bac08ff9 ("tools/bpf: bpftool: add net support")
added certain networking support to bpftool.
The implementation relies on a relatively recent uapi header file
linux/tc_act/tc_bpf.h on the host which contains the marco
definition of TCA_ACT_BPF_ID.
Unfortunately, this is not the case for all distributions.
See the email message below where rhel-7.2 does not have
an up-to-date linux/tc_act/tc_bpf.h.
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1799211.html
i have not tested this patch, but basing on the early commit
6f3bac08ff9 ("tools/bpf: bpftool: add net support")
i cooked up similar patch locally, but i noticed that it also requires an
up-to-date linux/pkt_cls.h as well to avoid compiling errors:
root@lkp-bdw-ep3 ~/linux-f6f3bac08f/tools/bpf/bpftool# make V=1
[...snip...]
gcc -O2 -W -Wall -Wextra -Wno-unused-parameter -Wshadow -Wno-missing-field-initializers
-DPACKAGE='"bpftool"' -D__EXPORTED_HEADERS__ -I/root/linux-f6f3bac08f/kernel/bpf/
-I/root/linux-f6f3bac08f/tools/include -I/root/linux-f6f3bac08f/tools/include/uapi
-I/root/linux-f6f3bac08f/tools/lib/bpf -I/root/linux-f6f3bac08f/tools/perf
-DBPFTOOL_VERSION='"4.19.0-rc2"' -DCOMPAT_NEED_REALLOCARRAY -c -MMD -o netlink_dumper.o
netlink_dumper.c
make -C /root/linux-f6f3bac08f/tools/lib/bpf/ OUTPUT= libbpf.a
make[1]: Entering directory '/root/linux-f6f3bac08f/tools/lib/bpf'
netlink_dumper.c: In function 'do_bpf_filter_dump':
netlink_dumper.c:153:9: error: 'TCA_BPF_ID' undeclared (first use in this
function)
if (tb[TCA_BPF_ID])
^~
netlink_dumper.c:153:9: note: each undeclared identifier is reported only once
for each function it appears in
netlink_dumper.c:155:9: error: 'TCA_BPF_TAG' undeclared (first use in this
function)
if (tb[TCA_BPF_TAG])
^~~
Makefile:96: recipe for target 'netlink_dumper.o' failed
make: *** [netlink_dumper.o] Error 1
make: *** Waiting for unfinished jobs
make -f /root/linux-f6f3bac08f/tools/build/Makefile.build dir=. obj=libbpf
make[1]: Leaving directory '/root/linux-f6f3bac08f/tools/lib/bpf'
Thanks
Zhijian
This patch fixed the issue by copying linux/tc_act/tc_bpf.h from
kernel include/uapi directory to tools/include/uapi directory so
building the bpftool does not depend on host system for this file.
Fixes: f6f3bac08ff9 ("tools/bpf: bpftool: add net support")
Reported-by: kernel test robot
Signed-off-by: Yonghong Song
---
tools/include/uapi/linux/tc_act/tc_bpf.h | 37
1 file changed, 37 insertions(+)
create mode 100644 tools/include/uapi/linux/tc_act/tc_bpf.h
diff --git a/tools/include/uapi/linux/tc_act/tc_bpf.h
b/tools/include/uapi/linux/tc_act/tc_bpf.h
new file mode 100644
index ..6e89a5df49a4
--- /dev/null
+++ b/tools/include/uapi/linux/tc_act/tc_bpf.h
@@ -0,0 +1,37 @@
+/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */
+/*
+ * Copyright (c) 2015 Jiri Pirko
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef __LINUX_TC_BPF_H
+#define __LINUX_TC_BPF_H
+
+#include
+
+#define TCA_ACT_BPF 13
+
+struct tc_act_bpf {
+ tc_gen;
+};
+
+enum {
+ TCA_ACT_BPF_UNSPEC,
+ TCA_ACT_BPF_TM,
+ TCA_ACT_BPF_PARMS,
+ TCA_ACT_BPF_OPS_LEN,
+ TCA_ACT_BPF_OPS,
+ TCA_ACT_BPF_FD,
+ TCA_ACT_BPF_NAME,
+ TCA_ACT_BPF_PAD,
+ TCA_ACT_BPF_TAG,
+ TCA_ACT_BPF_ID,
+ __TCA_ACT_BPF_MAX,
+};
+#define TCA_ACT_BPF_MAX (__TCA_ACT_BPF_MAX - 1)
+
+#endif
[PATCH v2] selftests/bpf/test_maps: exit child process without error in ENOMEM case
From: Li Zhijian <zhijianx...@intel.com>
test_maps contains a series of stress tests, and previously it will break the
rest tests when it failed to alloc memory.
---
Failed to create hashmap key=8 value=262144 'Cannot allocate memory'
Failed to create hashmap key=16 value=262144 'Cannot allocate memory'
Failed to create hashmap key=8 value=262144 'Cannot allocate memory'
Failed to create hashmap key=8 value=262144 'Cannot allocate memory'
test_maps: test_maps.c:955: run_parallel: Assertion `status == 0' failed.
Aborted
not ok 1..3 selftests: test_maps [FAIL]
---
after this patch, the rest tests will be continue when it occurs an ENOMEM
failure
CC: Alexei Starovoitov <alexei.starovoi...@gmail.com>
CC: Philip Li <philip...@intel.com>
Suggested-by: Daniel Borkmann <dan...@iogearbox.net>
Signed-off-by: Li Zhijian <zhijianx...@intel.com>
---
tools/testing/selftests/bpf/test_maps.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/testing/selftests/bpf/test_maps.c
b/tools/testing/selftests/bpf/test_maps.c
index 436c4c7..9e03a4c 100644
--- a/tools/testing/selftests/bpf/test_maps.c
+++ b/tools/testing/selftests/bpf/test_maps.c
@@ -126,6 +126,8 @@ static void test_hashmap_sizes(int task, void *data)
fd = bpf_create_map(BPF_MAP_TYPE_HASH, i, j,
2, map_flags);
if (fd < 0) {
+ if (errno == ENOMEM)
+ return;
printf("Failed to create hashmap key=%d
value=%d '%s'\n",
i, j, strerror(errno));
exit(1);
--
2.7.4
[RFC] COLO Proxy Module
Hi, all We are planning to implement a kernel module called COLO Proxy to buffer and compare packets. This module is one of the important component of COLO project and now it is still in early stage, so any comments and feedback are warmly welcomed, thanks in advance. = # RFC: COLO-Proxy Module ## Rationale COLO FT/HA (COarse-grain LOck-stepping Virtual Machines for Non-stop Service) project is a high availability solution. Both Primary VM (PVM) and Secondary VM (SVM) run in parallel. They receive the same request from client, and generate responses in parallel too. If the response packets from PVM and SVM are identical, they are released immediately. Otherwise, a VM checkpoint (on demand) is conducted. Paper: http://www.socc2013.org/home/program/a3-dong.pdf?attredirects=0 COLO on Xen: http://wiki.xen.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping COLO on Qemu/KVM: http://wiki.qemu.org/Features/COLO By the needs of capturing response packets from PVM and SVM and finding out whether they are identical, we introduce a new kernel module which called colo-proxy. This document describes the design of the colo-proxy module ## Glossary * PVM - Primary VM, which provides services to clients. * SVM - Secondary VM, a hot standby and replication of PVM. * PN - Primary Node, the host which PVM runs on * SN - Secondary Node, the host which SVM runs on ## Network topology = Normal = ++ | client | ++---+ -+ |+ -+ PN | +|SN| +---+ +[eth0]-[switch]-[eth0]-+ | |PVM| +---+-+|| +---+-+| | [tap0]--+ br0 ||| | br0 || | | +-+ [eth1]-[forward][eth1]--+ +-+| +---+|||+---+| ||| +-+ |SVM|| [eth2]---[checkpoint]---[eth2] +--+ br1 |-[tap0]|| || +-+ | || || +---+| -++--+ e.g. PN: br0: 192.168.0.33 eth1: 192.168.1.33 eth2: 192.168.2.33 SN: br0: 192.168.0.88 br1: no ip address eth1: 192.168.1.88 eth2: 192.168.2.88 == After failover ++ | client | ++---+ -+ |---+ PN (dead)| +|SN (alive)| +---+ +[eth0]--X--[switch]-[eth0]---+| |PVM| +---+-+|| +---+-+ | | [tap0]--+ br0 ||| | br0 +--+ | | | +-+ [eth1]--X--[forward][eth1] +-+ | | +---+|| | +---+| || +-+ | |SVM|| [eth2]-X-[checkpoint]---[eth2] | br1 | +[tap0]|| || +-+ | || || +---+| -++--+ ## Network flow ### Receive packets from client (Input) +--+ |Client| +---+--+ +---+ | ++ |PN | v | SN| | +---[eth0]---[switch] | ++ | | +---+ v || |SVM | | | | PVM | +-+-+ || [tap0] | | | | [tap0]-+br0| || ^ || | | | | | +---+ || | ++ | | +---+ | || +-+-+ | | +[eth1]-[eth1]---colo-proxy | | | copyforward|| |*Adjust| | | || | Client's ack | | +---++-+---+--+ * colo-proxy on SN: ** Capture the first ack from client, find out the initial seq
