From notifications at github.com Sun Dec 1 04:02:33 2019 From: notifications at github.com (ionenwks) Date: Sun, 01 Dec 2019 04:02:33 +0000 (UTC) Subject: =?UTF-8?Q?Re:_[strace/strace]_5.4_FTBFS:_fetch=5Fstruct=5Fstat64.?= =?UTF-8?Q?c:58:16:_error:_storage_size_of_=E2=80=98buf=E2=80=99?= =?UTF-8?Q?_isn=E2=80=99t_known_=28#114=29?= In-Reply-To: References: Message-ID: I mentioned this in the downstream bug, but for me 5.4 fails to build even with just `CFLAGS="-O2 -g0"` giving the same error (-g0 is just to disable a previous -g if specified and should be harmless). Builds fine with 5.3 or if I use a normal or no -g. Some parsing error leading to something missing perhaps? I don't think the compiler itself is causing the behavior. But for reference, using gcc-9.2.0, binutils 2.33.1, glibc 2.30, and linux headers 5.3. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/strace/strace/issues/114#issuecomment-560050979 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Dec 5 12:56:06 2019 From: notifications at github.com (Dmitry V. Levin) Date: Thu, 05 Dec 2019 04:56:06 -0800 Subject: =?UTF-8?Q?Re:_[strace/strace]_5.4_FTBFS:_fetch=5Fstruct=5Fstat64.?= =?UTF-8?Q?c:58:16:_error:_storage_size_of_=E2=80=98buf=E2=80=99?= =?UTF-8?Q?_isn=E2=80=99t_known_=28#114=29?= In-Reply-To: References: Message-ID: Closed #114 via 52ac53e96143f6aac52738f6e385f75203a68a7b. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/strace/strace/issues/114#event-2857716510 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Dec 5 12:57:42 2019 From: notifications at github.com (Dmitry V. Levin) Date: Thu, 05 Dec 2019 04:57:42 -0800 Subject: =?UTF-8?Q?Re:_[strace/strace]_5.4_FTBFS:_fetch=5Fstruct=5Fstat64.?= =?UTF-8?Q?c:58:16:_error:_storage_size_of_=E2=80=98buf=E2=80=99?= =?UTF-8?Q?_isn=E2=80=99t_known_=28#114=29?= In-Reply-To: References: Message-ID: On Thu, Dec 05, 2019 at 04:56:05AM -0800, Dmitry V. Levin wrote: > Closed #114 via 52ac53e96143f6aac52738f6e385f75203a68a7b. The workaround for v5.4 is export CFLAGS_FOR_M32= CFLAGS_FOR_MX32= -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/strace/strace/issues/114#issuecomment-562118275 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Dec 5 17:42:54 2019 From: notifications at github.com (Thomas Deutschmann) Date: Thu, 05 Dec 2019 09:42:54 -0800 Subject: =?UTF-8?Q?Re:_[strace/strace]_5.4_FTBFS:_fetch=5Fstruct=5Fstat64.?= =?UTF-8?Q?c:58:16:_error:_storage_size_of_=E2=80=98buf=E2=80=99?= =?UTF-8?Q?_isn=E2=80=99t_known_=28#114=29?= In-Reply-To: References: Message-ID: Thanks, I can confirm that the patch fixes the problem. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/strace/strace/issues/114#issuecomment-562236231 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ldv at altlinux.org Fri Dec 6 12:27:26 2019 From: ldv at altlinux.org (Dmitry V. Levin) Date: Fri, 6 Dec 2019 15:27:26 +0300 Subject: [PATCH v2 1/1] netlink: fix neigh lladdr decoder In-Reply-To: <20180908232513.GA12892@altlinux.org> References: <20180901181108.32746-1-jhs@emojatatu.com> <20180908232513.GA12892@altlinux.org> Message-ID: <20191206122726.GD25049@altlinux.org> On Sun, Sep 09, 2018 at 02:25:13AM +0300, Dmitry V. Levin wrote: > On Sat, Sep 01, 2018 at 02:11:08PM -0400, Jamal Hadi Salim wrote: > > From: Jamal Hadi Salim > > > > Fixes: 19abd528fbba ("rtnl_neigh: decode ndmsg netlink attributes") > > signed-off-by: Jamal Hadi Salim > > It would be great if you added a sentence describing what was wrong in the > decoder (I suppose that mac address was printed as inet address) and what > is a fix (I suppose it's a new decoder for mac addresses). > > > --- > > rtnl_neigh.c | 18 +++++++++++++++++- > > 1 file changed, 17 insertions(+), 1 deletion(-) > > > > diff --git a/rtnl_neigh.c b/rtnl_neigh.c > > index 31087748..c1dd3d1c 100644 > > --- a/rtnl_neigh.c > > +++ b/rtnl_neigh.c > > @@ -56,6 +56,22 @@ decode_neigh_addr(struct tcb *const tcp, > > } > > > > static bool > > +decode_neigh_lladdr(struct tcb *const tcp, > > + const kernel_ulong_t addr, > > + const unsigned int len, > > + const void *const opaque_data) > > +{ > > + uint8_t maddr[6]; > > + > > + if (len < sizeof(maddr)) > > + return false; > > + else if (!umove_or_printaddr(tcp, addr, &maddr)) > > + print_mac_addr("", maddr, sizeof(maddr)); > > + > > + return true; > > +} > > + > > +static bool > > decode_nda_cacheinfo(struct tcb *const tcp, > > const kernel_ulong_t addr, > > const unsigned int len, > > @@ -78,7 +94,7 @@ decode_nda_cacheinfo(struct tcb *const tcp, > > > > static const nla_decoder_t ndmsg_nla_decoders[] = { > > [NDA_DST] = decode_neigh_addr, > > - [NDA_LLADDR] = decode_neigh_addr, > > + [NDA_LLADDR] = decode_neigh_lladdr, > > [NDA_CACHEINFO] = decode_nda_cacheinfo, > > [NDA_PROBES] = decode_nla_u32, > > [NDA_VLAN] = decode_nla_u16, > > This looks OK. > > Could you add a corresponding check to tests/nlattr_ndmsg.c, please? OK, I applied the patch and added a test for it. Thanks, -- ldv -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From chenjingpiao at gmail.com Fri Dec 6 14:16:59 2019 From: chenjingpiao at gmail.com (=?UTF-8?B?6ZmI5pmv6aOY?=) Date: Fri, 6 Dec 2019 22:16:59 +0800 Subject: [PATCH v2 1/1] netlink: fix neigh lladdr decoder In-Reply-To: <20180901181108.32746-1-jhs@emojatatu.com> References: <20180901181108.32746-1-jhs@emojatatu.com> Message-ID: On Sun, Sep 2, 2018 at 2:11 AM Jamal Hadi Salim wrote: > From: Jamal Hadi Salim > > Fixes: 19abd528fbba ("rtnl_neigh: decode ndmsg netlink attributes") > signed-off-by: Jamal Hadi Salim Thanks. Chen Jingpiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Sun Dec 8 18:33:01 2019 From: notifications at github.com (Dmitry V. Levin) Date: Sun, 08 Dec 2019 10:33:01 -0800 Subject: [strace/strace] make check fails with -j16 and higher (#74) In-Reply-To: References: Message-ID: On Thu, Jul 26, 2018 at 01:32:15AM -0700, Jiri Slaby wrote: > Running > ``` > for aa in `seq 1 120`; do ./tests/bpf-obj_get_info_by_fd >> log & done > ``` > results in *no* `EPERM`. It must be some other test interfering. Looking into the bpf code, `EPERM` is returned when we are over `RLIMIT_MEMLOCK`. And this `BPF_MAP_CREATE` only adds few bytes to that limit AFAIU (`value_size=8` ? `max_entries=1` + some constant, the sum rounded to `PAGE_SIZE`, i.e. exactly one page). And `ulimit -l` is set 64 k (which is not that much, I agree, looking where is this limit from; my machine has set that to 16 M). Finally, I've managed to reproduce this issue: $ uname -a Linux ppc64le-test.fedorainfracloud.org 5.2.16-200.fc30.ppc64le #1 SMP Thu Sep 19 15:47:22 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux $ ulimit -l 64 $ for n in `seq 1 5`; do i=1; while ./bpf-obj_get_info_by_fd; do i="$(($i+1))"; done &>/dev/null; echo $i; done 3 1448 484 1139 903 Yes, these were consequent invocations with no concurrency whatsoever. What can I say? It's definitely a kernel bug that has to be addressed on the kernel side. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/strace/strace/issues/74#issuecomment-562978462 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Dec 9 12:42:53 2019 From: notifications at github.com (Quentin Monnet) Date: Mon, 09 Dec 2019 04:42:53 -0800 Subject: [strace/strace] make check fails with -j16 and higher (#74) In-Reply-To: References: Message-ID: There is a delay indeed when the locked memory is being reclaimed after a BPF program or map is removed. If I understand correctly it could come from the `call_rcu()` in [`__bpf_put_prog_noref()`](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/bpf/syscall.c?h=v5.4#n1339). For the record, in bpftool we call `setrlimit()` to work around it and [raise the limit](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8302b9bd31d29f29dd24dd6b1e1e5682c302c11c) prior to running a succession of tests to check what BPF objects are supported by the system. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/strace/strace/issues/74#issuecomment-563221085 -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.chaignon at gmail.com Mon Dec 9 17:19:23 2019 From: paul.chaignon at gmail.com (Paul Chaignon) Date: Mon, 9 Dec 2019 18:19:23 +0100 Subject: [PATCH 1/2] bpf: update BPF constants Message-ID: <00a3a770c25fd809432f0abd3c07d45eeb559f72.1575905806.git.paul.chaignon@gmail.com> * xlat/bpf_attach_type.in (BPF_TRACE_RAW_TP): New constant introduced in Linux commit v5.5-rc1~174^2~249^2~4^2~1. (BPF_TRACE_FENTRY, BPF_TRACE_FEXIT): New constants introduced in Linux commit v5.5-rc1~174^2~49^2~12^2~16. * xlat/bpf_map_flags.in (BPF_F_MMAPABLE): New constant introduced in Linux commit v5.5-rc1~174^2~49^2~11^2~2. * xlat/bpf_prog_types.in (BPF_PROG_TYPE_TRACING): New constant introduced in Linux commit v5.5-rc1~174^2~249^2~4^2~1. * tests/bpf.c (BPF_MAP_CREATE_checks, BPF_PROG_LOAD_checks, BPF_PROG_QUERY_checks): Update expected outputs. * tests/kernel_version.c (print_bpf_attr, main): Likewise. Signed-off-by: Paul Chaignon --- tests/bpf.c | 27 ++++++++++++++++----------- tests/kernel_version.c | 6 +++--- xlat/bpf_attach_type.in | 3 +++ xlat/bpf_map_flags.in | 1 + xlat/bpf_prog_types.in | 1 + 5 files changed, 24 insertions(+), 14 deletions(-) diff --git a/tests/bpf.c b/tests/bpf.c index 9e5f9f5c..5cf79531 100644 --- a/tests/bpf.c +++ b/tests/bpf.c @@ -286,7 +286,7 @@ static struct bpf_attr_check BPF_MAP_CREATE_checks[] = { .key_size = 0xface1e55, .value_size = 0xbadc0ded, .max_entries = 0xbeefcafe, - .map_flags = 0xfffffc00, + .map_flags = 0xfffff800, .inner_map_fd = 2718281828, .numa_node = -1, .map_name = "", @@ -296,7 +296,7 @@ static struct bpf_attr_check BPF_MAP_CREATE_checks[] = { .str = "map_type=0x1a /* BPF_MAP_TYPE_??? */" ", key_size=4207812181, value_size=3134983661" ", max_entries=3203386110" - ", map_flags=0xfffffc00 /* BPF_F_??? */" + ", map_flags=0xfffff800 /* BPF_F_??? */" ", inner_map_fd=-1576685468" ", map_name=\"\", map_ifindex=3141592653", @@ -317,7 +317,8 @@ static struct bpf_attr_check BPF_MAP_CREATE_checks[] = { ", max_entries=3203386110" ", map_flags=BPF_F_NO_PREALLOC|BPF_F_NUMA_NODE" "|BPF_F_RDONLY|BPF_F_STACK_BUILD_ID" - "|BPF_F_RDONLY_PROG|BPF_F_CLONE|0xc0dedc00", + "|BPF_F_RDONLY_PROG|BPF_F_CLONE" + "|BPF_F_MMAPABLE|0xc0ded800", }, { /* 4 */ .data = { .BPF_MAP_CREATE_data = { @@ -335,7 +336,8 @@ static struct bpf_attr_check BPF_MAP_CREATE_checks[] = { ", max_entries=3203386110" ", map_flags=BPF_F_NO_PREALLOC|BPF_F_NUMA_NODE" "|BPF_F_RDONLY|BPF_F_STACK_BUILD_ID" - "|BPF_F_RDONLY_PROG|BPF_F_CLONE|0xc0dedc00" + "|BPF_F_RDONLY_PROG|BPF_F_CLONE" + "|BPF_F_MMAPABLE|0xc0ded800" ", inner_map_fd=-1576685468", }, { /* 5 */ @@ -354,7 +356,8 @@ static struct bpf_attr_check BPF_MAP_CREATE_checks[] = { ", max_entries=3203386110" ", map_flags=BPF_F_NO_PREALLOC|BPF_F_NUMA_NODE" "|BPF_F_RDONLY|BPF_F_STACK_BUILD_ID" - "|BPF_F_RDONLY_PROG|BPF_F_CLONE|0xc0dedc00" + "|BPF_F_RDONLY_PROG|BPF_F_CLONE" + "|BPF_F_MMAPABLE|0xc0ded800" ", inner_map_fd=-1576685468" ", numa_node=4294967295 /* NUMA_NO_NODE */", }, @@ -375,7 +378,8 @@ static struct bpf_attr_check BPF_MAP_CREATE_checks[] = { ", max_entries=3203386110" ", map_flags=BPF_F_NO_PREALLOC|BPF_F_NUMA_NODE" "|BPF_F_RDONLY|BPF_F_STACK_BUILD_ID" - "|BPF_F_RDONLY_PROG|BPF_F_CLONE|0xc0dedc00" + "|BPF_F_RDONLY_PROG|BPF_F_CLONE" + "|BPF_F_MMAPABLE|0xc0ded800" ", inner_map_fd=-1576685468" ", numa_node=4294967295 /* NUMA_NO_NODE */" ", map_name=\"fedcba987654321\"...", @@ -397,7 +401,8 @@ static struct bpf_attr_check BPF_MAP_CREATE_checks[] = { ", max_entries=3203386110" ", map_flags=BPF_F_NO_PREALLOC|BPF_F_NUMA_NODE" "|BPF_F_RDONLY|BPF_F_STACK_BUILD_ID" - "|BPF_F_RDONLY_PROG|BPF_F_CLONE|0xc0dedc00" + "|BPF_F_RDONLY_PROG|BPF_F_CLONE" + "|BPF_F_MMAPABLE|0xc0ded800" ", inner_map_fd=-1576685468" ", numa_node=4294967295 /* NUMA_NO_NODE */" ", map_name=\"0123456789abcde\"" @@ -612,7 +617,7 @@ static struct bpf_attr_check BPF_PROG_LOAD_checks[] = { }, { /* 1 */ .data = { .BPF_PROG_LOAD_data = { - .prog_type = 26, + .prog_type = 27, .insn_cnt = 0xbadc0ded, .insns = 0, .license = 0, @@ -623,7 +628,7 @@ static struct bpf_attr_check BPF_PROG_LOAD_checks[] = { .prog_flags = 0, } }, .size = offsetofend(struct BPF_PROG_LOAD_struct, prog_flags), - .str = "prog_type=0x1a /* BPF_PROG_TYPE_??? */" + .str = "prog_type=0x1b /* BPF_PROG_TYPE_??? */" ", insn_cnt=3134983661, insns=NULL, license=NULL" ", log_level=42, log_size=3141592653, log_buf=NULL" ", kern_version=KERNEL_VERSION(51966, 240, 13)" @@ -1083,7 +1088,7 @@ static struct bpf_attr_check BPF_PROG_QUERY_checks[] = { { /* 2 */ .data = { .BPF_PROG_QUERY_data = { .target_fd = 3141592653U, - .attach_type = 23, + .attach_type = 26, .query_flags = 0xfffffffe, .attach_flags = 0xfffffffc, .prog_ids = 0xffffffffffffffffULL, @@ -1091,7 +1096,7 @@ static struct bpf_attr_check BPF_PROG_QUERY_checks[] = { } }, .size = offsetofend(struct BPF_PROG_QUERY_struct, prog_cnt), .str = "query={target_fd=-1153374643" - ", attach_type=0x17 /* BPF_??? */" + ", attach_type=0x1a /* BPF_??? */" ", query_flags=0xfffffffe /* BPF_F_QUERY_??? */" ", attach_flags=0xfffffffc /* BPF_F_??? */" ", prog_ids=" diff --git a/tests/kernel_version.c b/tests/kernel_version.c index cfe75ade..009f9fd5 100644 --- a/tests/kernel_version.c +++ b/tests/kernel_version.c @@ -34,9 +34,9 @@ static void print_bpf_attr(void) { #if XLAT_RAW - printf("{prog_type=0x1a" + printf("{prog_type=0x1b" #else - printf("{prog_type=0x1a /* BPF_PROG_TYPE_??? */" + printf("{prog_type=0x1b /* BPF_PROG_TYPE_??? */" #endif ", insn_cnt=3134983661" ", insns=NULL" @@ -77,7 +77,7 @@ main(void) { long ret; struct BPF_PROG_LOAD_struct prog = { - .prog_type = 26, + .prog_type = 27, .insn_cnt = 0xbadc0ded, .insns = 0, .license = 0, diff --git a/xlat/bpf_attach_type.in b/xlat/bpf_attach_type.in index 60505746..c7ec3327 100644 --- a/xlat/bpf_attach_type.in +++ b/xlat/bpf_attach_type.in @@ -22,3 +22,6 @@ BPF_CGROUP_UDP4_RECVMSG 19 BPF_CGROUP_UDP6_RECVMSG 20 BPF_CGROUP_GETSOCKOPT 21 BPF_CGROUP_SETSOCKOPT 22 +BPF_TRACE_RAW_TP 23 +BPF_TRACE_FENTRY 24 +BPF_TRACE_FEXIT 25 diff --git a/xlat/bpf_map_flags.in b/xlat/bpf_map_flags.in index d4e5ab5a..f0484ab8 100644 --- a/xlat/bpf_map_flags.in +++ b/xlat/bpf_map_flags.in @@ -8,3 +8,4 @@ BPF_F_ZERO_SEED (1U << 6) BPF_F_RDONLY_PROG (1U << 7) BPF_F_WRONLY_PROG (1U << 8) BPF_F_CLONE (1U << 9) +BPF_F_MMAPABLE (1U << 10) diff --git a/xlat/bpf_prog_types.in b/xlat/bpf_prog_types.in index a72f5b52..97d99081 100644 --- a/xlat/bpf_prog_types.in +++ b/xlat/bpf_prog_types.in @@ -25,3 +25,4 @@ BPF_PROG_TYPE_FLOW_DISSECTOR 22 BPF_PROG_TYPE_CGROUP_SYSCTL 23 BPF_PROG_TYPE_RAW_TRACEPOINT_WRITABLE 24 BPF_PROG_TYPE_CGROUP_SOCKOPT 25 +BPF_PROG_TYPE_TRACING 26 -- 2.17.1 From paul.chaignon at gmail.com Mon Dec 9 17:19:45 2019 From: paul.chaignon at gmail.com (Paul Chaignon) Date: Mon, 9 Dec 2019 18:19:45 +0100 Subject: [PATCH 2/2] bpf: support new fields for BPF_PROG_LOAD In-Reply-To: <00a3a770c25fd809432f0abd3c07d45eeb559f72.1575905806.git.paul.chaignon@gmail.com> References: <00a3a770c25fd809432f0abd3c07d45eeb559f72.1575905806.git.paul.chaignon@gmail.com> Message-ID: <7d5c53900099bbf6f617915d73751ba4eb7869c3.1575905806.git.paul.chaignon@gmail.com> * bpf_attr.h (BPF_PROG_LOAD_struct): New fields introduced in Linux commits v5.5-rc1~174^2~310^2~19^2~7 and v5.5-rc1~174^2~49^2~12^2~3. * bpf.c (BEGIN_BPF_CMD_DECODER(BPF_PROG_LOAD)): Decode the new fields. * tests/bpf.c (BPF_PROG_LOAD_checks): Update expected outputs. * tests/bpf-obj_get_info_by_fd.c (print_prog_load): Likewise. * tests/kernel_version.c (print_bpf_attr): Likewise. Signed-off-by: Paul Chaignon --- bpf.c | 10 ++++++++++ bpf_attr.h | 6 ++++-- tests/bpf-obj_get_info_by_fd.c | 4 ++++ tests/bpf.c | 14 +++++++++----- tests/kernel_version.c | 4 +++- 5 files changed, 30 insertions(+), 8 deletions(-) diff --git a/bpf.c b/bpf.c index 9b6fb488..b42cf29d 100644 --- a/bpf.c +++ b/bpf.c @@ -343,6 +343,16 @@ BEGIN_BPF_CMD_DECODER(BPF_PROG_LOAD) PRINT_FIELD_U(", ", attr, line_info_rec_size); PRINT_FIELD_ADDR64(", ", attr, line_info); PRINT_FIELD_U(", ", attr, line_info_cnt); + + /* attach_btf_id was added in Linux commit v5.5-rc1~174^2~310^2~19^2~7 */ + if (len <= offsetof(struct BPF_PROG_LOAD_struct, attach_btf_id)) + break; + PRINT_FIELD_U(", ", attr, attach_btf_id); + + /* attach_prog_fd was added in Linux commit v5.5-rc1~174^2~49^2~12^2~3 */ + if (len <= offsetof(struct BPF_PROG_LOAD_struct, attach_prog_fd)) + break; + PRINT_FIELD_FD(", ", attr, attach_prog_fd, tcp); } END_BPF_CMD_DECODER(RVAL_DECODED | RVAL_FD) diff --git a/bpf_attr.h b/bpf_attr.h index 6695a2fe..33dd54af 100644 --- a/bpf_attr.h +++ b/bpf_attr.h @@ -124,11 +124,13 @@ struct BPF_PROG_LOAD_struct { uint32_t line_info_rec_size; uint64_t ATTRIBUTE_ALIGNED(8) line_info; uint32_t line_info_cnt; + uint32_t attach_btf_id; + uint32_t attach_prog_fd; }; # define BPF_PROG_LOAD_struct_size \ - offsetofend(struct BPF_PROG_LOAD_struct, line_info_cnt) -# define expected_BPF_PROG_LOAD_struct_size 108 + offsetofend(struct BPF_PROG_LOAD_struct, attach_prog_fd) +# define expected_BPF_PROG_LOAD_struct_size 116 struct BPF_OBJ_PIN_struct { uint64_t ATTRIBUTE_ALIGNED(8) pathname; diff --git a/tests/bpf-obj_get_info_by_fd.c b/tests/bpf-obj_get_info_by_fd.c index 3bfa6402..c486d77f 100644 --- a/tests/bpf-obj_get_info_by_fd.c +++ b/tests/bpf-obj_get_info_by_fd.c @@ -205,6 +205,10 @@ print_prog_load(void *attr_void, size_t size, long rc) printf(", line_info=NULL"); if (size > offsetof(struct BPF_PROG_LOAD_struct, line_info_cnt)) printf(", line_info_cnt=0"); + if (size > offsetof(struct BPF_PROG_LOAD_struct, attach_btf_id)) + printf(", attach_btf_id=0"); + if (size > offsetof(struct BPF_PROG_LOAD_struct, attach_prog_fd)) + printf(", attach_prog_fd=0"); printf("}, %zu) = ", size); if (rc >= 0) printf("%ld\n", rc); diff --git a/tests/bpf.c b/tests/bpf.c index 5cf79531..24b70339 100644 --- a/tests/bpf.c +++ b/tests/bpf.c @@ -606,7 +606,7 @@ print_BPF_PROG_LOAD_attr4(const struct bpf_attr_check *check, unsigned long addr license, IFINDEX_LO_STR); } -static_assert(ARRAY_SIZE(bpf_prog_types_xdata) == 26, +static_assert(ARRAY_SIZE(bpf_prog_types_xdata) == 27, "The prog_type for test 5 below needs to be updated"); static struct bpf_attr_check BPF_PROG_LOAD_checks[] = { { @@ -691,7 +691,7 @@ static struct bpf_attr_check BPF_PROG_LOAD_checks[] = { }, { /* 5 */ .data = { .BPF_PROG_LOAD_data = { - .prog_type = 25, + .prog_type = 26, .insn_cnt = 0xbadc0ded, .insns = 0xffffffff00000000, .license = 0xffffffff00000000, @@ -703,7 +703,7 @@ static struct bpf_attr_check BPF_PROG_LOAD_checks[] = { .prog_name = "fedcba987654321", } }, .size = offsetofend(struct BPF_PROG_LOAD_struct, prog_name), - .str = "prog_type=BPF_PROG_TYPE_CGROUP_SOCKOPT" + .str = "prog_type=BPF_PROG_TYPE_TRACING" ", insn_cnt=3134983661" ", insns=" BIG_ADDR("0xffffffff00000000", "NULL") ", license=" BIG_ADDR("0xffffffff00000000", "NULL") @@ -723,10 +723,12 @@ static struct bpf_attr_check BPF_PROG_LOAD_checks[] = { .func_info_cnt = 0xdad3bef4, .line_info_rec_size = 0xdad5bef6, .line_info = 0xfac5fed5fac7fed8, - .line_info_cnt = 0xdad7bef8 + .line_info_cnt = 0xdad7bef8, + .attach_btf_id = 0xdad7befa, + .attach_prog_fd = 0xbadc0def, } }, .size = offsetofend(struct BPF_PROG_LOAD_struct, - line_info_cnt), + attach_prog_fd), .str = "prog_type=BPF_PROG_TYPE_UNSPEC" ", insn_cnt=0" ", insns=NULL" @@ -746,6 +748,8 @@ static struct bpf_attr_check BPF_PROG_LOAD_checks[] = { ", line_info_rec_size=3671441142" ", line_info=0xfac5fed5fac7fed8" ", line_info_cnt=3671572216" + ", attach_btf_id=3671572218" + ", attach_prog_fd=-1159983633" }, }; diff --git a/tests/kernel_version.c b/tests/kernel_version.c index 009f9fd5..a667b584 100644 --- a/tests/kernel_version.c +++ b/tests/kernel_version.c @@ -69,7 +69,9 @@ print_bpf_attr(void) ", func_info_cnt=0" ", line_info_rec_size=0" ", line_info=NULL" - ", line_info_cnt=0}"); + ", line_info_cnt=0" + ", attach_btf_id=0" + ", attach_prog_fd=0}"); } int -- 2.17.1 From ldv at altlinux.org Mon Dec 9 19:31:21 2019 From: ldv at altlinux.org (Dmitry V. Levin) Date: Mon, 9 Dec 2019 22:31:21 +0300 Subject: [PATCH 1/2] bpf: update BPF constants In-Reply-To: <00a3a770c25fd809432f0abd3c07d45eeb559f72.1575905806.git.paul.chaignon@gmail.com> References: <00a3a770c25fd809432f0abd3c07d45eeb559f72.1575905806.git.paul.chaignon@gmail.com> Message-ID: <20191209193121.GA12957@altlinux.org> On Mon, Dec 09, 2019 at 06:19:23PM +0100, Paul Chaignon wrote: > * xlat/bpf_attach_type.in (BPF_TRACE_RAW_TP): New constant introduced in > Linux commit v5.5-rc1~174^2~249^2~4^2~1. > (BPF_TRACE_FENTRY, BPF_TRACE_FEXIT): New constants introduced in Linux > commit v5.5-rc1~174^2~49^2~12^2~16. > * xlat/bpf_map_flags.in (BPF_F_MMAPABLE): New constant introduced in Linux > commit v5.5-rc1~174^2~49^2~11^2~2. > * xlat/bpf_prog_types.in (BPF_PROG_TYPE_TRACING): New constant > introduced in Linux commit v5.5-rc1~174^2~249^2~4^2~1. > * tests/bpf.c (BPF_MAP_CREATE_checks, BPF_PROG_LOAD_checks, > BPF_PROG_QUERY_checks): Update expected outputs. > * tests/kernel_version.c (print_bpf_attr, main): Likewise. Great! Could you add a NEWS entry for each of two bpf update patches, please? -- ldv -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From notifications at github.com Mon Dec 9 19:08:44 2019 From: notifications at github.com (Dmitry V. Levin) Date: Mon, 09 Dec 2019 11:08:44 -0800 Subject: [strace/strace] make check fails with -j16 and higher (#74) In-Reply-To: References: Message-ID: On Mon, Dec 09, 2019 at 04:42:52AM -0800, Quentin Monnet wrote: > There is a delay indeed when the locked memory is being reclaimed after a BPF program or map is removed. If I understand correctly it could come from the `call_rcu()` in [`__bpf_put_prog_noref()`](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/bpf/syscall.c?h=v5.4#n1339). > > For the record, in bpftool we call `setrlimit()` to work around it and [raise the limit](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8302b9bd31d29f29dd24dd6b1e1e5682c302c11c) prior to running a succession of tests to check what BPF objects are supported by the system. Thanks Quentin. We could use the same approach in the strace test suite, but unlike iproute2 and bpftool, strace test suite does not usually have any privileges to raise its RLIMIT_MEMLOCK above the hard limit which is set by default to 64K. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/strace/strace/issues/74#issuecomment-563385507 -------------- next part -------------- An HTML attachment was scrubbed... URL: