diff --git a/README.md b/README.md index ffaa15d..ec8f1e5 100644 --- a/README.md +++ b/README.md @@ -28,7 +28,9 @@ Unlike other approaches: - What were the trade-offs considered in design decisions, and how do they manifest in the system's implementation? - How does the collaboration between developers affect the consistency and coherence of feature development? -## Workflow / Methodology +Here is an example of analysis: **[docs/report_ebpf.md](docs/report_ebpf.md).** (Not yet complete...more is adding) + +## Workflow / Methodolog The core idea of Code-survey is to treat LLMs like human participants in a survey: @@ -176,8 +178,13 @@ For a more detailed explanation and the general approach, see the [docs/best-pra ## References +Linux development: + 1. [Submitting patches: the essential guide to getting your code into the kernel](https://www.kernel.org/doc/html/v4.10/process/submitting-patches.html) 2. [how to ask question in maillist](https://www.linuxquestions.org/questions/linux-kernel-70/how-to-ask-question-in-maillist-4175719442/) 3. [How to Communicate When Submitting Patches: An Empirical Study of the Linux Kernel](https://dl.acm.org/doi/abs/10.1145/3359210) 3. [Differentiating Communication Styles of Leaders on the Linux Kernel Mailing List](https://dl.acm.org/doi/abs/10.1145/2957792) +AI model: + +- [Introducing OpenAI o1-preview](https://openai.com/index/introducing-openai-o1-preview/) They can reason through complex tasks and solve harder problems than previous models in science, coding, and math. \ No newline at end of file diff --git a/data/commit_survey.csv b/data/commit_survey.csv index c3e3386..652a024 100644 --- a/data/commit_survey.csv +++ b/data/commit_survey.csv @@ -10468,3 +10468,686 @@ acf1c3d68e9a31f10d92bc67ad4673cdae5e8d92,acf1c3d68e9a31f10d92bc67ad4673cdae5e8d9 "8c061865f5ff66adca8056327accff1bf7d09d35","8c061865f5ff66adca8056327accff1bf7d09d35","Andrey Ignatov","rdna@fb.com","1585075895","Daniel Borkmann","daniel@iogearbox.net","1585177716","98dd009da525f7a23813f996b77e93b4c79ea9be","aa5e2af660fc6e35b9518d68dd7e1bb736e9f7e7","bpf: Document bpf_inspect drgn tool It's a follow-up for discussion in [1]. drgn tool bpf_inspect.py was merged to drgn repo in [2]. Document it in kernel tree to make BPF developers aware that the tool exists and can help with getting BPF state unavailable via UAPI. For now it's just one tool but the doc is written in a way that allows to cover more tools in the future if needed. Please refer to the doc itself for more details. The patch was tested by `make htmldocs` and sanity-checking that resulting html looks good. v2 -> v3: - two sections: ""Description"" and ""Getting started"" (Daniel); - add examples in ""Getting started"" section (Daniel); - add ""Customization"" section to show how tool can be customized. v1 -> v2: - better ""BPF drgn tools"" section (Alexei) [1] https://lore.kernel.org/bpf/20200228201514.GB51456@rdna-mbp/T/#mefed65e8a98116bd5d07d09a570a3eac46724951 [2] https://github.com/osandov/drgn/pull/49 Signed-off-by: Andrey Ignatov Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200324185135.1431038-1-rdna@fb.com","Documentation/bpf/drgn.rst | 213 ++++++++++++++++++++++++++++++++++++++++++++; Documentation/bpf/index.rst | 5 +-; 2 files changed, 216 insertions(+), 2 deletions(-)","The commit introduces documentation for the bpf_inspect drgn tool, making BPF developers aware of its usage and customizations.","documentation,bpf_inspect,drgn","A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","I'm not sure about the implementation component of the commit. The component affected by It is unclear.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" "1b649e0bcae71c118c1333e02249a7510ba7f70a","1b649e0bcae71c118c1333e02249a7510ba7f70a","Linus Torvalds","torvalds@linux-foundation.org","1585169885","Linus Torvalds","torvalds@linux-foundation.org","1585169885","9daba29f622149a290500cc2d0897ab5fedf467e","1dfb642b10158b45068102402decc3bcf853cb76 2910594fd38d1cb3c32fbf235e6c6228c780ab87","Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from David Miller: 1) Fix deadlock in bpf_send_signal() from Yonghong Song. 2) Fix off by one in kTLS offload of mlx5, from Tariq Toukan. 3) Add missing locking in iwlwifi mvm code, from Avraham Stern. 4) Fix MSG_WAITALL handling in rxrpc, from David Howells. 5) Need to hold RTNL mutex in tcindex_partial_destroy_work(), from Cong Wang. 6) Fix producer race condition in AF_PACKET, from Willem de Bruijn. 7) cls_route removes the wrong filter during change operations, from Cong Wang. 8) Reject unrecognized request flags in ethtool netlink code, from Michal Kubecek. 9) Need to keep MAC in reset until PHY is up in bcmgenet driver, from Doug Berger. 10) Don't leak ct zone template in act_ct during replace, from Paul Blakey. 11) Fix flushing of offloaded netfilter flowtable flows, also from Paul Blakey. 12) Fix throughput drop during tx backpressure in cxgb4, from Rahul Lakkireddy. 13) Don't let a non-NULL skb->dev leave the TCP stack, from Eric Dumazet. 14) TCP_QUEUE_SEQ socket option has to update tp->copied_seq as well, also from Eric Dumazet. 15) Restrict macsec to ethernet devices, from Willem de Bruijn. 16) Fix reference leak in some ethtool *_SET handlers, from Michal Kubecek. 17) Fix accidental disabling of MSI for some r8169 chips, from Heiner Kallweit. * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (138 commits) net: Fix CONFIG_NET_CLS_ACT=n and CONFIG_NFT_FWD_NETDEV={y, m} build net: ena: Add PCI shutdown handler to allow safe kexec selftests/net/forwarding: define libs as TEST_PROGS_EXTENDED selftests/net: add missing tests to Makefile r8169: re-enable MSI on RTL8168c net: phy: mdio-bcm-unimac: Fix clock handling cxgb4/ptp: pass the sign of offset delta in FW CMD net: dsa: tag_8021q: replace dsa_8021q_remove_header with __skb_vlan_pop net: cbs: Fix software cbs to consider packet sending time net/mlx5e: Do not recover from a non-fatal syndrome net/mlx5e: Fix ICOSQ recovery flow with Striding RQ net/mlx5e: Fix missing reset of SW metadata in Striding RQ reset net/mlx5e: Enhance ICOSQ WQE info fields net/mlx5_core: Set IB capability mask1 to fix ib_srpt connection failure selftests: netfilter: add nfqueue test case netfilter: nft_fwd_netdev: allow to redirect to ifb via ingress netfilter: nft_fwd_netdev: validate family and chain type netfilter: nft_set_rbtree: Detect partial overlaps on insertion netfilter: nft_set_rbtree: Introduce and use nft_rbtree_interval_start() netfilter: nft_set_pipapo: Separate partial and complete overlap cases on insertion ...","","This commit merges multiple networking fixes from the netdev repository into the main branch.","networking, fixes, merge","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" "aa5e2af660fc6e35b9518d68dd7e1bb736e9f7e7","aa5e2af660fc6e35b9518d68dd7e1bb736e9f7e7","Daniel T. Lee","danieltimlee@gmail.com","1584785064","Daniel Borkmann","daniel@iogearbox.net","1584998877","f99d5a219ca3d9f2026770dae2c1a7930eba071e","24a6034acc922f1f6292636be4ec4dc3d9b4d2d7","samples, bpf: Refactor perf_event user program with libbpf bpf_link The bpf_program__attach of libbpf(using bpf_link) is much more intuitive than the previous method using ioctl. bpf_program__attach_perf_event manages the enable of perf_event and attach of BPF programs to it, so there's no neeed to do this directly with ioctl. In addition, bpf_link provides consistency in the use of API because it allows disable (detach, destroy) for multiple events to be treated as one bpf_link__destroy. Also, bpf_link__destroy manages the close() of perf_event fd. This commit refactors samples that attach the bpf program to perf_event by using libbbpf instead of ioctl. Also the bpf_load in the samples were removed and migrated to use libbbpf API. Signed-off-by: Daniel T. Lee Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200321100424.1593964-3-danieltimlee@gmail.com","samples/bpf/Makefile | 4 +-; samples/bpf/sampleip_user.c | 98 +++++++++++++++++++----------; samples/bpf/trace_event_user.c | 139 +++++++++++++++++++++++++++--------------; 3 files changed, 159 insertions(+), 82 deletions(-)","Refactors perf_event sample programs to use libbpf API instead of ioctl for improved management consistency.","refactor, libbpf, perf_event","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.', 'kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"24a6034acc922f1f6292636be4ec4dc3d9b4d2d7","24a6034acc922f1f6292636be4ec4dc3d9b4d2d7","Daniel T. Lee","danieltimlee@gmail.com","1584785063","Daniel Borkmann","daniel@iogearbox.net","1584998871","727c570476d15c624e63c61ffac6deb56f71bf05","c9b24312040edaa89acb6fb91a9a53fb4775309e","samples, bpf: Move read_trace_pipe to trace_helpers To reduce the reliance of trace samples (trace*_user) on bpf_load, move read_trace_pipe to trace_helpers. By moving this bpf_loader helper elsewhere, trace functions can be easily migrated to libbbpf. Signed-off-by: Daniel T. Lee Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200321100424.1593964-2-danieltimlee@gmail.com","samples/bpf/Makefile | 4 ++--; samples/bpf/bpf_load.c | 20 --------------------; samples/bpf/bpf_load.h | 1 -; samples/bpf/tracex1_user.c | 1 +; samples/bpf/tracex5_user.c | 1 +; tools/testing/selftests/bpf/trace_helpers.c | 23 +++++++++++++++++++++++; tools/testing/selftests/bpf/trace_helpers.h | 1 +; 7 files changed, 28 insertions(+), 23 deletions(-)","This commit moves 'read_trace_pipe' from 'bpf_load' to 'trace_helpers' improving trace function migration to libbbpf.","trace_helpers,bpf_load,libbbpf","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.']" +"c9b24312040edaa89acb6fb91a9a53fb4775309e","c9b24312040edaa89acb6fb91a9a53fb4775309e","Martin KaFai Lau","kafai@fb.com","1584717667","Daniel Borkmann","daniel@iogearbox.net","1584993115","24b2e33e4c91a8e5ca60ad7464adaafcad108e37","ab14fd4ee82ead4b058034509971b8bd749862ff","bpf: Add tests for bpf_sk_storage to bpf_tcp_ca This patch adds test to exercise the bpf_sk_storage_get() and bpf_sk_storage_delete() helper from the bpf_dctcp.c. The setup and check on the sk_storage is done immediately before and after the connect(). This patch also takes this chance to move the pthread_create() after the connect() has been done. That will remove the need of the ""wait_thread"" label. Signed-off-by: Martin KaFai Lau Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200320152107.2169904-1-kafai@fb.com",".../testing/selftests/bpf/prog_tests/bpf_tcp_ca.c | 39 +++++++++++++++++-----; tools/testing/selftests/bpf/progs/bpf_dctcp.c | 16 +++++++++; 2 files changed, 47 insertions(+), 8 deletions(-)","This commit adds test cases for bpf_sk_storage to bpf_tcp_ca in eBPF.","tests bpf_sk_storage bpf_tcp_ca","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime."", ""I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear.""]" +"ab14fd4ee82ead4b058034509971b8bd749862ff","ab14fd4ee82ead4b058034509971b8bd749862ff","Martin KaFai Lau","kafai@fb.com","1584717661","Daniel Borkmann","daniel@iogearbox.net","1584993115","6560d904aeea7c1aeb23f3a2cff643c28a9eeaca","1440e7929392297f1578a54f372e9821bb1b0658","bpf: Add bpf_sk_storage support to bpf_tcp_ca This patch adds bpf_sk_storage_get() and bpf_sk_storage_delete() helper to the bpf_tcp_ca's struct_ops. That would allow bpf-tcp-cc to: 1) share sk private data with other bpf progs. 2) use bpf_sk_storage as a private storage for a bpf-tcp-cc if the existing icsk_ca_priv is not big enough. Signed-off-by: Martin KaFai Lau Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200320152101.2169498-1-kafai@fb.com","net/ipv4/bpf_tcp_ca.c | 33 +++++++++++++++++++++++++++++++++; 1 file changed, 33 insertions(+)","The commit enhances bpf_tcp_ca by adding support for bpf_sk_storage to share or store private data.","bpf_sk_storage,bpf_tcp_ca,struct_ops","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"443bc639e518c6c4e8fc2e0456cccf3a04f6e77f","443bc639e518c6c4e8fc2e0456cccf3a04f6e77f","Jin Yao","yao.jin@linux.intel.com","1582778377","Arnaldo Carvalho de Melo","acme@redhat.com","1584972509","4227508f030e1504867d04b71bcf38ad309a6d4e","7eec00a74720d35b6d89505350e5b08ecef376c0","perf report: Print al_addr when symbol is not found For branch mode, if the symbol is not found, it prints the address. For example, 0x0000555eee0365a0 in below output. Overhead Command Source Shared Object Source Symbol Target Symbol 17.55% div libc-2.27.so [.] __random [.] __random 6.11% div div [.] 0x0000555eee0365a0 [.] rand 6.10% div libc-2.27.so [.] rand [.] 0x0000555eee036769 5.80% div libc-2.27.so [.] __random_r [.] __random 5.72% div libc-2.27.so [.] __random [.] __random_r 5.62% div libc-2.27.so [.] __random_r [.] __random_r 5.38% div libc-2.27.so [.] __random [.] rand 4.56% div libc-2.27.so [.] __random [.] __random 4.49% div div [.] 0x0000555eee036779 [.] 0x0000555eee0365ff 4.25% div div [.] 0x0000555eee0365fa [.] 0x0000555eee036760 But it's not very easy to understand what the instructions are in the binary. So this patch uses the al_addr instead. With this patch, the output is Overhead Command Source Shared Object Source Symbol Target Symbol 17.55% div libc-2.27.so [.] __random [.] __random 6.11% div div [.] 0x00000000000005a0 [.] rand 6.10% div libc-2.27.so [.] rand [.] 0x0000000000000769 5.80% div libc-2.27.so [.] __random_r [.] __random 5.72% div libc-2.27.so [.] __random [.] __random_r 5.62% div libc-2.27.so [.] __random_r [.] __random_r 5.38% div libc-2.27.so [.] __random [.] rand 4.56% div libc-2.27.so [.] __random [.] __random 4.49% div div [.] 0x0000000000000779 [.] 0x00000000000005ff 4.25% div div [.] 0x00000000000005fa [.] 0x0000000000000760 Now we can use objdump to dump the object starting from 0x5a0. For example, objdump -d --start-address 0x5a0 div 00000000000005a0 : 5a0: ff 25 2a 0a 20 00 jmpq *0x200a2a(%rip) # 200fd0 <__cxa_finalize@plt+0x200a20> 5a6: 68 02 00 00 00 pushq $0x2 5ab: e9 c0 ff ff ff jmpq 570 ... Committer testing: [root@seventh ~]# perf record -a -b sleep 1 [root@seventh ~]# perf report --header-only | grep cpudesc # cpudesc : Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz [root@seventh ~]# perf evlist -v cycles: size: 120, { sample_period, sample_freq }: 4000, sample_type: IP|TID|TIME|CPU|PERIOD|BRANCH_STACK, read_format: ID, disabled: 1, inherit: 1, mmap: 1, comm: 1, freq: 1, task: 1, precise_ip: 3, sample_id_all: 1, exclude_guest: 1, mmap2: 1, comm_exec: 1, ksymbol: 1, bpf_event: 1, branch_sample_type: ANY [root@seventh ~]# Before: [root@seventh ~]# perf report --stdio --dso libsystemd-shared-241.so | head -20 # To display the perf.data header info, please use --header/--header-only options. # # # Total Lost Samples: 0 # # Samples: 2K of event 'cycles' # Event count (approx.): 2240 # # Overhead Command Source Shared Object Source Symbol Target Symbol Basic Block Cycles # ........ ............... ........................ ...................... ...................... .................. # 0.13% systemd-journal libc-2.29.so [.] cfree@GLIBC_2.2.5 [.] _int_free 1 0.09% systemd libsystemd-shared-241.so [.] 0x00007fe406465c82 [.] 0x00007fe406465d80 1 0.09% systemd libsystemd-shared-241.so [.] 0x00007fe406465ded [.] 0x00007fe406465c30 1 0.09% systemd libsystemd-shared-241.so [.] 0x00007fe406465e4e [.] 0x00007fe406465de0 1 0.09% systemd-journal systemd-journald [.] free@plt [.] cfree@GLIBC_2.2.5 1 0.09% systemd-journal libc-2.29.so [.] _int_free [.] _int_free 18 0.09% systemd-journal libc-2.29.so [.] _int_free [.] _int_free 2 0.04% systemd libsystemd-shared-241.so [.] bus_resolve@plt [.] bus_resolve 204 0.04% systemd libsystemd-shared-241.so [.] getpid_cached@plt [.] getpid_cached 7 [root@seventh ~]# After: [root@seventh ~]# perf report --stdio --dso libsystemd-shared-241.so | head -20 # To display the perf.data header info, please use --header/--header-only options. # # # Total Lost Samples: 0 # # Samples: 2K of event 'cycles' # Event count (approx.): 2240 # # Overhead Command Source Shared Object Source Symbol Target Symbol Basic Block Cycles # ........ ............... ........................ ...................... ...................... .................. # 0.13% systemd-journal libc-2.29.so [.] cfree@GLIBC_2.2.5 [.] _int_free 1 0.09% systemd libsystemd-shared-241.so [.] 0x00000000000f7c82 [.] 0x00000000000f7d80 1 0.09% systemd libsystemd-shared-241.so [.] 0x00000000000f7ded [.] 0x00000000000f7c30 1 0.09% systemd libsystemd-shared-241.so [.] 0x00000000000f7e4e [.] 0x00000000000f7de0 1 0.09% systemd-journal systemd-journald [.] free@plt [.] cfree@GLIBC_2.2.5 1 0.09% systemd-journal libc-2.29.so [.] _int_free [.] _int_free 18 0.09% systemd-journal libc-2.29.so [.] _int_free [.] _int_free 2 0.04% systemd libsystemd-shared-241.so [.] bus_resolve@plt [.] bus_resolve 204 0.04% systemd libsystemd-shared-241.so [.] getpid_cached@plt [.] getpid_cached 7 [root@seventh ~]# Lets use -v to get full paths and then try objdump on the unresolved address: [root@seventh ~]# perf report -v --stdio --dso libsystemd-shared-241.so |& grep libsystemd-shared-241.so | tail -1 0.04% systemd-journal /usr/lib/systemd/libsystemd-shared-241.so 0x80c1a B [.] 0x0000000000080c1a 0x80a95 B [.] 0x0000000000080a95 61 [root@seventh ~]# [root@seventh ~]# objdump -d --start-address 0x00000000000f7d80 /usr/lib/systemd/libsystemd-shared-241.so | head -20 /usr/lib/systemd/libsystemd-shared-241.so: file format elf64-x86-64 Disassembly of section .text: 00000000000f7d80 : f7d80: 41 39 11 cmp %edx,(%r9) f7d83: 0f 84 ff fe ff ff je f7c88 f7d89: 4c 8d 05 97 09 0c 00 lea 0xc0997(%rip),%r8 # 1b8727 f7d90: b9 49 00 00 00 mov $0x49,%ecx f7d95: 48 8d 15 c9 f5 0b 00 lea 0xbf5c9(%rip),%rdx # 1b7365 f7d9c: 31 ff xor %edi,%edi f7d9e: 48 8d 35 9b ff 0b 00 lea 0xbff9b(%rip),%rsi # 1b7d40 f7da5: e8 a6 d6 f4 ff callq 45450 f7daa: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) f7db0: 41 56 push %r14 f7db2: 41 55 push %r13 f7db4: 41 54 push %r12 f7db6: 55 push %rbp [root@seventh ~]# If we tried the the reported address before this patch: [root@seventh ~]# objdump -d --start-address 0x00007fe406465d80 /usr/lib/systemd/libsystemd-shared-241.so | head -20 /usr/lib/systemd/libsystemd-shared-241.so: file format elf64-x86-64 [root@seventh ~]# Signed-off-by: Jin Yao Tested-by: Arnaldo Carvalho de Melo Tested-by: Ravi Bangoria Acked-by: Jiri Olsa Cc: Alexander Shishkin Cc: Andi Kleen Cc: Kan Liang Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/20200227043939.4403-2-yao.jin@linux.intel.com Signed-off-by: Arnaldo Carvalho de Melo ","tools/perf/util/sort.c | 6 ++++--; 1 file changed, 4 insertions(+), 2 deletions(-)","This commit updates the 'perf report' tool to improve the handling of unresolved symbols by displaying alternative addresses.","perf,report,symbol","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.","It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.","[""It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.""]" +"e28596012d1a482641a2110ed1c4c09ce98562b3","e28596012d1a482641a2110ed1c4c09ce98562b3","David S. Miller","davem@davemloft.net","1584846497","David S. Miller","davem@davemloft.net","1584846497","9c1964e017b681e310c7ec48352bd124da90930c","26922c0ef33f2b24192f567db9d01ce4fa289b54 d5bee7374b68de3c44586d46e9e61ffc97a1e886","Merge branch 'net-tls-Annotate-lockless-access-to-sk_prot' Jakub Sitnicki says: ==================== net/tls: Annotate lockless access to sk_prot We have recently noticed that there is a case of lockless read/write to sk->sk_prot [0]. sockmap code on psock tear-down writes to sk->sk_prot, while holding sk_callback_lock. Concurrently, tcp can access it. Usually to read out the sk_prot pointer and invoke one of the ops, sk->sk_prot->handler(). The lockless write (lockless in regard to concurrent reads) happens on the following paths: tcp_bpf_{recvmsg|sendmsg} / sock_map_unref sk_psock_put sk_psock_drop sk_psock_restore_proto WRITE_ONCE(sk->sk_prot, proto) To prevent load/store tearing [1], and to make tooling aware of intentional shared access [2], we need to annotate sites that access sk_prot with READ_ONCE/WRITE_ONCE. This series kicks off the effort to do it. Starting with net/tls. [0] https://lore.kernel.org/bpf/a6bf279e-a998-84ab-4371-cd6c1ccbca5d@gmail.com/ [1] https://lwn.net/Articles/793253/ [2] https://github.com/google/ktsan/wiki/READ_ONCE-and-WRITE_ONCE ==================== Signed-off-by: David S. Miller ","","This commit merges annotations for lockless access to sk_prot in the net/tls subsystem.","net,tls,sk_prot","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"d5bee7374b68de3c44586d46e9e61ffc97a1e886","d5bee7374b68de3c44586d46e9e61ffc97a1e886","Jakub Sitnicki","jakub@cloudflare.com","1584464679","David S. Miller","davem@davemloft.net","1584846497","9c1964e017b681e310c7ec48352bd124da90930c","5bb4c45d466cb28dd0a7f15f80c4cb7768054e94","net/tls: Annotate access to sk_prot with READ_ONCE/WRITE_ONCE sockmap performs lockless writes to sk->sk_prot on the following paths: tcp_bpf_{recvmsg|sendmsg} / sock_map_unref sk_psock_put sk_psock_drop sk_psock_restore_proto WRITE_ONCE(sk->sk_prot, proto) To prevent load/store tearing [1], and to make tooling aware of intentional shared access [2], we need to annotate other sites that access sk_prot with READ_ONCE/WRITE_ONCE macros. Change done with Coccinelle with following semantic patch: @@ expression E; identifier I; struct sock *sk; identifier sk_prot =~ ""^sk_prot$""; @@ ( E = -sk->sk_prot +READ_ONCE(sk->sk_prot) | -sk->sk_prot = E +WRITE_ONCE(sk->sk_prot, E) | -sk->sk_prot +READ_ONCE(sk->sk_prot) ->I ) Signed-off-by: Jakub Sitnicki Signed-off-by: David S. Miller ","net/tls/tls_device.c | 2 +-; net/tls/tls_main.c | 9 +++++----; 2 files changed, 6 insertions(+), 5 deletions(-)","Annotate access to sk_prot with READ_ONCE/WRITE_ONCE macros in net/tls to prevent tearing.","sk_prot, READ_ONCE, WRITE_ONCE","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.","I'm not sure about the logic component of the commit. The affected logic component is unclear.","[""It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.""]" +"1440e7929392297f1578a54f372e9821bb1b0658","1440e7929392297f1578a54f372e9821bb1b0658","Bill Wendling","morbo@google.com","1584735310","Daniel Borkmann","daniel@iogearbox.net","1584737172","184970998d630dac13e71ce33a9951f60c3191eb","c0fd336ea4ca82377fbb0954db09d765eb794339","selftests/bpf: Fix mix of tabs and spaces Clang's -Wmisleading-indentation warns about misleading indentations if there's a mixture of spaces and tabs. Remove extraneous spaces. Signed-off-by: Bill Wendling Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200320201510.217169-1-morbo@google.com","tools/testing/selftests/bpf/prog_tests/btf_dump.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","The commit fixes a mix of tabs and spaces to address misleading indentation warnings in BPF selftest code.","tabs, spaces, indentation","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"5c6f25887963f15492b604dd25cb149c501bbabf","5c6f25887963f15492b604dd25cb149c501bbabf","Greg Kroah-Hartman","gregkh@linuxfoundation.org","1584721378","Daniel Borkmann","daniel@iogearbox.net","1584734722","0ca35ad39945fc8e516682d2dd353e2802bfddc6","8096f229421f7b22433775e928d506f0342e5907","bpf: Explicitly memset some bpf info structures declared on the stack Trying to initialize a structure with ""= {};"" will not always clean out all padding locations in a structure. So be explicit and call memset to initialize everything for a number of bpf information structures that are then copied from userspace, sometimes from smaller memory locations than the size of the structure. Reported-by: Daniel Borkmann Signed-off-by: Greg Kroah-Hartman Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200320162258.GA794295@kroah.com","kernel/bpf/btf.c | 3 ++-; kernel/bpf/syscall.c | 6 ++++--; 2 files changed, 6 insertions(+), 3 deletions(-)","The commit fixes potential padding issues in bpf info structures by explicitly initializing them using memset.","memset,structures,padding","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"8096f229421f7b22433775e928d506f0342e5907","8096f229421f7b22433775e928d506f0342e5907","Greg Kroah-Hartman","gregkh@linuxfoundation.org","1584697693","Daniel Borkmann","daniel@iogearbox.net","1584734670","fb6259035e82cb890d5b668479eacb996e26921d","8e7ae2518f5265f0ef09d561748098fde5a87ccd","bpf: Explicitly memset the bpf_attr structure For the bpf syscall, we are relying on the compiler to properly zero out the bpf_attr union that we copy userspace data into. Unfortunately that doesn't always work properly, padding and other oddities might not be correctly zeroed, and in some tests odd things have been found when the stack is pre-initialized to other values. Fix this by explicitly memsetting the structure to 0 before using it. Reported-by: Maciej Żenczykowski Reported-by: John Stultz Reported-by: Alexander Potapenko Reported-by: Alistair Delva Signed-off-by: Greg Kroah-Hartman Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://android-review.googlesource.com/c/kernel/common/+/1235490 Link: https://lore.kernel.org/bpf/20200320094813.GA421650@kroah.com","kernel/bpf/syscall.c | 3 ++-; 1 file changed, 2 insertions(+), 1 deletion(-)","The commit explicitly sets the bpf_attr structure to zero to avoid issues with uninitialized memory during bpf syscall handling.","bpf_attr, memset, syscall","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The syscall interface. It changes the system calls through which user-space programs interact with eBPF.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"c0fd336ea4ca82377fbb0954db09d765eb794339","c0fd336ea4ca82377fbb0954db09d765eb794339","YueHaibing","yuehaibing@huawei.com","1584671666","Daniel Borkmann","daniel@iogearbox.net","1584716215","22de800386bce70aa83175cdac9d81c0ed12f5ff","a26527981af2988ae0f17f6d633848c019929e38","bpf, tcp: Make tcp_bpf_recvmsg static After commit f747632b608f (""bpf: sockmap: Move generic sockmap hooks from BPF TCP""), tcp_bpf_recvmsg() is not used out of tcp_bpf.c, so make it static and remove it from tcp.h. Also move it to BPF_STREAM_PARSER #ifdef to fix unused function warnings. Fixes: f747632b608f (""bpf: sockmap: Move generic sockmap hooks from BPF TCP"") Signed-off-by: YueHaibing Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200320023426.60684-3-yuehaibing@huawei.com","include/net/tcp.h | 2 -; net/ipv4/tcp_bpf.c | 124 ++++++++++++++++++++++++++---------------------------; 2 files changed, 62 insertions(+), 64 deletions(-)","The commit makes the tcp_bpf_recvmsg function static for internal use, addressing unused function warnings.","static,function,warnings","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"a26527981af2988ae0f17f6d633848c019929e38","a26527981af2988ae0f17f6d633848c019929e38","YueHaibing","yuehaibing@huawei.com","1584671665","Daniel Borkmann","daniel@iogearbox.net","1584716185","10a827647d6e091d2091c075073bd1b71cd9cb1c","65c93628599dff4cd7cfb70130d1f6a2203731ea","bpf, tcp: Fix unused function warnings If BPF_STREAM_PARSER is not set, gcc warns: net/ipv4/tcp_bpf.c:483:12: warning: 'tcp_bpf_sendpage' defined but not used [-Wunused-function] net/ipv4/tcp_bpf.c:395:12: warning: 'tcp_bpf_sendmsg' defined but not used [-Wunused-function] net/ipv4/tcp_bpf.c:13:13: warning: 'tcp_bpf_stream_read' defined but not used [-Wunused-function] Moves the unused functions into the #ifdef CONFIG_BPF_STREAM_PARSER. Fixes: f747632b608f (""bpf: sockmap: Move generic sockmap hooks from BPF TCP"") Reported-by: Hulk Robot Signed-off-by: YueHaibing Signed-off-by: Daniel Borkmann Reviewed-by: Lorenz Bauer Reviewed-by: Jakub Sitnicki Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200320023426.60684-2-yuehaibing@huawei.com","net/ipv4/tcp_bpf.c | 28 ++++++++++++++--------------; 1 file changed, 14 insertions(+), 14 deletions(-)","The commit addresses unused function warnings by enclosing them in #ifdef CONFIG_BPF_STREAM_PARSER blocks.","unused,function,warnings","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.', ""It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here."", ""I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear.""]" +"65c93628599dff4cd7cfb70130d1f6a2203731ea","65c93628599dff4cd7cfb70130d1f6a2203731ea","Martin KaFai Lau","kafai@fb.com","1584551816","Daniel Borkmann","daniel@iogearbox.net","1584715895","a4c09c50c6e8a521a6ab3d329d0e55d8c09751a2","d5ae04da34a213cc518558ecd25af0f609428560","bpftool: Add struct_ops support This patch adds struct_ops support to the bpftool. To recap a bit on the recent bpf_struct_ops feature on the kernel side: It currently supports ""struct tcp_congestion_ops"" to be implemented in bpf. At a high level, bpf_struct_ops is struct_ops map populated with a number of bpf progs. bpf_struct_ops currently supports the ""struct tcp_congestion_ops"". However, the bpf_struct_ops design is generic enough that other kernel struct ops can be supported in the future. Although struct_ops is map+progs at a high lever, there are differences in details. For example, 1) After registering a struct_ops, the struct_ops is held by the kernel subsystem (e.g. tcp-cc). Thus, there is no need to pin a struct_ops map or its progs in order to keep them around. 2) To iterate all struct_ops in a system, it iterates all maps in type BPF_MAP_TYPE_STRUCT_OPS. BPF_MAP_TYPE_STRUCT_OPS is the current usual filter. In the future, it may need to filter by other struct_ops specific properties. e.g. filter by tcp_congestion_ops or other kernel subsystem ops in the future. 3) struct_ops requires the running kernel having BTF info. That allows more flexibility in handling other kernel structs. e.g. it can always dump the latest bpf_map_info. 4) Also, ""struct_ops"" command is not intended to repeat all features already provided by ""map"" or ""prog"". For example, if there really is a need to pin the struct_ops map, the user can use the ""map"" cmd to do that. While the first attempt was to reuse parts from map/prog.c, it ended up not a lot to share. The only obvious item is the map_parse_fds() but that still requires modifications to accommodate struct_ops map specific filtering (for the immediate and the future needs). Together with the earlier mentioned differences, it is better to part away from map/prog.c. The initial set of subcmds are, register, unregister, show, and dump. For register, it registers all struct_ops maps that can be found in an obj file. Option can be added in the future to specify a particular struct_ops map. Also, the common bpf_tcp_cc is stateless (e.g. bpf_cubic.c and bpf_dctcp.c). The ""reuse map"" feature is not implemented in this patch and it can be considered later also. For other subcmds, please see the man doc for details. A sample output of dump: [root@arch-fb-vm1 bpf]# bpftool struct_ops dump name cubic [{ ""bpf_map_info"": { ""type"": 26, ""id"": 64, ""key_size"": 4, ""value_size"": 256, ""max_entries"": 1, ""map_flags"": 0, ""name"": ""cubic"", ""ifindex"": 0, ""btf_vmlinux_value_type_id"": 18452, ""netns_dev"": 0, ""netns_ino"": 0, ""btf_id"": 52, ""btf_key_type_id"": 0, ""btf_value_type_id"": 0 } },{ ""bpf_struct_ops_tcp_congestion_ops"": { ""refcnt"": { ""refs"": { ""counter"": 1 } }, ""state"": ""BPF_STRUCT_OPS_STATE_INUSE"", ""data"": { ""list"": { ""next"": 0, ""prev"": 0 }, ""key"": 0, ""flags"": 0, ""init"": ""void (struct sock *) bictcp_init/prog_id:138"", ""release"": ""void (struct sock *) 0"", ""ssthresh"": ""u32 (struct sock *) bictcp_recalc_ssthresh/prog_id:141"", ""cong_avoid"": ""void (struct sock *, u32, u32) bictcp_cong_avoid/prog_id:140"", ""set_state"": ""void (struct sock *, u8) bictcp_state/prog_id:142"", ""cwnd_event"": ""void (struct sock *, enum tcp_ca_event) bictcp_cwnd_event/prog_id:139"", ""in_ack_event"": ""void (struct sock *, u32) 0"", ""undo_cwnd"": ""u32 (struct sock *) tcp_reno_undo_cwnd/prog_id:144"", ""pkts_acked"": ""void (struct sock *, const struct ack_sample *) bictcp_acked/prog_id:143"", ""min_tso_segs"": ""u32 (struct sock *) 0"", ""sndbuf_expand"": ""u32 (struct sock *) 0"", ""cong_control"": ""void (struct sock *, const struct rate_sample *) 0"", ""get_info"": ""size_t (struct sock *, u32, int *, union tcp_cc_info *) 0"", ""name"": ""bpf_cubic"", ""owner"": 0 } } } ] Signed-off-by: Martin KaFai Lau Signed-off-by: Daniel Borkmann Acked-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200318171656.129650-1-kafai@fb.com",".../bpftool/Documentation/bpftool-struct_ops.rst | 116 ++++; tools/bpf/bpftool/bash-completion/bpftool | 28 +; tools/bpf/bpftool/main.c | 3 +-; tools/bpf/bpftool/main.h | 1 +; tools/bpf/bpftool/struct_ops.c | 596 +++++++++++++++++++++; 5 files changed, 743 insertions(+), 1 deletion(-)","This commit adds support for struct_ops in bpftool, enhancing the ability to manage kernel struct operations like tcp_congestion_ops.","bpftool,struct_ops,tcp_congestion_ops","A new feature. It adds a new capability or feature that was not previously present.","Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems.']" +"d5ae04da34a213cc518558ecd25af0f609428560","d5ae04da34a213cc518558ecd25af0f609428560","Martin KaFai Lau","kafai@fb.com","1584551810","Daniel Borkmann","daniel@iogearbox.net","1584715895","7f9647bbdcef022552275ecb575a2e8b86004447","30255d317579e93ca3ecf7f4ab953094123e4a8c","bpftool: Translate prog_id to its bpf prog_name The kernel struct_ops obj has kernel's func ptrs implemented by bpf_progs. The bpf prog_id is stored as the value of the func ptr for introspection purpose. In the latter patch, a struct_ops dump subcmd will be added to introspect these func ptrs. It is desired to print the actual bpf prog_name instead of only printing the prog_id. Since struct_ops is the only usecase storing prog_id in the func ptr, this patch adds a prog_id_as_func_ptr bool (default is false) to ""struct btf_dumper"" in order not to mis-interpret the ptr value for the other existing use-cases. While printing a func_ptr as a bpf prog_name, this patch also prefix the bpf prog_name with the ptr's func_proto. [ Note that it is the ptr's func_proto instead of the bpf prog's func_proto ] It reuses the current btf_dump_func() to obtain the ptr's func_proto string. Here is an example from the bpf_cubic.c: ""void (struct sock *, u32, u32) bictcp_cong_avoid/prog_id:140"" Signed-off-by: Martin KaFai Lau Signed-off-by: Daniel Borkmann Acked-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200318171650.129252-1-kafai@fb.com","tools/bpf/bpftool/btf_dumper.c | 118 ++++++++++++++++++++++++++++++++++++-----; tools/bpf/bpftool/main.h | 1 +; 2 files changed, 107 insertions(+), 12 deletions(-)","This commit updates bpftool to translate BPF program IDs into program names for function pointers in kernel struct_ops introspection.","bpftool,prog_id,struct_ops","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems.']" +"30255d317579e93ca3ecf7f4ab953094123e4a8c","30255d317579e93ca3ecf7f4ab953094123e4a8c","Martin KaFai Lau","kafai@fb.com","1584551803","Daniel Borkmann","daniel@iogearbox.net","1584715895","1fbd68bd94c0fbd9b237b27e7d599245e44c3de7","ca7e6e45d108f5712aec4407e6c757af59d43d0f","bpftool: Print as a string for char array A char[] is currently printed as an integer array. This patch will print it as a string when 1) The array element type is an one byte int 2) The array element type has a BTF_INT_CHAR encoding or the array element type's name is ""char"" 3) All characters is between (0x1f, 0x7f) and it is terminated by a null character. Signed-off-by: Martin KaFai Lau Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Acked-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200318171643.129021-1-kafai@fb.com","tools/bpf/bpftool/btf_dumper.c | 41 +++++++++++++++++++++++++++++++++++++++++; 1 file changed, 41 insertions(+)","The patch modifies bpftool to print char arrays as strings instead of integer arrays.","bpftool,char,array","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"ca7e6e45d108f5712aec4407e6c757af59d43d0f","ca7e6e45d108f5712aec4407e6c757af59d43d0f","Martin KaFai Lau","kafai@fb.com","1584551797","Daniel Borkmann","daniel@iogearbox.net","1584715895","d5ec98e971734053d9b103ea38bdecf6b99f5bba","90ceddcb495008ac8ba7a3dce297841efcd7d584","bpftool: Print the enum's name instead of value This patch prints the enum's name if there is one found in the array of btf_enum. The commit 9eea98497951 (""bpf: fix BTF verification of enums"") has details about an enum could have any power-of-2 size (up to 8 bytes). This patch also takes this chance to accommodate these non 4 byte enums. Signed-off-by: Martin KaFai Lau Signed-off-by: Daniel Borkmann Acked-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200318171637.128862-1-kafai@fb.com","tools/bpf/bpftool/btf_dumper.c | 40 ++++++++++++++++++++++++++++++++++++----; 1 file changed, 36 insertions(+), 4 deletions(-)","The commit updates bpftool to print enum names rather than values and accommodates enums of various sizes.","bpftool,enum,BTF","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"90ceddcb495008ac8ba7a3dce297841efcd7d584","90ceddcb495008ac8ba7a3dce297841efcd7d584","Fangrui Song","maskray@google.com","1584570466","Daniel Borkmann","daniel@iogearbox.net","1584617558","16ba978c36201f3c8f02f4643243e5e6dc693c35","483d7a30f538e2f8addd32aa9a3d2e94ae55fa65","bpf: Support llvm-objcopy for vmlinux BTF Simplify gen_btf logic to make it work with llvm-objcopy. The existing 'file format' and 'architecture' parsing logic is brittle and does not work with llvm-objcopy/llvm-objdump. 'file format' output of llvm-objdump>=11 will match GNU objdump, but 'architecture' (bfdarch) may not. .BTF in .tmp_vmlinux.btf is non-SHF_ALLOC. Add the SHF_ALLOC flag because it is part of vmlinux image used for introspection. C code can reference the section via linker script defined __start_BTF and __stop_BTF. This fixes a small problem that previous .BTF had the SHF_WRITE flag (objcopy -I binary -O elf* synthesized .data). Additionally, `objcopy -I binary` synthesized symbols _binary__btf_vmlinux_bin_start and _binary__btf_vmlinux_bin_stop (not used elsewhere) are replaced with more commonplace __start_BTF and __stop_BTF. Add 2>/dev/null because GNU objcopy (but not llvm-objcopy) warns ""empty loadable segment detected at vaddr=0xffffffff81000000, is this intentional?"" We use a dd command to change the e_type field in the ELF header from ET_EXEC to ET_REL so that lld will accept .btf.vmlinux.bin.o. Accepting ET_EXEC as an input file is an extremely rare GNU ld feature that lld does not intend to support, because this is error-prone. The output section description .BTF in include/asm-generic/vmlinux.lds.h avoids potential subtle orphan section placement issues and suppresses --orphan-handling=warn warnings. Fixes: df786c9b9476 (""bpf: Force .BTF section start to zero when dumping from vmlinux"") Fixes: cb0cc635c7a9 (""powerpc: Include .BTF section"") Reported-by: Nathan Chancellor Signed-off-by: Fangrui Song Signed-off-by: Daniel Borkmann Tested-by: Stanislav Fomichev Tested-by: Andrii Nakryiko Reviewed-by: Stanislav Fomichev Reviewed-by: Kees Cook Acked-by: Andrii Nakryiko Acked-by: Michael Ellerman (powerpc) Link: https://github.com/ClangBuiltLinux/linux/issues/871 Link: https://lore.kernel.org/bpf/20200318222746.173648-1-maskray@google.com","arch/powerpc/kernel/vmlinux.lds.S | 6 ------; include/asm-generic/vmlinux.lds.h | 15 +++++++++++++++; kernel/bpf/btf.c | 9 ++++-----; kernel/bpf/sysfs_btf.c | 11 +++++------; scripts/link-vmlinux.sh | 24 ++++++++++--------------; 5 files changed, 34 insertions(+), 31 deletions(-)","This commit updates BTF generation for compatibility with llvm-objcopy by modifying section flags and ELF headers.","BTF, llvm-objcopy, ELF","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"8e7ae2518f5265f0ef09d561748098fde5a87ccd","8e7ae2518f5265f0ef09d561748098fde5a87ccd","Martin KaFai Lau","kafai@fb.com","1584147729","Daniel Borkmann","daniel@iogearbox.net","1584474019","4ca18ed93fa3e56a4c81ff6715d0a8b9d8b7afb9","32ca98feab8c9076c89c0697c5a85e46fece809d","bpf: Sanitize the bpf_struct_ops tcp-cc name The bpf_struct_ops tcp-cc name should be sanitized in order to avoid problematic chars (e.g. whitespaces). This patch reuses the bpf_obj_name_cpy() for accepting the same set of characters in order to keep a consistent bpf programming experience. A ""size"" param is added. Also, the strlen is returned on success so that the caller (like the bpf_tcp_ca here) can error out on empty name. The existing callers of the bpf_obj_name_cpy() only need to change the testing statement to ""if (err < 0)"". For all these existing callers, the err will be overwritten later, so no extra change is needed for the new strlen return value. v3: - reverse xmas tree style v2: - Save the orig_src to avoid ""end - size"" (Andrii) Fixes: 0baf26b0fcd7 (""bpf: tcp: Support tcp_congestion_ops in bpf"") Signed-off-by: Martin KaFai Lau Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200314010209.1131542-1-kafai@fb.com","include/linux/bpf.h | 1 +; kernel/bpf/syscall.c | 25 ++++++++++++++-----------; net/ipv4/bpf_tcp_ca.c | 7 ++-----; 3 files changed, 17 insertions(+), 16 deletions(-)","The commit sanitizes tcp congestion control names in bpf_struct_ops to prevent issues with invalid characters.","sanitize,tcp-cc,characters","A bug fix. It primarily resolves a bug or issue in the code.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"483d7a30f538e2f8addd32aa9a3d2e94ae55fa65","483d7a30f538e2f8addd32aa9a3d2e94ae55fa65","Wenbo Zhang","ethercflow@gmail.com","1584261172","Daniel Borkmann","daniel@iogearbox.net","1584470020","968d29ce16ea67806562979e2c5d2021e49ea28d","fd27b1835e7079d26809cd4d33ba98f84e593766","bpf, libbpf: Fix ___bpf_kretprobe_args1(x) macro definition Use PT_REGS_RC instead of PT_REGS_RET to get ret correctly. Fixes: df8ff35311c8 (""libbpf: Merge selftests' bpf_trace_helpers.h into libbpf's bpf_tracing.h"") Signed-off-by: Wenbo Zhang Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200315083252.22274-1-ethercflow@gmail.com","tools/lib/bpf/bpf_tracing.h | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","Fixed a macro definition in libbpf to correctly retrieve return values using PT_REGS_RC instead of PT_REGS_RET.","macro,libbpf,fix","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"fd27b1835e7079d26809cd4d33ba98f84e593766","fd27b1835e7079d26809cd4d33ba98f84e593766","Andrii Nakryiko","andriin@fb.com","1584149972","Daniel Borkmann","daniel@iogearbox.net","1584469873","fd8f222a6926caed7a675f7cd86bb98fa904188c","fc32490bff855a539d253c8a52c5a1ba51d1325a","selftests/bpf: Reset process and thread affinity after each test/sub-test Some tests and sub-tests are setting ""custom"" thread/process affinity and don't reset it back. Instead of requiring each test to undo all this, ensure that thread affinity is restored by test_progs test runner itself. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200314013932.4035712-3-andriin@fb.com","tools/testing/selftests/bpf/test_progs.c | 42 +++++++++++++++++++++++++++++++-; tools/testing/selftests/bpf/test_progs.h | 1 +; 2 files changed, 42 insertions(+), 1 deletion(-)","Reset process and thread affinity after each BPF selftest to ensure proper cleanup.","selftests, affinity, reset","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"fc32490bff855a539d253c8a52c5a1ba51d1325a","fc32490bff855a539d253c8a52c5a1ba51d1325a","Andrii Nakryiko","andriin@fb.com","1584149971","Daniel Borkmann","daniel@iogearbox.net","1584469846","5776c7a29cbec9405fbde8d5cba00412fce235e4","94c2f50b61258381abcd3a33fd5f2bc87e26df11","selftests/bpf: Fix test_progs's parsing of test numbers When specifying disjoint set of tests, test_progs doesn't set skipped test's array elements to false. This leads to spurious execution of tests that should have been skipped. Fix it by explicitly initializing them to false. Fixes: 3a516a0a3a7b (""selftests/bpf: add sub-tests support for test_progs"") Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200314013932.4035712-2-andriin@fb.com","tools/testing/selftests/bpf/test_progs.c | 13 +++++++------; 1 file changed, 7 insertions(+), 6 deletions(-)","Fixes incorrect execution of skipped tests in test_progs by ensuring skipped tests are properly initialized to false.","fix,test_progs,skipped","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"94c2f50b61258381abcd3a33fd5f2bc87e26df11","94c2f50b61258381abcd3a33fd5f2bc87e26df11","Andrii Nakryiko","andriin@fb.com","1584149970","Daniel Borkmann","daniel@iogearbox.net","1584469826","b3656959de1c71aef7b0092bbc7cc6a6022c464e","41078907eef0dd508d0999996d10683ae114c21a","selftests/bpf: Fix race in tcp_rtt test Previous attempt to make tcp_rtt more robust introduced a new race, in which server_done might be set to true before server can actually accept any connection. Fix this by unconditionally waiting for accept(). Given socket is non-blocking, if there are any problems with client side, it should eventually close listening FD and let server thread exit with failure. Fixes: 4cd729fa022c (""selftests/bpf: Make tcp_rtt test more robust to failures"") Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200314013932.4035712-1-andriin@fb.com","tools/testing/selftests/bpf/prog_tests/tcp_rtt.c | 4 ++--; 1 file changed, 2 insertions(+), 2 deletions(-)","Fixes a race condition in the tcp_rtt selftest by unconditionally waiting for accept().","race,tcp_rtt,selftests","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"41078907eef0dd508d0999996d10683ae114c21a","41078907eef0dd508d0999996d10683ae114c21a","Andrii Nakryiko","andriin@fb.com","1584145663","Daniel Borkmann","daniel@iogearbox.net","1584469752","4e8e634122a0f7092025f2942ff1c27f0118a4a6","cc9864a7aad9bc952d89f80dd0404a44ca591c2d","selftests/bpf: Fix nanosleep for real this time Amazingly, some libc implementations don't call __NR_nanosleep syscall from their nanosleep() APIs. Hammer it down with explicit syscall() call and never get back to it again. Also simplify code for timespec initialization. I verified that nanosleep is called w/ printk and in exactly same Linux image that is used in Travis CI. So it should both sleep and call correct syscall. v1->v2: - math is too hard, fix usec -> nsec convertion (Martin); - test_vmlinux has explicit nanosleep() call, convert that one as well. Fixes: 4e1fd25d19e8 (""selftests/bpf: Fix usleep() implementation"") Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200314002743.3782677-1-andriin@fb.com","tools/testing/selftests/bpf/prog_tests/vmlinux.c | 2 +-; tools/testing/selftests/bpf/test_progs.c | 16 ++++++----------; 2 files changed, 7 insertions(+), 11 deletions(-)","The commit fixes the nanosleep syscall implementation in BPF selftests to ensure consistent behavior across libc implementations.","nanosleep,selftests,fix","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"cc9864a7aad9bc952d89f80dd0404a44ca591c2d","cc9864a7aad9bc952d89f80dd0404a44ca591c2d","Andrii Nakryiko","andriin@fb.com","1584145114","Daniel Borkmann","daniel@iogearbox.net","1584469707","06caf596b160c376e4c4b2c065cf71b55ac8809c","86e85bf6981c0c265c427d6bfe9e2a0111797444","selftest/bpf: Fix compilation warning in sockmap_parse_prog.c Remove unused len variable, which causes compilation warnings. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200314001834.3727680-1-andriin@fb.com","tools/testing/selftests/bpf/progs/sockmap_parse_prog.c | 1 -; 1 file changed, 1 deletion(-)","Fixes a compilation warning by removing an unused variable in the selftest sockmap_parse_prog.c file.","compilation,warning,sockmap","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"13d0f7b814d9b4c67e60d8c2820c86ea181e7d99","13d0f7b814d9b4c67e60d8c2820c86ea181e7d99","Bruno Meneguele","bmeneg@redhat.com","1584054500","David S. Miller","davem@davemloft.net","1584244690","e675b7a0d660751e92a34c2d55c4bb4569ce87ce","0d1c3530e1bd38382edef72591b78e877e0edcd3","net/bpfilter: fix dprintf usage for /dev/kmsg The bpfilter UMH code was recently changed to log its informative messages to /dev/kmsg, however this interface doesn't support SEEK_CUR yet, used by dprintf(). As result dprintf() returns -EINVAL and doesn't log anything. However there already had some discussions about supporting SEEK_CUR into /dev/kmsg interface in the past it wasn't concluded. Since the only user of that from userspace perspective inside the kernel is the bpfilter UMH (userspace) module it's better to correct it here instead waiting a conclusion on the interface. Fixes: 36c4357c63f3 (""net: bpfilter: print umh messages to /dev/kmsg"") Signed-off-by: Bruno Meneguele Signed-off-by: David S. Miller ","net/bpfilter/main.c | 14 ++++++++------; 1 file changed, 8 insertions(+), 6 deletions(-)","This commit corrects the usage of dprintf in bpfilter UMH to properly log messages to /dev/kmsg.","bpfilter, UMH, kmsg","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.","It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.","[""It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here.""]" +"44ef976ab3c4ccd6c886714e5349caa53c477010","44ef976ab3c4ccd6c886714e5349caa53c477010","David S. Miller","davem@davemloft.net","1584157923","David S. Miller","davem@davemloft.net","1584157923","fad7059aad1e1ac040e59a2f4870400bc8e9e30a","48f5d5cb80b4e414cb97dd7dba43b0370bdee130 832165d225f71040a2c1fc2407752e462d00de1f","Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next Daniel Borkmann says: ==================== pull-request: bpf-next 2020-03-13 The following pull-request contains BPF updates for your *net-next* tree. We've added 86 non-merge commits during the last 12 day(s) which contain a total of 107 files changed, 5771 insertions(+), 1700 deletions(-). The main changes are: 1) Add modify_return attach type which allows to attach to a function via BPF trampoline and is run after the fentry and before the fexit programs and can pass a return code to the original caller, from KP Singh. 2) Generalize BPF's kallsyms handling and add BPF trampoline and dispatcher objects to be visible in /proc/kallsyms so they can be annotated in stack traces, from Jiri Olsa. 3) Extend BPF sockmap to allow for UDP next to existing TCP support in order in order to enable this for BPF based socket dispatch, from Lorenz Bauer. 4) Introduce a new bpftool 'prog profile' command which attaches to existing BPF programs via fentry and fexit hooks and reads out hardware counters during that period, from Song Liu. Example usage: bpftool prog profile id 337 duration 3 cycles instructions llc_misses 4228 run_cnt 3403698 cycles (84.08%) 3525294 instructions # 1.04 insn per cycle (84.05%) 13 llc_misses # 3.69 LLC misses per million isns (83.50%) 5) Batch of improvements to libbpf, bpftool and BPF selftests. Also addition of a new bpf_link abstraction to keep in particular BPF tracing programs attached even when the applicaion owning them exits, from Andrii Nakryiko. 6) New bpf_get_current_pid_tgid() helper for tracing to perform PID filtering and which returns the PID as seen by the init namespace, from Carlos Neira. 7) Refactor of RISC-V JIT code to move out common pieces and addition of a new RV32G BPF JIT compiler, from Luke Nelson. 8) Add gso_size context member to __sk_buff in order to be able to know whether a given skb is GSO or not, from Willem de Bruijn. 9) Add a new bpf_xdp_output() helper which reuses XDP's existing perf RB output implementation but can be called from tracepoint programs, from Eelco Chaudron. ==================== Signed-off-by: David S. Miller ","","This commit merges multiple eBPF enhancements from the bpf-next branch into net-next.","merge,eBPF,enhancements","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"832165d225f71040a2c1fc2407752e462d00de1f","832165d225f71040a2c1fc2407752e462d00de1f","Daniel Borkmann","daniel@iogearbox.net","1584138653","Daniel Borkmann","daniel@iogearbox.net","1584138674","46e7397710281de9f743512c43d65bc279ab4a51","30b4cb36b11144e29b4f837057f8ab31aac10b8a acbd06206bbbe59ffd2415c0b902dd244910e42e","Merge branch 'bpf-core-fixes' Andrii Nakryiko says: ==================== This patch set fixes bug in CO-RE relocation candidate finding logic, which currently allows matching against forward declarations, functions, and other named types, even though it makes no sense to even attempt. As part of verifying the fix, add test using vmlinux.h with preserve_access_index attribute and utilizing struct pt_regs heavily to trace nanosleep syscall using 5 different types of tracing BPF programs. This test also demonstrated problems using struct pt_regs in syscall tracepoints and required a new set of macro, which were added in patch #3 into bpf_tracing.h. Patch #1 fixes annoying issue with selftest failure messages being out of sync. v1->v2: - drop unused handle__probed() function (Martin). ==================== Signed-off-by: Daniel Borkmann ","","A merge commit fixing bugs in CO-RE relocation logic adding tests and new macros for BPF tracing.","CO-RE,tracing,relocation","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.', 'kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.', ""I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear.""]" +"acbd06206bbbe59ffd2415c0b902dd244910e42e","acbd06206bbbe59ffd2415c0b902dd244910e42e","Andrii Nakryiko","andriin@fb.com","1584120216","Daniel Borkmann","daniel@iogearbox.net","1584138653","46e7397710281de9f743512c43d65bc279ab4a51","b8ebce86ffe655ac15a841bba2d645105ffe3d38","selftests/bpf: Add vmlinux.h selftest exercising tracing of syscalls Add vmlinux.h generation to selftest/bpf's Makefile. Use it from newly added test_vmlinux to trace nanosleep syscall using 5 different types of programs: - tracepoint; - raw tracepoint; - raw tracepoint w/ direct memory reads (tp_btf); - kprobe; - fentry. These programs are realistic variants of real-life tracing programs, excercising vmlinux.h's usage with tracing applications. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200313172336.1879637-5-andriin@fb.com","tools/testing/selftests/bpf/Makefile | 7 +-; tools/testing/selftests/bpf/prog_tests/vmlinux.c | 43 ++++++++++++; tools/testing/selftests/bpf/progs/test_vmlinux.c | 84 ++++++++++++++++++++++++; 3 files changed, 133 insertions(+), 1 deletion(-)","Add a selftest for tracing syscalls using vmlinux.h with various eBPF program types.","selftests,vmlinux,tracing","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.', 'kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"b8ebce86ffe655ac15a841bba2d645105ffe3d38","b8ebce86ffe655ac15a841bba2d645105ffe3d38","Andrii Nakryiko","andriin@fb.com","1584120215","Daniel Borkmann","daniel@iogearbox.net","1584138653","342c3e6a8f11df30291dafd552e2427846c67971","d121e1d34b72c4975ff0340901d926c0aaf98174","libbpf: Provide CO-RE variants of PT_REGS macros Syscall raw tracepoints have struct pt_regs pointer as tracepoint's first argument. After that, reading any of pt_regs fields requires bpf_probe_read(), even for tp_btf programs. Due to that, PT_REGS_PARMx macros are not usable as is. This patch adds CO-RE variants of those macros that use BPF_CORE_READ() to read necessary fields. This provides relocatable architecture-agnostic pt_regs field accesses. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200313172336.1879637-4-andriin@fb.com","tools/lib/bpf/bpf_tracing.h | 103 ++++++++++++++++++++++++++++++++++++++++++++; 1 file changed, 103 insertions(+)","This commit introduces CO-RE variants of PT_REGS macros in libbpf for relocatable architecture-agnostic field access in syscall raw tracepoints.","CO-RE, PT_REGS, libbpf","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"d121e1d34b72c4975ff0340901d926c0aaf98174","d121e1d34b72c4975ff0340901d926c0aaf98174","Andrii Nakryiko","andriin@fb.com","1584120214","Daniel Borkmann","daniel@iogearbox.net","1584138653","cd25234c8e4096105993a9b4432d1f13ca59c044","3e2671fb9a95d2b46990832466383ec8384d88a3","libbpf: Ignore incompatible types with matching name during CO-RE relocation When finding target type candidates, ignore forward declarations, functions, and other named types of incompatible kind. Not doing this can cause false errors. See [0] for one such case (due to struct pt_regs forward declaration). [0] https://github.com/iovisor/bcc/pull/2806#issuecomment-598543645 Fixes: ddc7c3042614 (""libbpf: implement BPF CO-RE offset relocation algorithm"") Reported-by: Wenbo Zhang Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200313172336.1879637-3-andriin@fb.com","tools/lib/bpf/libbpf.c | 4 ++++; 1 file changed, 4 insertions(+)","The commit addresses false errors in CO-RE relocation by skipping incompatible type candidates in libbpf.","libbpf, CO-RE, types","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"3e2671fb9a95d2b46990832466383ec8384d88a3","3e2671fb9a95d2b46990832466383ec8384d88a3","Andrii Nakryiko","andriin@fb.com","1584120213","Daniel Borkmann","daniel@iogearbox.net","1584138653","b71e83c60faef2de1a4704f4e10bad681227c461","30b4cb36b11144e29b4f837057f8ab31aac10b8a","selftests/bpf: Ensure consistent test failure output printf() doesn't seem to honor using overwritten stdout/stderr (as part of stdio hijacking), so ensure all ""standard"" invocations of printf() do fprintf(stdout, ...) instead. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200313172336.1879637-2-andriin@fb.com","tools/testing/selftests/bpf/test_progs.c | 10 +++++-----; tools/testing/selftests/bpf/test_progs.h | 8 ++++----; 2 files changed, 9 insertions(+), 9 deletions(-)","The commit modifies test outputs in the bpf selftests to ensure consistent failure messages by using fprintf instead of printf.","selftests bpf fprintf","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"30b4cb36b11144e29b4f837057f8ab31aac10b8a","30b4cb36b11144e29b4f837057f8ab31aac10b8a","Jakub Sitnicki","jakub@cloudflare.com","1584115849","Daniel Borkmann","daniel@iogearbox.net","1584131826","0456ef00c35942b251b0780373ff2277109d6b21","bcd66b10b5e956b3e81f76a61abfed2501ff4038","selftests/bpf: Fix spurious failures in accept due to EAGAIN Andrii Nakryiko reports that sockmap_listen test suite is frequently failing due to accept() calls erroring out with EAGAIN: ./test_progs:connect_accept_thread:733: accept: Resource temporarily unavailable connect_accept_thread:FAIL:733 This is because we are using a non-blocking listening TCP socket to accept() connections without polling on the socket. While at first switching to blocking mode seems like the right thing to do, this could lead to test process blocking indefinitely in face of a network issue, like loopback interface being down, as Andrii pointed out. Hence, stick to non-blocking mode for TCP listening sockets but with polling for incoming connection for a limited time before giving up. Apply this approach to all socket I/O calls in the test suite that we expect to block indefinitely, that is accept() for TCP and recv() for UDP. Fixes: 44d28be2b8d4 (""selftests/bpf: Tests for sockmap/sockhash holding listening sockets"") Reported-by: Andrii Nakryiko Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200313161049.677700-1-jakub@cloudflare.com",".../selftests/bpf/prog_tests/sockmap_listen.c | 77 ++++++++++++++++------; 1 file changed, 58 insertions(+), 19 deletions(-)","This commit fixes spurious failures in sockmap_listen selftest by using polling for non-blocking TCP sockets to handle EAGAIN errors.","selftests,bpf,EAGAIN","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"bcd66b10b5e956b3e81f76a61abfed2501ff4038","bcd66b10b5e956b3e81f76a61abfed2501ff4038","Tobias Klauser","tklauser@distanz.ch","1584099065","Daniel Borkmann","daniel@iogearbox.net","1584129394","a6a91557c5486f547cdc8cf2c747ba1388c1dc15","dcce11d545cc5d04c3fb529a8e2a0da987389139","tools/bpf: Move linux/types.h for selftests and bpftool Commit fe4eb069edb7 (""bpftool: Use linux/types.h from source tree for profiler build"") added a build dependency on tools/testing/selftests/bpf to tools/bpf/bpftool. This is suboptimal with respect to a possible stand-alone build of bpftool. Fix this by moving tools/testing/selftests/bpf/include/uapi/linux/types.h to tools/include/uapi/linux/types.h. This requires an adjustment in the include search path order for the tests in tools/testing/selftests/bpf so that tools/include/linux/types.h is selected when building host binaries and tools/include/uapi/linux/types.h is selected when building bpf binaries. Verified by compiling bpftool and the bpf selftests on x86_64 with this change. Fixes: fe4eb069edb7 (""bpftool: Use linux/types.h from source tree for profiler build"") Suggested-by: Andrii Nakryiko Signed-off-by: Tobias Klauser Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200313113105.6918-1-tklauser@distanz.ch","tools/bpf/bpftool/Makefile | 1 -; tools/include/uapi/linux/types.h | 23 ++++++++++++++++++++++; tools/testing/selftests/bpf/Makefile | 7 ++++---; .../selftests/bpf/include/uapi/linux/types.h | 23 ----------------------; 4 files changed, 27 insertions(+), 27 deletions(-)","This commit relocates linux/types.h to improve standalone builds of bpftool and adjusts include paths for bpftool and selftests.","bpftool,selftests,types.h","A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"dcce11d545cc5d04c3fb529a8e2a0da987389139","dcce11d545cc5d04c3fb529a8e2a0da987389139","Jules Irenge","jbi.octave@gmail.com","1583888941","Daniel Borkmann","daniel@iogearbox.net","1584129307","d235ecfa4fa2b74ecdb43d8371d8fac296ec804a","5996a587a466fa469531272139d23a3b56e07e5c","bpf: Add missing annotations for __bpf_prog_enter() and __bpf_prog_exit() Sparse reports a warning at __bpf_prog_enter() and __bpf_prog_exit() warning: context imbalance in __bpf_prog_enter() - wrong count at exit warning: context imbalance in __bpf_prog_exit() - unexpected unlock The root cause is the missing annotation at __bpf_prog_enter() and __bpf_prog_exit() Add the missing __acquires(RCU) annotation Add the missing __releases(RCU) annotation Signed-off-by: Jules Irenge Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200311010908.42366-2-jbi.octave@gmail.com","kernel/bpf/trampoline.c | 2 ++; 1 file changed, 2 insertions(+)","The commit adds missing RCU annotations to __bpf_prog_enter() and __bpf_prog_exit() to fix sparse warnings related to context imbalance.","annotations,RCU,imbalances","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"5996a587a466fa469531272139d23a3b56e07e5c","5996a587a466fa469531272139d23a3b56e07e5c","Carlos Neira","cneirabustos@gmail.com","1584114410","Daniel Borkmann","daniel@iogearbox.net","1584129220","ce9491a9f8d62cc6df1fbd713eff34ee7a31bce4","4e1fd25d19e83774e41008c1ca35c6c27eb30270","bpf_helpers_doc.py: Fix warning when compiling bpftool When compiling bpftool the following warning is found: ""declaration of 'struct bpf_pidns_info' will not be visible outside of this function."" This patch adds struct bpf_pidns_info to type_fwds array to fix this. Fixes: b4490c5c4e02 (""bpf: Added new helper bpf_get_ns_current_pid_tgid"") Signed-off-by: Carlos Neira Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200313154650.13366-1-cneirabustos@gmail.com","scripts/bpf_helpers_doc.py | 1 +; 1 file changed, 1 insertion(+)","The commit resolves a compilation warning by adding a forward declaration for struct 'bpf_pidns_info' in bpf_helpers_doc.py.","warning,bpftool,struct","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"4e1fd25d19e83774e41008c1ca35c6c27eb30270","4e1fd25d19e83774e41008c1ca35c6c27eb30270","Andrii Nakryiko","andriin@fb.com","1584080317","Alexei Starovoitov","ast@kernel.org","1584128992","707021a3a1bf50ca0896c5170aa937cda10933fe","1afbcd9466f2fd979dde57ad424524a2fc5572e3","selftests/bpf: Fix usleep() implementation nanosleep syscall expects pointer to struct timespec, not nanoseconds directly. Current implementation fulfills its purpose of invoking nanosleep syscall, but doesn't really provide sleeping capabilities, which can cause flakiness for tests relying on usleep() to wait for something. Fixes: ec12a57b822c (""selftests/bpf: Guarantee that useep() calls nanosleep() syscall"") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200313061837.3685572-1-andriin@fb.com Signed-off-by: Alexei Starovoitov ","tools/testing/selftests/bpf/test_progs.c | 11 ++++++++++-; 1 file changed, 10 insertions(+), 1 deletion(-)","The commit fixes the usleep() functionality in BPF selftests by correctly utilizing nanosleep syscall with a struct timespec.","selftests,usleep,nanosleep","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"1afbcd9466f2fd979dde57ad424524a2fc5572e3","1afbcd9466f2fd979dde57ad424524a2fc5572e3","Alexei Starovoitov","ast@kernel.org","1584066192","Alexei Starovoitov","ast@kernel.org","1584128992","b693861f42cde02243deb69d151fa80fcee09364","98868668367b24487c0b0b3298d7ca98409baf07 7ac88eba185b4d0e06a71678e54bc092edcd3af3","Merge branch 'generalize-bpf-ksym' Jiri Olsa says: ==================== this patchset adds trampoline and dispatcher objects to be visible in /proc/kallsyms. $ sudo cat /proc/kallsyms | tail -20 ... ffffffffa050f000 t bpf_prog_5a2b06eab81b8f51 [bpf] ffffffffa0511000 t bpf_prog_6deef7357e7b4530 [bpf] ffffffffa0542000 t bpf_trampoline_13832 [bpf] ffffffffa0548000 t bpf_prog_96f1b5bf4e4cc6dc_mutex_lock [bpf] ffffffffa0572000 t bpf_prog_d1c63e29ad82c4ab_bpf_prog1 [bpf] ffffffffa0585000 t bpf_prog_e314084d332a5338__dissect [bpf] ffffffffa0587000 t bpf_prog_59785a79eac7e5d2_mutex_unlock [bpf] ffffffffa0589000 t bpf_prog_d0db6e0cac050163_mutex_lock [bpf] ffffffffa058d000 t bpf_prog_d8f047721e4d8321_bpf_prog2 [bpf] ffffffffa05df000 t bpf_trampoline_25637 [bpf] ffffffffa05e3000 t bpf_prog_d8f047721e4d8321_bpf_prog2 [bpf] ffffffffa05e5000 t bpf_prog_3b185187f1855c4c [bpf] ffffffffa05e7000 t bpf_prog_d8f047721e4d8321_bpf_prog2 [bpf] ffffffffa05eb000 t bpf_prog_93cebb259dd5c4b2_do_sys_open [bpf] ffffffffa0677000 t bpf_dispatcher_xdp [bpf] v5 changes: - keeping just 1 bpf_tree for all the objects and adding flag to recognize bpf_objects when searching for exception tables [Alexei] - no need for is_bpf_image_address call in kernel_text_address [Alexei] - removed the bpf_image tree, because it's no longer needed v4 changes: - add trampoline and dispatcher to kallsyms once the it's allocated [Alexei] - omit the symbols sorting for kallsyms [Alexei] - small title change in one patch [Song] - some function renames: bpf_get_prog_name to bpf_prog_ksym_set_name bpf_get_prog_addr_region to bpf_prog_ksym_set_addr - added acks to changelogs - I checked and there'll be conflict on perftool side with upcoming changes from Adrian Hunter (text poke events), so I think it's better if Arnaldo takes the perf changes via perf tree and we will solve all conflicts there v3 changes: - use container_of directly in bpf_get_ksym_start [Daniel] - add more changelog explanations for ksym addresses [Daniel] v2 changes: - omit extra condition in __bpf_ksym_add for sorting code (Andrii) - rename bpf_kallsyms_tree_ops to bpf_ksym_tree (Andrii) - expose only executable code in kallsyms (Andrii) - use full trampoline key as its kallsyms id (Andrii) - explained the BPF_TRAMP_REPLACE case (Andrii) - small format changes in bpf_trampoline_link_prog/bpf_trampoline_unlink_prog (Andrii) - propagate error value in bpf_dispatcher_update and update kallsym if it's successful (Andrii) - get rid of __always_inline for bpf_ksym_tree callbacks (Andrii) - added KSYMBOL notification for bpf_image add/removal - added perf tools changes to properly display trampoline/dispatcher ==================== Signed-off-by: Alexei Starovoitov ","","The commit merges bpf-ksym generalization by including trampoline and dispatcher objects in /proc/kallsyms.","trampoline,dispatcher,kallsyms","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"7ac88eba185b4d0e06a71678e54bc092edcd3af3","7ac88eba185b4d0e06a71678e54bc092edcd3af3","Jiri Olsa","jolsa@kernel.org","1584042967","Alexei Starovoitov","ast@kernel.org","1584128992","b693861f42cde02243deb69d151fa80fcee09364","517b75e44c7be9c776aa5f7beaa85baff3868f80","bpf: Remove bpf_image tree Now that we have all the objects (bpf_prog, bpf_trampoline, bpf_dispatcher) linked in bpf_tree, there's no need to have separate bpf_image tree for images. Reverting the bpf_image tree together with struct bpf_image, because it's no longer needed. Also removing bpf_image_alloc function and adding the original bpf_jit_alloc_exec_page interface instead. The kernel_text_address function can now rely only on is_bpf_text_address, because it checks the bpf_tree that contains all the objects. Keeping bpf_image_ksym_add and bpf_image_ksym_del because they are useful wrappers with perf's ksymbol interface calls. Signed-off-by: Jiri Olsa Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200312195610.346362-13-jolsa@kernel.org Signed-off-by: Alexei Starovoitov ","include/linux/bpf.h | 8 +----; kernel/bpf/dispatcher.c | 4 +--; kernel/bpf/trampoline.c | 83 ++++++-------------------------------------------; kernel/extable.c | 2 --; 4 files changed, 13 insertions(+), 84 deletions(-)","The commit removes the bpf_image tree, streamlining bpf_tree usage for eBPF object management.","bpf_image,remove,bpf_tree","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"517b75e44c7be9c776aa5f7beaa85baff3868f80","517b75e44c7be9c776aa5f7beaa85baff3868f80","Jiri Olsa","jolsa@kernel.org","1584042966","Alexei Starovoitov","ast@kernel.org","1584128992","8f828afe30f143a9467428a04f77d751f6dcb60f","a108f7dcfa010e3da825af90d77ac0a6a0240992","bpf: Add dispatchers to kallsyms Adding dispatchers to kallsyms. It's displayed as bpf_dispatcher_ where NAME is the name of dispatcher. Signed-off-by: Jiri Olsa Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200312195610.346362-12-jolsa@kernel.org Signed-off-by: Alexei Starovoitov ","include/linux/bpf.h | 19 ++++++++++++-------; kernel/bpf/dispatcher.c | 1 +; 2 files changed, 13 insertions(+), 7 deletions(-)","This commit adds bpf dispatchers to kallsyms for improved visibility and symbol resolution.","bpf,kallsyms,dispatchers","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.']" +"a108f7dcfa010e3da825af90d77ac0a6a0240992","a108f7dcfa010e3da825af90d77ac0a6a0240992","Jiri Olsa","jolsa@kernel.org","1584042965","Alexei Starovoitov","ast@kernel.org","1584128992","620c483c6d3e73da1b2d46ff3cd2d4fd3bfe26aa","dba122fb5e122e8e07e2f11cdebc10ba4f425cf7","bpf: Add trampolines to kallsyms Adding trampolines to kallsyms. It's displayed as bpf_trampoline_ [bpf] where ID is the BTF id of the trampoline function. Adding bpf_image_ksym_add/del functions that setup the start/end values and call KSYMBOL perf events handlers. Signed-off-by: Jiri Olsa Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200312195610.346362-11-jolsa@kernel.org Signed-off-by: Alexei Starovoitov ","include/linux/bpf.h | 3 +++; kernel/bpf/trampoline.c | 28 ++++++++++++++++++++++++++++; 2 files changed, 31 insertions(+)","Added trampolines to kallsyms with identification via bpf_trampoline_ and integrated KSYMBOL perf events handling.","trampolines,kallsyms,perf","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"dba122fb5e122e8e07e2f11cdebc10ba4f425cf7","dba122fb5e122e8e07e2f11cdebc10ba4f425cf7","Jiri Olsa","jolsa@kernel.org","1584042964","Alexei Starovoitov","ast@kernel.org","1584128992","b7a60bb5ec25a3454df7b3ce43a5fa5e2e060a74","cbd76f8d5ac9c4e99c4ffe5e39a1e907cdf5a76f","bpf: Add bpf_ksym_add/del functions Separating /proc/kallsyms add/del code and adding bpf_ksym_add/del functions for that. Moving bpf_prog_ksym_node_add/del functions to __bpf_ksym_add/del and changing their argument to 'struct bpf_ksym' object. This way we can call them for other bpf objects types like trampoline and dispatcher. Signed-off-by: Jiri Olsa Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200312195610.346362-10-jolsa@kernel.org Signed-off-by: Alexei Starovoitov ","include/linux/bpf.h | 3 +++; kernel/bpf/core.c | 33 +++++++++++++++++++--------------; 2 files changed, 22 insertions(+), 14 deletions(-)","This commit introduces bpf_ksym_add/del functions for better management of eBPF kernel symbols.","bpf,ksym,management","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"cbd76f8d5ac9c4e99c4ffe5e39a1e907cdf5a76f","cbd76f8d5ac9c4e99c4ffe5e39a1e907cdf5a76f","Jiri Olsa","jolsa@kernel.org","1584042963","Alexei Starovoitov","ast@kernel.org","1584128992","fc4bb2d1cf96c608c2c200e54766d4dc202cb496","eda0c92902b57bbde674c27882554b074e9180a6","bpf: Add prog flag to struct bpf_ksym object Adding 'prog' bool flag to 'struct bpf_ksym' to mark that this object belongs to bpf_prog object. This change allows having bpf_prog objects together with other types (trampolines and dispatchers) in the single bpf_tree. It's used when searching for bpf_prog exception tables by the bpf_prog_ksym_find function, where we need to get the bpf_prog pointer. >From now we can safely add bpf_ksym support for trampoline or dispatcher objects, because we can differentiate them from bpf_prog objects. Signed-off-by: Jiri Olsa Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200312195610.346362-9-jolsa@kernel.org Signed-off-by: Alexei Starovoitov ","include/linux/bpf.h | 1 +; kernel/bpf/core.c | 22 +++++++++++-----------; 2 files changed, 12 insertions(+), 11 deletions(-)","This commit adds a 'prog' flag to the struct bpf_ksym to differentiate bpf_prog objects from other types.","prog, bpf_ksym, flag","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"98868668367b24487c0b0b3298d7ca98409baf07","98868668367b24487c0b0b3298d7ca98409baf07","Andrii Nakryiko","andriin@fb.com","1584058888","Alexei Starovoitov","ast@kernel.org","1584128991","fd21f9944906d4f3475021869688cbfe25a18db9","4cd729fa022cb5142e5b65f25589af61c8148cf6","bpf: Abstract away entire bpf_link clean up procedure Instead of requiring users to do three steps for cleaning up bpf_link, its anon_inode file, and unused fd, abstract that away into bpf_link_cleanup() helper. bpf_link_defunct() is removed, as it shouldn't be needed as an individual operation anymore. v1->v2: - keep bpf_link_cleanup() static for now (Daniel). Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200313002128.2028680-1-andriin@fb.com Signed-off-by: Alexei Starovoitov ","include/linux/bpf.h | 1 -; kernel/bpf/syscall.c | 18 +++++++++++-------; 2 files changed, 11 insertions(+), 8 deletions(-)","The commit introduces a helper function to simplify the cleanup process for bpf_link in the eBPF subsystem.","bpf_link, cleanup, abstract","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The syscall interface. It changes the system calls through which user-space programs interact with eBPF.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"eda0c92902b57bbde674c27882554b074e9180a6","eda0c92902b57bbde674c27882554b074e9180a6","Jiri Olsa","jolsa@kernel.org","1584042962","Alexei Starovoitov","ast@kernel.org","1584128991","5a8d436dc0a859bb4faf33360b5ed49ad6d01cc0","ca4424c920f574b7246ff1b6d83cfdfd709e42c8","bpf: Add bpf_ksym_find function Adding bpf_ksym_find function that is used bpf bpf address lookup functions: __bpf_address_lookup is_bpf_text_address while keeping bpf_prog_kallsyms_find to be used only for lookup of bpf_prog objects (will happen in following changes). Signed-off-by: Jiri Olsa Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200312195610.346362-8-jolsa@kernel.org Signed-off-by: Alexei Starovoitov ","kernel/bpf/core.c | 22 +++++++++++++++-------; 1 file changed, 15 insertions(+), 7 deletions(-)","The commit introduces bpf_ksym_find to facilitate BPF address lookup and adjusts bpf/core.c accordingly.","bpf, ksym, lookup","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"4cd729fa022cb5142e5b65f25589af61c8148cf6","4cd729fa022cb5142e5b65f25589af61c8148cf6","Andrii Nakryiko","andriin@fb.com","1583965669","Alexei Starovoitov","ast@kernel.org","1584128991","5759fc33f51ed252abef521733f9e4b67fb2d560","2b5cf9fb74848fe5742a56e872e6847b79933c0b","selftests/bpf: Make tcp_rtt test more robust to failures Switch to non-blocking accept and wait for server thread to exit before proceeding. I noticed that sometimes tcp_rtt server thread failure would ""spill over"" into other tests (that would run after tcp_rtt), probably just because server thread exits much later and tcp_rtt doesn't wait for it. v1->v2: - add usleep() while waiting on initial non-blocking accept() (Stanislav); Fixes: 8a03222f508b (""selftests/bpf: test_progs: fix client/server race in tcp_rtt"") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Reviewed-by: Stanislav Fomichev Link: https://lore.kernel.org/bpf/20200311222749.458015-1-andriin@fb.com Signed-off-by: Alexei Starovoitov ","tools/testing/selftests/bpf/prog_tests/tcp_rtt.c | 32 +++++++++++++++---------; 1 file changed, 20 insertions(+), 12 deletions(-)","Improve robustness of the BPF tcp_rtt selftest by using non-blocking accept and ensuring server thread exits properly.","tcp_rtt non-blocking robustness","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"ca4424c920f574b7246ff1b6d83cfdfd709e42c8","ca4424c920f574b7246ff1b6d83cfdfd709e42c8","Jiri Olsa","jolsa@kernel.org","1584042961","Alexei Starovoitov","ast@kernel.org","1584128991","1fb56b4a04f00eeadb71455bbec75fa752051263","ecb60d1c670e9b205197d8e4381b19e77bc2d834","bpf: Move ksym_tnode to bpf_ksym Moving ksym_tnode list node to 'struct bpf_ksym' object, so the symbol itself can be chained and used in other objects like bpf_trampoline and bpf_dispatcher. We need bpf_ksym object to be linked both in bpf_kallsyms via lnode for /proc/kallsyms and in bpf_tree via tnode for bpf address lookup functions like __bpf_address_lookup or bpf_prog_kallsyms_find. Signed-off-by: Jiri Olsa Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200312195610.346362-7-jolsa@kernel.org Signed-off-by: Alexei Starovoitov ","include/linux/bpf.h | 2 +-; kernel/bpf/core.c | 24 ++++++++++--------------; 2 files changed, 11 insertions(+), 15 deletions(-)","The commit integrates ksym_tnode into bpf_ksym for improved symbol chaining across various eBPF components.","ksym_tnode,bpf_ksym,bpf_trampoline","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"2b5cf9fb74848fe5742a56e872e6847b79933c0b","2b5cf9fb74848fe5742a56e872e6847b79933c0b","Andrii Nakryiko","andriin@fb.com","1583952825","Alexei Starovoitov","ast@kernel.org","1584128991","dacdbf2b57b6865afe3f14591fe5c8b7d6f7ae42","6ae32b29c09ba9b99c4c7317eed029587bd2706d","selftests/bpf: Guarantee that useep() calls nanosleep() syscall Some implementations of C runtime library won't call nanosleep() syscall from usleep(). But a bunch of kprobe/tracepoint selftests rely on nanosleep being called to trigger them. To make this more reliable, ""override"" usleep implementation and call nanosleep explicitly. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Cc: Julia Kartseva Link: https://lore.kernel.org/bpf/20200311185345.3874602-1-andriin@fb.com Signed-off-by: Alexei Starovoitov ","tools/testing/selftests/bpf/test_progs.c | 9 +++++++++; 1 file changed, 9 insertions(+)","The commit ensures nanosleep syscall is explicitly called for kprobe/tracepoint selftests by overriding usleep implementation.","nanosleep,kprobe,usleep","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.']" +"ecb60d1c670e9b205197d8e4381b19e77bc2d834","ecb60d1c670e9b205197d8e4381b19e77bc2d834","Jiri Olsa","jolsa@kernel.org","1584042960","Alexei Starovoitov","ast@kernel.org","1584128991","c83a00f79f1bd24471b40698794bcab83a4f49af","bfea9a8574f34597581f74f792d044d38497b775","bpf: Move lnode list node to struct bpf_ksym Adding lnode list node to 'struct bpf_ksym' object, so the struct bpf_ksym itself can be chained and used in other objects like bpf_trampoline and bpf_dispatcher. Changing iterator to bpf_ksym in bpf_get_kallsym function. The ksym->start is holding the prog->bpf_func value, so it's ok to use it as value in bpf_get_kallsym. Signed-off-by: Jiri Olsa Signed-off-by: Alexei Starovoitov Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200312195610.346362-6-jolsa@kernel.org Signed-off-by: Alexei Starovoitov ","include/linux/bpf.h | 2 +-; kernel/bpf/core.c | 22 +++++++++++-----------; 2 files changed, 12 insertions(+), 12 deletions(-)","This commit adds the lnode list node to struct bpf_ksym for use in bpf_trampoline and bpf_dispatcher.","lnode,bpf_ksym,struct","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"6ae32b29c09ba9b99c4c7317eed029587bd2706d","6ae32b29c09ba9b99c4c7317eed029587bd2706d","Quentin Monnet","quentin@isovalent.com","1583892725","Alexei Starovoitov","ast@kernel.org","1584128991","416d031bf3a6a30aa91782505b8716b2aae55fb0","d831ee84bfc9173eecf30dbbc2553ae81b996c60","tools: bpftool: Restore message on failure to guess program type In commit 4a3d6c6a6e4d (""libbpf: Reduce log level for custom section names""), log level for messages for libbpf_attach_type_by_name() and libbpf_prog_type_by_name() was downgraded from ""info"" to ""debug"". The latter function, in particular, is used by bpftool when attempting to load programs, and this change caused bpftool to exit with no hint or error message when it fails to detect the type of the program to load (unless ""-d"" option was provided). To help users understand why bpftool fails to load the program, let's do a second run of the function with log level in ""debug"" mode in case of failure. Before: # bpftool prog load sample_ret0.o /sys/fs/bpf/sample_ret0 # echo $? 255 Or really verbose with -d flag: # bpftool -d prog load sample_ret0.o /sys/fs/bpf/sample_ret0 libbpf: loading sample_ret0.o libbpf: section(1) .strtab, size 134, link 0, flags 0, type=3 libbpf: skip section(1) .strtab libbpf: section(2) .text, size 16, link 0, flags 6, type=1 libbpf: found program .text libbpf: section(3) .debug_abbrev, size 55, link 0, flags 0, type=1 libbpf: skip section(3) .debug_abbrev libbpf: section(4) .debug_info, size 75, link 0, flags 0, type=1 libbpf: skip section(4) .debug_info libbpf: section(5) .rel.debug_info, size 32, link 14, flags 0, type=9 libbpf: skip relo .rel.debug_info(5) for section(4) libbpf: section(6) .debug_str, size 150, link 0, flags 30, type=1 libbpf: skip section(6) .debug_str libbpf: section(7) .BTF, size 155, link 0, flags 0, type=1 libbpf: section(8) .BTF.ext, size 80, link 0, flags 0, type=1 libbpf: section(9) .rel.BTF.ext, size 32, link 14, flags 0, type=9 libbpf: skip relo .rel.BTF.ext(9) for section(8) libbpf: section(10) .debug_frame, size 40, link 0, flags 0, type=1 libbpf: skip section(10) .debug_frame libbpf: section(11) .rel.debug_frame, size 16, link 14, flags 0, type=9 libbpf: skip relo .rel.debug_frame(11) for section(10) libbpf: section(12) .debug_line, size 74, link 0, flags 0, type=1 libbpf: skip section(12) .debug_line libbpf: section(13) .rel.debug_line, size 16, link 14, flags 0, type=9 libbpf: skip relo .rel.debug_line(13) for section(12) libbpf: section(14) .symtab, size 96, link 1, flags 0, type=2 libbpf: looking for externs among 4 symbols... libbpf: collected 0 externs total libbpf: failed to guess program type from ELF section '.text' libbpf: supported section(type) names are: socket sk_reuseport kprobe/ [...] After: # bpftool prog load sample_ret0.o /sys/fs/bpf/sample_ret0 libbpf: failed to guess program type from ELF section '.text' libbpf: supported section(type) names are: socket sk_reuseport kprobe/ [...] Signed-off-by: Quentin Monnet Signed-off-by: Alexei Starovoitov Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200311021205.9755-1-quentin@isovalent.com Signed-off-by: Alexei Starovoitov ","tools/bpf/bpftool/common.c | 7 +++++++; tools/bpf/bpftool/main.c | 7 -------; tools/bpf/bpftool/main.h | 5 +++++; tools/bpf/bpftool/prog.c | 27 +++++++++++++++++++++++----; 4 files changed, 35 insertions(+), 11 deletions(-)","This commit enhances bpftool to display error messages when it fails to determine eBPF program type by running debug logs on failure.","bpftool,error,message","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"bfea9a8574f34597581f74f792d044d38497b775","bfea9a8574f34597581f74f792d044d38497b775","Jiri Olsa","jolsa@kernel.org","1584042959","Alexei Starovoitov","ast@kernel.org","1584128991","db1f634cfbb8d0aa93e8975fb54815c0eadf36cb","535911c80ad4f5801700e9d827a1985bbff41519","bpf: Add name to struct bpf_ksym Adding name to 'struct bpf_ksym' object to carry the name of the symbol for bpf_prog, bpf_trampoline, bpf_dispatcher objects. The current benefit is that name is now generated only when the symbol is added to the list, so we don't need to generate it every time it's accessed. The future benefit is that we will have all the bpf objects symbols represented by struct bpf_ksym. Signed-off-by: Jiri Olsa Signed-off-by: Alexei Starovoitov Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200312195610.346362-5-jolsa@kernel.org Signed-off-by: Alexei Starovoitov ","include/linux/bpf.h | 2 ++; include/linux/filter.h | 6 ------; kernel/bpf/core.c | 9 ++++++---; kernel/events/core.c | 9 ++++-----; 4 files changed, 12 insertions(+), 14 deletions(-)","Added name field to struct bpf_ksym for efficient symbol name generation and representation of bpf objects.","bpf, ksym, symbol","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"535911c80ad4f5801700e9d827a1985bbff41519","535911c80ad4f5801700e9d827a1985bbff41519","Jiri Olsa","jolsa@kernel.org","1584042958","Alexei Starovoitov","ast@kernel.org","1584128991","bbb6ef548496d99a0d46e3d961748856fe8d285d","6a64037d4bf252bb8cf13917320c8e001da8997a","bpf: Add struct bpf_ksym Adding 'struct bpf_ksym' object that will carry the kallsym information for bpf symbol. Adding the start and end address to begin with. It will be used by bpf_prog, bpf_trampoline, bpf_dispatcher objects. The symbol_start/symbol_end values were originally used to sort bpf_prog objects. For the address displayed in /proc/kallsyms we are using prog->bpf_func value. I'm using the bpf_func value for program symbol start instead of the symbol_start, because it makes no difference for sorting bpf_prog objects and we can use it directly as an address to display it in /proc/kallsyms. Signed-off-by: Jiri Olsa Signed-off-by: Alexei Starovoitov Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200312195610.346362-4-jolsa@kernel.org Signed-off-by: Alexei Starovoitov ","include/linux/bpf.h | 6 ++++++; kernel/bpf/core.c | 28 ++++++++++++----------------; 2 files changed, 18 insertions(+), 16 deletions(-)","The commit adds 'struct bpf_ksym' which manages kallsym information for BPF symbols with start and end addresses.","bpf_ksym,kallsym,symbol","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"6a64037d4bf252bb8cf13917320c8e001da8997a","6a64037d4bf252bb8cf13917320c8e001da8997a","Björn Töpel","bjorn.topel@intel.com","1584042957","Alexei Starovoitov","ast@kernel.org","1584128991","c99151660a803532d4f15bc1bb96386d2ef2244e","b56cd05c55a10afd479a1877d7f6a50d92d8536e","bpf: Add bpf_trampoline_ name prefix for DECLARE_BPF_DISPATCHER Adding bpf_trampoline_ name prefix for DECLARE_BPF_DISPATCHER, so all the dispatchers have the common name prefix. And also a small '_' cleanup for bpf_dispatcher_nopfunc function name. Signed-off-by: Björn Töpel Signed-off-by: Jiri Olsa Signed-off-by: Alexei Starovoitov Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200312195610.346362-3-jolsa@kernel.org Signed-off-by: Alexei Starovoitov ","include/linux/bpf.h | 21 +++++++++++----------; include/linux/filter.h | 9 ++++-----; net/core/filter.c | 5 ++---; 3 files changed, 17 insertions(+), 18 deletions(-)","The commit prefixes dispatcher functions with 'bpf_trampoline_' for consistency and cleans up a function name.","bpf_trampoline, dispatcher, cleanup","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"b56cd05c55a10afd479a1877d7f6a50d92d8536e","b56cd05c55a10afd479a1877d7f6a50d92d8536e","Jiri Olsa","jolsa@kernel.org","1584042956","Alexei Starovoitov","ast@kernel.org","1584128991","15f9be42eabf72cda1269a2a27c234571a4710f3","98868668367b24487c0b0b3298d7ca98409baf07","x86/mm: Rename is_kernel_text to __is_kernel_text The kbuild test robot reported compile issue on x86 in one of the following patches that adds include into , which is picked up by init_32.c object. The problem is that defines global function is_kernel_text which colides with the static function of the same name defined in init_32.c: $ make ARCH=i386 ... >> arch/x86/mm/init_32.c:241:19: error: redefinition of 'is_kernel_text' static inline int is_kernel_text(unsigned long addr) ^~~~~~~~~~~~~~ In file included from include/linux/bpf.h:21:0, from include/linux/bpf-cgroup.h:5, from include/linux/cgroup-defs.h:22, from include/linux/cgroup.h:28, from include/linux/hugetlb.h:9, from arch/x86/mm/init_32.c:18: include/linux/kallsyms.h:31:19: note: previous definition of 'is_kernel_text' was here static inline int is_kernel_text(unsigned long addr) Renaming the init_32.c is_kernel_text function to __is_kernel_text. Reported-by: kbuild test robot Signed-off-by: Jiri Olsa Signed-off-by: Alexei Starovoitov Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200312195610.346362-2-jolsa@kernel.org Signed-off-by: Alexei Starovoitov ","arch/x86/mm/init_32.c | 14 +++++++++-----; 1 file changed, 9 insertions(+), 5 deletions(-)","The commit resolves a naming conflict by renaming a function in x86 init_32.c.","rename,function,conflict","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.","It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.","[""It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.""]" +"242a6df688dcad7c55105280a79aaff83addf7ce","242a6df688dcad7c55105280a79aaff83addf7ce","David S. Miller","davem@davemloft.net","1584123225","David S. Miller","davem@davemloft.net","1584123225","f9adee4a9f9cc9e55bcace5b5ae91fdc032c0699","0d81a3f29c0afb18ba2b1275dcccf21e0dd4da38 90db6d772f749e38171d04619a5e3cd8804a6d02","Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf Alexei Starovoitov says: ==================== pull-request: bpf 2020-03-12 The following pull-request contains BPF updates for your *net* tree. We've added 12 non-merge commits during the last 8 day(s) which contain a total of 12 files changed, 161 insertions(+), 15 deletions(-). The main changes are: 1) Andrii fixed two bugs in cgroup-bpf. 2) John fixed sockmap. 3) Luke fixed x32 jit. 4) Martin fixed two issues in struct_ops. 5) Yonghong fixed bpf_send_signal. 6) Yoshiki fixed BTF enum. ==================== Signed-off-by: David S. Miller ","","The commit merges multiple BPF updates including bug fixes in components like cgroup-bpf and sockmap into the *net* tree.","merge,BPF,fixes","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"d831ee84bfc9173eecf30dbbc2553ae81b996c60","d831ee84bfc9173eecf30dbbc2553ae81b996c60","Eelco Chaudron","echaudro@redhat.com","1583485163","Alexei Starovoitov","ast@kernel.org","1584060458","52c110beaf9330261d28ed885ea246cb66e39ee8","4823b7210b90a10b88b0c56198f894b27a767509","bpf: Add bpf_xdp_output() helper Introduce new helper that reuses existing xdp perf_event output implementation, but can be called from raw_tracepoint programs that receive 'struct xdp_buff *' as a tracepoint argument. Signed-off-by: Eelco Chaudron Signed-off-by: Alexei Starovoitov Acked-by: John Fastabend Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/158348514556.2239.11050972434793741444.stgit@xdp-tutorial","include/uapi/linux/bpf.h | 26 ++++++++++-; kernel/bpf/verifier.c | 4 +-; kernel/trace/bpf_trace.c | 3 ++; net/core/filter.c | 16 ++++++-; tools/include/uapi/linux/bpf.h | 26 ++++++++++-; .../testing/selftests/bpf/prog_tests/xdp_bpf2bpf.c | 53 ++++++++++++++++++++++; .../testing/selftests/bpf/progs/test_xdp_bpf2bpf.c | 24 ++++++++++; 7 files changed, 148 insertions(+), 4 deletions(-)","The commit introduces a new bpf_xdp_output() helper for raw_tracepoint programs to leverage xdp_buff structures for perf event outputs.","bpf_xdp_output, raw_tracepoint, xdp_buff","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.', 'Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"4823b7210b90a10b88b0c56198f894b27a767509","4823b7210b90a10b88b0c56198f894b27a767509","Alexei Starovoitov","ast@kernel.org","1584059592","Alexei Starovoitov","ast@kernel.org","1584060062","9b5177a264a126a0e5d9178d7b1585b596528145","132c1af0a23d049e2ec93eb6a180d9de71d3a32f 1c1052e0140af8f211c283c0a333ecff2a6edfc9","Merge branch 'bpf_get_ns_current_pid_tgid' Carlos Neira says: ==================== Currently bpf_get_current_pid_tgid(), is used to do pid filtering in bcc's scripts but this helper returns the pid as seen by the root namespace which is fine when a bcc script is not executed inside a container. When the process of interest is inside a container, pid filtering will not work if bpf_get_current_pid_tgid() is used. This helper addresses this limitation returning the pid as it's seen by the current namespace where the script is executing. In the future different pid_ns files may belong to different devices, according to the discussion between Eric Biederman and Yonghong in 2017 Linux plumbers conference. To address that situation the helper requires inum and dev_t from /proc/self/ns/pid. This helper has the same use cases as bpf_get_current_pid_tgid() as it can be used to do pid filtering even inside a container. ==================== Signed-off-by: Alexei Starovoitov ","","Merges changes to introduce a helper for obtaining PIDs in the current namespace for container compatibility.","PID, filter, namespace","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","['cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups).', ""It's likely a merge commit. It involves changes across multiple use cases or events."", ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"1c1052e0140af8f211c283c0a333ecff2a6edfc9","1c1052e0140af8f211c283c0a333ecff2a6edfc9","Carlos Neira","cneirabustos@gmail.com","1583354517","Alexei Starovoitov","ast@kernel.org","1584060047","9b5177a264a126a0e5d9178d7b1585b596528145","b4490c5c4e023f09b7d27c9a9d3e7ad7d09ea6bf","tools/testing/selftests/bpf: Add self-tests for new helper bpf_get_ns_current_pid_tgid. Self tests added for new helper bpf_get_ns_current_pid_tgid Signed-off-by: Carlos Neira Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200304204157.58695-4-cneirabustos@gmail.com","tools/testing/selftests/bpf/.gitignore | 1 +; tools/testing/selftests/bpf/Makefile | 3 +-; .../selftests/bpf/prog_tests/ns_current_pid_tgid.c | 88 ++++++++++++; .../selftests/bpf/progs/test_ns_current_pid_tgid.c | 37 +++++; .../selftests/bpf/test_current_pid_tgid_new_ns.c | 159 +++++++++++++++++++++; 5 files changed, 287 insertions(+), 1 deletion(-)","This commit adds self-tests for the new eBPF helper bpf_get_ns_current_pid_tgid.","self-tests,new helper,bpf","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"b4490c5c4e023f09b7d27c9a9d3e7ad7d09ea6bf","b4490c5c4e023f09b7d27c9a9d3e7ad7d09ea6bf","Carlos Neira","cneirabustos@gmail.com","1583354516","Alexei Starovoitov","ast@kernel.org","1584059591","2a1bcba2ff5a85b3fb0e0013b01ac25eef4cc6fa","1e2328e762548c7d17b7ba8ded9f409d05710dd1","bpf: Added new helper bpf_get_ns_current_pid_tgid New bpf helper bpf_get_ns_current_pid_tgid, This helper will return pid and tgid from current task which namespace matches dev_t and inode number provided, this will allows us to instrument a process inside a container. Signed-off-by: Carlos Neira Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200304204157.58695-3-cneirabustos@gmail.com","include/linux/bpf.h | 1 +; include/uapi/linux/bpf.h | 20 ++++++++++++++++++-; kernel/bpf/core.c | 1 +; kernel/bpf/helpers.c | 45 ++++++++++++++++++++++++++++++++++++++++++; kernel/trace/bpf_trace.c | 2 ++; scripts/bpf_helpers_doc.py | 1 +; tools/include/uapi/linux/bpf.h | 20 ++++++++++++++++++-; 7 files changed, 88 insertions(+), 2 deletions(-)","This commit adds a new eBPF helper function to retrieve the PID and TGID for processes in specific namespaces using device and inode criteria.","helper,namespace,pid","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"1e2328e762548c7d17b7ba8ded9f409d05710dd1","1e2328e762548c7d17b7ba8ded9f409d05710dd1","Carlos Neira","cneirabustos@gmail.com","1583354515","Alexei Starovoitov","ast@kernel.org","1584059591","6972c2aa0e86e3fb3590e3fe24c45db5f2d83928","132c1af0a23d049e2ec93eb6a180d9de71d3a32f","fs/nsfs.c: Added ns_match ns_match returns true if the namespace inode and dev_t matches the ones provided by the caller. Signed-off-by: Carlos Neira Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200304204157.58695-2-cneirabustos@gmail.com","fs/nsfs.c | 14 ++++++++++++++; include/linux/proc_ns.h | 2 ++; 2 files changed, 16 insertions(+)","This commit adds a function to match namespace inodes and device identifiers in the Linux filesystem code.","ns_match, namespace, inode","It's other type of commit. It does not fit into any of the categories listed above.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.","It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.","[""It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.""]" +"132c1af0a23d049e2ec93eb6a180d9de71d3a32f","132c1af0a23d049e2ec93eb6a180d9de71d3a32f","Quentin Monnet","quentin@isovalent.com","1584038768","Daniel Borkmann","daniel@iogearbox.net","1584055448","bbb5de804ab3af6e0789cbd33be45c427ee6616a","75a1e792c335b5c6d7fdb1014da47aeb64c5944f","tools: bpftool: Fix minor bash completion mistakes Minor fixes for bash completion: addition of program name completion for two subcommands, and correction for program test-runs and map pinning. The completion for the following commands is fixed or improved: # bpftool prog run [TAB] # bpftool prog pin [TAB] # bpftool map pin [TAB] # bpftool net attach xdp name [TAB] Signed-off-by: Quentin Monnet Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200312184608.12050-3-quentin@isovalent.com","tools/bpf/bpftool/bash-completion/bpftool | 29 +++++++++++++++++++++--------; 1 file changed, 21 insertions(+), 8 deletions(-)","The commit corrects and enhances bash completion for bpftool commands related to program and map operations.","bash,completion,bpftool","A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"75a1e792c335b5c6d7fdb1014da47aeb64c5944f","75a1e792c335b5c6d7fdb1014da47aeb64c5944f","Quentin Monnet","quentin@isovalent.com","1584038767","Daniel Borkmann","daniel@iogearbox.net","1584055448","f35913237fc5ebed02ed798b29a734bd4a20056b","b35f14f410416f06ec54d187dedc372405757290","tools: bpftool: Allow all prog/map handles for pinning objects Documentation and interactive help for bpftool have always explained that the regular handles for programs (id|name|tag|pinned) and maps (id|name|pinned) can be passed to the utility when attempting to pin objects (bpftool prog pin PROG / bpftool map pin MAP). THIS IS A LIE!! The tool actually accepts only ids, as the parsing is done in do_pin_any() in common.c instead of reusing the parsing functions that have long been generic for program and map handles. Instead of fixing the doc, fix the code. It is trivial to reuse the generic parsing, and to simplify do_pin_any() in the process. Do not accept to pin multiple objects at the same time with prog_parse_fds() or map_parse_fds() (this would require a more complex syntax for passing multiple sysfs paths and validating that they correspond to the number of e.g. programs we find for a given name or tag). Signed-off-by: Quentin Monnet Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200312184608.12050-2-quentin@isovalent.com","tools/bpf/bpftool/common.c | 33 ++++-----------------------------; tools/bpf/bpftool/main.h | 2 +-; tools/bpf/bpftool/map.c | 2 +-; tools/bpf/bpftool/prog.c | 2 +-; 4 files changed, 7 insertions(+), 32 deletions(-)","Fix bpftool to correctly accept all supported program and map handles for pinning objects, aligning code with documentation.","bpftool, parsing, pinning","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"b35f14f410416f06ec54d187dedc372405757290","b35f14f410416f06ec54d187dedc372405757290","Andrii Nakryiko","andriin@fb.com","1584039033","Daniel Borkmann","daniel@iogearbox.net","1584054916","06612def5679797955f2e506c2d2f28cf3504a6c","8d830f549dbd2f9cc4656a17704a2896682cbb5b","libbpf: Split BTF presence checks into libbpf- and kernel-specific parts Needs for application BTF being present differs between user-space libbpf needs and kernel needs. Currently, BTF is mandatory only in kernel only when BPF application is using STRUCT_OPS. While libbpf itself relies more heavily on presense of BTF: - for BTF-defined maps; - for Kconfig externs; - for STRUCT_OPS as well. Thus, checks for presence and validness of bpf_object's BPF needs to be performed separately, which is patch does. Fixes: 5327644614a1 (""libbpf: Relax check whether BTF is mandatory"") Reported-by: Michal Rostecki Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Cc: Quentin Monnet Link: https://lore.kernel.org/bpf/20200312185033.736911-1-andriin@fb.com","tools/lib/bpf/libbpf.c | 17 ++++++++++++-----; 1 file changed, 12 insertions(+), 5 deletions(-)","The commit separates BTF checks into user-space libbpf and kernel-specific requirements.","libbpf, BTF, STRUCT_OPS","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems.']" +"8d830f549dbd2f9cc4656a17704a2896682cbb5b","8d830f549dbd2f9cc4656a17704a2896682cbb5b","Song Liu","songliubraving@fb.com","1584037412","Daniel Borkmann","daniel@iogearbox.net","1584054513","5fb893f2bcb651a34a9f5160a283b9db5d63a702","39be909c38a42543239de97087d3c93ea9272864","bpftool: Add _bpftool and profiler.skel.h to .gitignore These files are generated, so ignore them. Signed-off-by: Song Liu Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200312182332.3953408-4-songliubraving@fb.com","tools/bpf/bpftool/.gitignore | 2 ++; 1 file changed, 2 insertions(+)","This commit adds auto-generated files _bpftool and profiler.skel.h to .gitignore in bpftool.","bpftool,gitignore,generated","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"39be909c38a42543239de97087d3c93ea9272864","39be909c38a42543239de97087d3c93ea9272864","Song Liu","songliubraving@fb.com","1584037411","Daniel Borkmann","daniel@iogearbox.net","1584054513","5b03b3392ad73451b923bede2396bd5f8fae0568","14e5728ff8176d4d5924b0bf5ab9b1c94d6b3381","bpftool: Skeleton should depend on libbpf Add the dependency to libbpf, to fix build errors like: In file included from skeleton/profiler.bpf.c:5: .../bpf_helpers.h:5:10: fatal error: 'bpf_helper_defs.h' file not found #include ""bpf_helper_defs.h"" ^~~~~~~~~~~~~~~~~~~ 1 error generated. make: *** [skeleton/profiler.bpf.o] Error 1 make: *** Waiting for unfinished jobs.... Fixes: 47c09d6a9f67 (""bpftool: Introduce ""prog profile"" command"") Suggested-by: Quentin Monnet Signed-off-by: Song Liu Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200312182332.3953408-3-songliubraving@fb.com","tools/bpf/bpftool/Makefile | 5 +++--; 1 file changed, 3 insertions(+), 2 deletions(-)","The commit adds a dependency on libbpf to the bpftool to prevent build errors.","libbpf,bpftool,dependency","A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"14e5728ff8176d4d5924b0bf5ab9b1c94d6b3381","14e5728ff8176d4d5924b0bf5ab9b1c94d6b3381","Song Liu","songliubraving@fb.com","1584037410","Daniel Borkmann","daniel@iogearbox.net","1584054513","96fd81f008024bf24e32bd4633822a7eef9e9571","fe4eb069edb7ab845160350d9e67d572c026a4a7","bpftool: Only build bpftool-prog-profile if supported by clang bpftool-prog-profile requires clang to generate BTF for global variables. When compared with older clang, skip this command. This is achieved by adding a new feature, clang-bpf-global-var, to tools/build/feature. Signed-off-by: Song Liu Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200312182332.3953408-2-songliubraving@fb.com","tools/bpf/bpftool/Makefile | 15 +++++++++++----; tools/bpf/bpftool/prog.c | 1 +; tools/build/feature/Makefile | 9 ++++++++-; tools/build/feature/test-clang-bpf-global-var.c | 4 ++++; 4 files changed, 24 insertions(+), 5 deletions(-)","The commit updates bpftool to only build bpftool-prog-profile if clang supports BTF generation for global variables.","bpftool,clang,BTF","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"fe4eb069edb7ab845160350d9e67d572c026a4a7","fe4eb069edb7ab845160350d9e67d572c026a4a7","Tobias Klauser","tklauser@distanz.ch","1584018210","Daniel Borkmann","daniel@iogearbox.net","1584026561","840739e27a07ed6f88a4ea40a1950b74c9a8392c","37ccc12bbcef880e6b3fdf7e03cf9e5fe9df99f2","bpftool: Use linux/types.h from source tree for profiler build When compiling bpftool on a system where the /usr/include/asm symlink doesn't exist (e.g. on an Ubuntu system without gcc-multilib installed), the build fails with: CLANG skeleton/profiler.bpf.o In file included from skeleton/profiler.bpf.c:4: In file included from /usr/include/linux/bpf.h:11: /usr/include/linux/types.h:5:10: fatal error: 'asm/types.h' file not found #include ^~~~~~~~~~~~~ 1 error generated. make: *** [Makefile:123: skeleton/profiler.bpf.o] Error 1 This indicates that the build is using linux/types.h from system headers instead of source tree headers. To fix this, adjust the clang search path to include the necessary headers from tools/testing/selftests/bpf/include/uapi and tools/include/uapi. Also use __bitwise__ instead of __bitwise in skeleton/profiler.h to avoid clashing with the definition in tools/testing/selftests/bpf/include/uapi/linux/types.h. Signed-off-by: Tobias Klauser Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200312130330.32239-1-tklauser@distanz.ch","tools/bpf/bpftool/Makefile | 5 ++++-; tools/bpf/bpftool/skeleton/profiler.h | 17 ++++++++---------; 2 files changed, 12 insertions(+), 10 deletions(-)","This commit fixes a header file inclusion issue in bpftool to ensure proper compilation across different systems.","bpftool, compilation, header","A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"37ccc12bbcef880e6b3fdf7e03cf9e5fe9df99f2","37ccc12bbcef880e6b3fdf7e03cf9e5fe9df99f2","Andrii Nakryiko","andriin@fb.com","1583901010","Daniel Borkmann","daniel@iogearbox.net","1583936259","cf80dd1cb387fce8e3169c111ea59c4708c8f576","13fac1d851e09109096b5862bf37c3da6908fb48","tools/runqslower: Add BPF_F_CURRENT_CPU for running selftest on older kernels Libbpf compiles and runs subset of selftests on each PR in its Github mirror repository. To allow still building up-to-date selftests against outdated kernel images, add back BPF_F_CURRENT_CPU definitions back. N.B. BCC's runqslower version ([0]) doesn't need BPF_F_CURRENT_CPU due to use of locally checked in vmlinux.h, generated against kernel with 1aae4bdd7879 (""bpf: Switch BPF UAPI #define constants used from BPF program side to enums"") applied. [0] https://github.com/iovisor/bcc/pull/2809 Fixes: 367d82f17eff ("" tools/runqslower: Drop copy/pasted BPF_F_CURRENT_CPU definiton"") Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200311043010.530620-1-andriin@fb.com","tools/bpf/runqslower/runqslower.bpf.c | 1 +; 1 file changed, 1 insertion(+)","The commit reintroduces BPF_F_CURRENT_CPU definition to runqslower for compatibility with older kernels in selftests.","runqslower,BPF_F_CURRENT_CPU,compatibility","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"90db6d772f749e38171d04619a5e3cd8804a6d02","90db6d772f749e38171d04619a5e3cd8804a6d02","John Fastabend","john.fastabend@gmail.com","1583858508","Daniel Borkmann","daniel@iogearbox.net","1583932132","db2c11ba32e62129a1eb3c11c4dfa0f90d8035bb","f7861a55b1ce35d0cacfd1f0435f46533dbc9b67","bpf, sockmap: Remove bucket->lock from sock_{hash|map}_free The bucket->lock is not needed in the sock_hash_free and sock_map_free calls, in fact it is causing a splat due to being inside rcu block. | BUG: sleeping function called from invalid context at net/core/sock.c:2935 | in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 62, name: kworker/0:1 | 3 locks held by kworker/0:1/62: | #0: ffff88813b019748 ((wq_completion)events){+.+.}, at: process_one_work+0x1d7/0x5e0 | #1: ffffc900000abe50 ((work_completion)(&map->work)){+.+.}, at: process_one_work+0x1d7/0x5e0 | #2: ffff8881381f6df8 (&stab->lock){+...}, at: sock_map_free+0x26/0x180 | CPU: 0 PID: 62 Comm: kworker/0:1 Not tainted 5.5.0-04008-g7b083332376e #454 | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 | Workqueue: events bpf_map_free_deferred | Call Trace: | dump_stack+0x71/0xa0 | ___might_sleep.cold+0xa6/0xb6 | lock_sock_nested+0x28/0x90 | sock_map_free+0x5f/0x180 | bpf_map_free_deferred+0x58/0x80 | process_one_work+0x260/0x5e0 | worker_thread+0x4d/0x3e0 | kthread+0x108/0x140 | ? process_one_work+0x5e0/0x5e0 | ? kthread_park+0x90/0x90 | ret_from_fork+0x3a/0x50 The reason we have stab->lock and bucket->locks in sockmap code is to handle checking EEXIST in update/delete cases. We need to be careful during an update operation that we check for EEXIST and we need to ensure that the psock object is not in some partial state of removal/insertion while we do this. So both map_update_common and sock_map_delete need to guard from being run together potentially deleting an entry we are checking, etc. But by the time we get to the tear-down code in sock_{ma[|hash}_free we have already disconnected the map and we just did synchronize_rcu() in the line above so no updates/deletes should be in flight. Because of this we can drop the bucket locks from the map free'ing code, noting no update/deletes can be in-flight. Fixes: 604326b41a6f (""bpf, sockmap: convert to generic sk_msg interface"") Reported-by: Jakub Sitnicki Suggested-by: Jakub Sitnicki Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/158385850787.30597.8346421465837046618.stgit@john-Precision-5820-Tower","net/core/sock_map.c | 12 ++++++++----; 1 file changed, 8 insertions(+), 4 deletions(-)","This commit removes unnecessary locks from sockmap free functions to fix a context bug in eBPF socket programs.","sockmap,lock,bug","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime."", ""I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear.""]" +"13fac1d851e09109096b5862bf37c3da6908fb48","13fac1d851e09109096b5862bf37c3da6908fb48","Alexei Starovoitov","ast@kernel.org","1583887146","Daniel Borkmann","daniel@iogearbox.net","1583932052","927815f0128976e44e7f0435f52b91dd348ca4ea","babf3164095b0670435910340c2a1eec37757b57","bpf: Fix trampoline generation for fmod_ret programs fmod_ret progs are emitted as: start = __bpf_prog_enter(); call fmod_ret *(u64 *)(rbp - 8) = rax __bpf_prog_exit(, start); test eax, eax jne do_fexit That 'test eax, eax' is working by accident. The compiler is free to use rax inside __bpf_prog_exit() or inside functions that __bpf_prog_exit() is calling. Which caused ""test_progs -t modify_return"" to sporadically fail depending on compiler version and kconfig. Fix it by using 'cmp [rbp - 8], 0' instead of 'test eax, eax'. Fixes: ae24082331d9 (""bpf: Introduce BPF_MODIFY_RETURN"") Reported-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Acked-by: KP Singh Link: https://lore.kernel.org/bpf/20200311003906.3643037-1-ast@kernel.org","arch/x86/net/bpf_jit_comp.c | 31 +++++--------------------------; 1 file changed, 5 insertions(+), 26 deletions(-)","Fixes trampoline generation for fmod_ret programs by changing a faulty instruction to prevent sporadic test failures.","trampoline,fmod_ret,fix","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"babf3164095b0670435910340c2a1eec37757b57","babf3164095b0670435910340c2a1eec37757b57","Andrii Nakryiko","andriin@fb.com","1583795451","Daniel Borkmann","daniel@iogearbox.net","1583931768","827de49bba040e01901d8b024f08caaad82c9acc","aad32f4c76a22fa0417db083a8cbf9222d4f3d9a","bpf: Add bpf_link_new_file that doesn't install FD Add bpf_link_new_file() API for cases when we need to ensure anon_inode is successfully created before we proceed with expensive BPF program attachment procedure, which will require equally (if not more so) expensive and potentially failing compensation detachment procedure just because anon_inode creation failed. This API allows to simplify code by ensuring first that anon_inode is created and after BPF program is attached proceed with fd_install() that can't fail. After anon_inode file is created, link can't be just kfree()'d anymore, because its destruction will be performed by deferred file_operations->release call. For this, bpf_link API required specifying two separate operations: release() and dealloc(), former performing detachment only, while the latter frees memory used by bpf_link itself. dealloc() needs to be specified, because struct bpf_link is frequently embedded into link type-specific container struct (e.g., struct bpf_raw_tp_link), so bpf_link itself doesn't know how to properly free the memory. In case when anon_inode file was successfully created, but subsequent BPF attachment failed, bpf_link needs to be marked as ""defunct"", so that file's release() callback will perform only memory deallocation, but no detachment. Convert raw tracepoint and tracing attachment to new API and eliminate detachment from error handling path. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200309231051.1270337-1-andriin@fb.com","include/linux/bpf.h | 3 ++; kernel/bpf/syscall.c | 122 +++++++++++++++++++++++++++++++++++++--------------; 2 files changed, 91 insertions(+), 34 deletions(-)","This commit introduces the bpf_link_new_file API to improve BPF program attachment handling and error management.","bpf link api","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The syscall interface. It changes the system calls through which user-space programs interact with eBPF.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.', 'kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.']" +"f7861a55b1ce35d0cacfd1f0435f46533dbc9b67","f7861a55b1ce35d0cacfd1f0435f46533dbc9b67","Alexei Starovoitov","ast@kernel.org","1583859642","Alexei Starovoitov","ast@kernel.org","1583859647","524f44a063aa249f4b93668b0149564311175cc7","1d8006abaab4cb90f81add86e8d1bf9411add05a 6ffe559a77d1c963a3567f7a39a5419bdcdc4f1c","Merge branch 'fix-BTF-enum' Yoshiki Komachi says: ==================== btf_enum_check_member() checked if the size of ""enum"" as a struct member exceeded struct_size or not. Then, the function compared it with the size of ""int"". Although the size of ""enum"" is 4-byte by default (i.e., equivalent to ""int""), the packing feature enables us to reduce it, as illustrated by the following example: struct A { char m; enum { E0, E1 } __attribute__((packed)) n; }; With such a setup above, the bpf loader gave an error attempting to load it: ------------------------------------------------------------------ ... [3] ENUM (anon) size=1 vlen=2 E0 val=0 E1 val=1 [4] STRUCT A size=2 vlen=2 m type_id=2 bits_offset=0 n type_id=3 bits_offset=8 [4] STRUCT A size=2 vlen=2 n type_id=3 bits_offset=8 Member exceeds struct_size libbpf: Error loading .BTF into kernel: -22. ------------------------------------------------------------------ The related issue was previously fixed by the commit 9eea98497951 (""bpf: fix BTF verification of enums""). On the other hand, this series fixes this issue as well, and adds a selftest program for it. Changes in v2: - change an example in commit message based on Andrii's review - add a selftest program for packed ""enum"" type members in struct/union ==================== Acked-by: Andrii Nakryiko Acked-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov ","","This commit merges a branch addressing a BTF issue with enum size checking and includes a selftest for packed enums.","BTF,enum,selftest","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"6ffe559a77d1c963a3567f7a39a5419bdcdc4f1c","6ffe559a77d1c963a3567f7a39a5419bdcdc4f1c","Yoshiki Komachi","komachi.yoshiki@gmail.com","1583825550","Alexei Starovoitov","ast@kernel.org","1583859641","524f44a063aa249f4b93668b0149564311175cc7","da6c7faeb103c493e505e87643272f70be586635","selftests/bpf: Add test for the packed enum member in struct/union Add a simple test to the existing selftest program in order to make sure that a packed enum member in struct unexceeds the struct_size. Signed-off-by: Yoshiki Komachi Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/1583825550-18606-3-git-send-email-komachi.yoshiki@gmail.com","tools/testing/selftests/bpf/test_btf.c | 42 ++++++++++++++++++++++++++++++++++; 1 file changed, 42 insertions(+)","This commit adds a selftest to check handling of packed enum members in eBPF structs.","selftest,packed,enum","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"da6c7faeb103c493e505e87643272f70be586635","da6c7faeb103c493e505e87643272f70be586635","Yoshiki Komachi","komachi.yoshiki@gmail.com","1583825549","Alexei Starovoitov","ast@kernel.org","1583859641","41c62e0d904f0ebaa19ce488df5552bccc485a89","1d8006abaab4cb90f81add86e8d1bf9411add05a","bpf/btf: Fix BTF verification of enum members in struct/union btf_enum_check_member() was currently sure to recognize the size of ""enum"" type members in struct/union as the size of ""int"" even if its size was packed. This patch fixes BTF enum verification to use the correct size of member in BPF programs. Fixes: 179cde8cef7e (""bpf: btf: Check members of struct/union"") Signed-off-by: Yoshiki Komachi Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/1583825550-18606-2-git-send-email-komachi.yoshiki@gmail.com","kernel/bpf/btf.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","The commit fixes BTF enum member size verification in struct/union for BPF programs.","BTF,enum,verification","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.","BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"d2abfbe4652d2b49d30fe77548cf663e63d2d469","d2abfbe4652d2b49d30fe77548cf663e63d2d469","Heiko Carstens","heiko.carstens@de.ibm.com","1583416881","Vasily Gorbik","gor@linux.ibm.com","1583849785","64c20465a391722fd7325516b055a9f5e9bb4b4b","d68d5d51dc898895b4e15bea52e5668ca9e76180","s390: enable bpf jit by default when not built as always-on This is the s390 variant of commit 81c22041d9f1 (""bpf, x86, arm64: Enable jit by default when not built as always-on""). Acked-by: Ilya Leoshkevich Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik ","arch/s390/Kconfig | 1 +; 1 file changed, 1 insertion(+)","Enable BPF JIT compilation by default on s390 machines when not built as always-on.","s390,JIT,default","A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"1d8006abaab4cb90f81add86e8d1bf9411add05a","1d8006abaab4cb90f81add86e8d1bf9411add05a","Andrii Nakryiko","andriin@fb.com","1583793617","Alexei Starovoitov","ast@kernel.org","1583809134","b6dd24074e513d6fb9845dbfe28b30f2c7dcd671","62039c30c19dcab96621e074aeeb90da7100def7","bpf: Fix cgroup ref leak in cgroup_bpf_inherit on out-of-memory There is no compensating cgroup_bpf_put() for each ancestor cgroup in cgroup_bpf_inherit(). If compute_effective_progs returns error, those cgroups won't be freed ever. Fix it by putting them in cleanup code path. Fixes: e10360f815ca (""bpf: cgroup: prevent out-of-order release of cgroup bpf"") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Roman Gushchin Link: https://lore.kernel.org/bpf/20200309224017.1063297-1-andriin@fb.com","kernel/bpf/cgroup.c | 3 +++; 1 file changed, 3 insertions(+)","The commit fixes a reference leak in cgroup_bpf_inherit by adding necessary cleanup code on error paths.","cgroup, ref leak, cleanup","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups).']" +"62039c30c19dcab96621e074aeeb90da7100def7","62039c30c19dcab96621e074aeeb90da7100def7","Andrii Nakryiko","andriin@fb.com","1583792875","Alexei Starovoitov","ast@kernel.org","1583809008","7eaf14dc8ca1e1c1751eb54448f63f7ad35bc002","93e5fbb18cec70b3b5c614f67b65388829113bdd","bpf: Initialize storage pointers to NULL to prevent freeing garbage pointer Local storage array isn't initialized, so if cgroup storage allocation fails for BPF_CGROUP_STORAGE_SHARED, error handling code will attempt to free uninitialized pointer for BPF_CGROUP_STORAGE_PERCPU storage type. Avoid this by always initializing storage pointers to NULLs. Fixes: 8bad74f9840f (""bpf: extend cgroup bpf core to allow multiple cgroup storage types"") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200309222756.1018737-1-andriin@fb.com","kernel/bpf/cgroup.c | 4 ++--; 1 file changed, 2 insertions(+), 2 deletions(-)","The commit initializes storage pointers to prevent freeing uninitialized pointers in cgroup BPF storage.","storage,NULL,freeing","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups).']" +"d3f85437ad6a55113882d730beaa75759452da8f","d3f85437ad6a55113882d730beaa75759452da8f","Kan Liang","kan.liang@linux.intel.com","1582907401","Arnaldo Carvalho de Melo","acme@redhat.com","1583801004","1aa5ddc57164d59d2e71482cc5669e258a9273ab","42bbabed09ce6208026648a71a45b4394c74585a","perf evsel: Support PERF_SAMPLE_BRANCH_HW_INDEX A new branch sample type PERF_SAMPLE_BRANCH_HW_INDEX has been introduced in latest kernel. Enable HW_INDEX by default in LBR call stack mode. If kernel doesn't support the sample type, switching it off. Add HW_INDEX in attr_fprintf as well. User can check whether the branch sample type is set via debug information or header. Committer testing: First collect some samples with LBR callchains, system wide, for a few seconds: # perf record --call-graph lbr -a sleep 5 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.625 MB perf.data (224 samples) ] # Now lets use 'perf evlist -v' to look at the branch_sample_type: # perf evlist -v cycles: size: 120, { sample_period, sample_freq }: 4000, sample_type: IP|TID|TIME|CALLCHAIN|CPU|PERIOD|BRANCH_STACK, read_format: ID, disabled: 1, inherit: 1, mmap: 1, comm: 1, freq: 1, task: 1, precise_ip: 3, sample_id_all: 1, exclude_guest: 1, mmap2: 1, comm_exec: 1, ksymbol: 1, bpf_event: 1, branch_sample_type: USER|CALL_STACK|NO_FLAGS|NO_CYCLES|HW_INDEX # So the machine has the kernel feature, and it was correctly added to perf_event_attr.branch_sample_type, for the default 'cycles' event. If we do it in another machine, where the kernel lacks the HW_INDEX feature, we get: # perf record --call-graph lbr -a sleep 2s [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 1.690 MB perf.data (499 samples) ] # perf evlist -v cycles: size: 120, { sample_period, sample_freq }: 4000, sample_type: IP|TID|TIME|CALLCHAIN|CPU|PERIOD|BRANCH_STACK, read_format: ID, disabled: 1, inherit: 1, mmap: 1, comm: 1, freq: 1, task: 1, precise_ip: 3, sample_id_all: 1, exclude_guest: 1, mmap2: 1, comm_exec: 1, ksymbol: 1, bpf_event: 1, branch_sample_type: USER|CALL_STACK|NO_FLAGS|NO_CYCLES # No HW_INDEX in attr.branch_sample_type. Signed-off-by: Kan Liang Tested-by: Arnaldo Carvalho de Melo Cc: Adrian Hunter Cc: Alexey Budankov Cc: Andi Kleen Cc: Jiri Olsa Cc: Mathieu Poirier Cc: Michael Ellerman Cc: Namhyung Kim Cc: Pavel Gerasimov Cc: Peter Zijlstra Cc: Ravi Bangoria Cc: Stephane Eranian Cc: Vitaly Slobodskoy Link: http://lore.kernel.org/lkml/20200228163011.19358-3-kan.liang@linux.intel.com Signed-off-by: Arnaldo Carvalho de Melo ","tools/perf/util/evsel.c | 15 ++++++++++++---; tools/perf/util/evsel.h | 1 +; tools/perf/util/perf_event_attr_fprintf.c | 1 +; 3 files changed, 14 insertions(+), 3 deletions(-)","The commit adds support for PERF_SAMPLE_BRANCH_HW_INDEX in perf tools to handle branch samples with hardware indexes.","perf, HW_INDEX, branch","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.","It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.","[""It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.""]" +"aad32f4c76a22fa0417db083a8cbf9222d4f3d9a","aad32f4c76a22fa0417db083a8cbf9222d4f3d9a","Song Liu","songliubraving@fb.com","1583775138","Daniel Borkmann","daniel@iogearbox.net","1583795061","383abf3d5bc1c0e02ca24869bd351a35e7458768","397692eab35cbbd83681880c6a2dbcdb9fd84386","bpftool: Fix typo in bash-completion _bpftool_get_map_names => _bpftool_get_prog_names for prog-attach|detach. Fixes: 99f9863a0c45 (""bpftool: Match maps by name"") Signed-off-by: Song Liu Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200309173218.2739965-5-songliubraving@fb.com","tools/bpf/bpftool/bash-completion/bpftool | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","Fix typo in bpftool bash-completion script for handling program attach and detach commands.","bpftool,typo,bash-completion","A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"397692eab35cbbd83681880c6a2dbcdb9fd84386","397692eab35cbbd83681880c6a2dbcdb9fd84386","Song Liu","songliubraving@fb.com","1583775137","Daniel Borkmann","daniel@iogearbox.net","1583795059","4f33ab2af5924f9125f162eae83b6f89ebdad9e5","319c7c1f6b78a04e72d32336787912cc1b284f25","bpftool: Bash completion for ""bpftool prog profile"" Add bash completion for ""bpftool prog profile"" command. Signed-off-by: Song Liu Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200309173218.2739965-4-songliubraving@fb.com","tools/bpf/bpftool/bash-completion/bpftool | 45 ++++++++++++++++++++++++++++++-; 1 file changed, 44 insertions(+), 1 deletion(-)","The commit adds bash completion support for the ""bpftool prog profile"" command.","bash,completion,bpftool","A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"319c7c1f6b78a04e72d32336787912cc1b284f25","319c7c1f6b78a04e72d32336787912cc1b284f25","Song Liu","songliubraving@fb.com","1583775136","Daniel Borkmann","daniel@iogearbox.net","1583795047","f48d53d68b8ffc710612dc2d5f374a995f04e389","47c09d6a9f6794caface4ad50930460b82d7c670","bpftool: Documentation for bpftool prog profile Add documentation for the new bpftool prog profile command. Signed-off-by: Song Liu Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200309173218.2739965-3-songliubraving@fb.com","tools/bpf/bpftool/Documentation/bpftool-prog.rst | 19 +++++++++++++++++++; 1 file changed, 19 insertions(+)","This commit adds documentation for the new `bpftool prog profile` command.","bpftool,documentation,profile","A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"47c09d6a9f6794caface4ad50930460b82d7c670","47c09d6a9f6794caface4ad50930460b82d7c670","Song Liu","songliubraving@fb.com","1583775135","Daniel Borkmann","daniel@iogearbox.net","1583795047","bc29e8f83ffc3df13df0650e19c884970a6ab406","7b4b73bc8a609fa9655022ed24a7a714bc8c2155","bpftool: Introduce ""prog profile"" command With fentry/fexit programs, it is possible to profile BPF program with hardware counters. Introduce bpftool ""prog profile"", which measures key metrics of a BPF program. bpftool prog profile command creates per-cpu perf events. Then it attaches fentry/fexit programs to the target BPF program. The fentry program saves perf event value to a map. The fexit program reads the perf event again, and calculates the difference, which is the instructions/cycles used by the target program. Example input and output: ./bpftool prog profile id 337 duration 3 cycles instructions llc_misses 4228 run_cnt 3403698 cycles (84.08%) 3525294 instructions # 1.04 insn per cycle (84.05%) 13 llc_misses # 3.69 LLC misses per million isns (83.50%) This command measures cycles and instructions for BPF program with id 337 for 3 seconds. The program has triggered 4228 times. The rest of the output is similar to perf-stat. In this example, the counters were only counting ~84% of the time because of time multiplexing of perf counters. Note that, this approach measures cycles and instructions in very small increments. So the fentry/fexit programs introduce noticeable errors to the measurement results. The fentry/fexit programs are generated with BPF skeletons. Therefore, we build bpftool twice. The first time _bpftool is built without skeletons. Then, _bpftool is used to generate the skeletons. The second time, bpftool is built with skeletons. Signed-off-by: Song Liu Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200309173218.2739965-2-songliubraving@fb.com","tools/bpf/bpftool/Makefile | 18 ++; tools/bpf/bpftool/prog.c | 424 +++++++++++++++++++++++++++++-; tools/bpf/bpftool/skeleton/profiler.bpf.c | 119 +++++++++; tools/bpf/bpftool/skeleton/profiler.h | 47 ++++; tools/scripts/Makefile.include | 1 +; 5 files changed, 608 insertions(+), 1 deletion(-)","The commit introduces a profiling command in bpftool for BPF programs to measure key metrics using hardware counters.","bpftool,profile,program","A new feature. It adds a new capability or feature that was not previously present.","Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['Profile related type programs. It affects programs used for profiling system or application performance.']" +"7b4b73bc8a609fa9655022ed24a7a714bc8c2155","7b4b73bc8a609fa9655022ed24a7a714bc8c2155","Lorenz Bauer","lmb@cloudflare.com","1583752363","Daniel Borkmann","daniel@iogearbox.net","1583789699","b602e9eccdd93c0d880d258dc12b7a222bd875f4","1f441b35ea5453e1dcc00fac03dbd5d7e6cd4f97","bpf, doc: Update maintainers for L7 BPF Add Jakub and myself as maintainers for sockmap related code. Signed-off-by: Lorenz Bauer Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Sitnicki Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200309111243.6982-13-lmb@cloudflare.com","MAINTAINERS | 2 ++; 1 file changed, 2 insertions(+)","The commit updates the MAINTAINERS file to add new maintainers for sockmap related code.","maintainers,sockmap,doc","A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.","It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.","[""It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.""]" +"1f441b35ea5453e1dcc00fac03dbd5d7e6cd4f97","1f441b35ea5453e1dcc00fac03dbd5d7e6cd4f97","Lorenz Bauer","lmb@cloudflare.com","1583752362","Daniel Borkmann","daniel@iogearbox.net","1583789699","ea209b061fd67bd0acc7355ae6664140651b6f26","84be2113e6a7f781bd37c0fd0159899150fdcdfb","selftests: bpf: Enable UDP sockmap reuseport tests Remove the guard that disables UDP tests now that sockmap has support for them. Signed-off-by: Lorenz Bauer Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Sitnicki Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200309111243.6982-12-lmb@cloudflare.com","tools/testing/selftests/bpf/prog_tests/select_reuseport.c | 6 ------; 1 file changed, 6 deletions(-)","Enable UDP sockmap reuseport tests by removing the guard disabling them.","UDP sockmap tests","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"84be2113e6a7f781bd37c0fd0159899150fdcdfb","84be2113e6a7f781bd37c0fd0159899150fdcdfb","Lorenz Bauer","lmb@cloudflare.com","1583752361","Daniel Borkmann","daniel@iogearbox.net","1583789699","5d5cb08c31541eea60026e64e11e8cf8e77bce3a","b05fbb9f03f15134735f9d2dcc7d067092ec9dd2","selftests: bpf: Add tests for UDP sockets in sockmap Expand the TCP sockmap test suite to also check UDP sockets. Signed-off-by: Jakub Sitnicki Signed-off-by: Lorenz Bauer Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200309111243.6982-11-lmb@cloudflare.com",".../selftests/bpf/prog_tests/sockmap_listen.c | 157 +++++++++++++++++----; 1 file changed, 127 insertions(+), 30 deletions(-)","The commit adds UDP socket tests to the existing TCP sockmap test suite.","UDP, tests, sockmap","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"b05fbb9f03f15134735f9d2dcc7d067092ec9dd2","b05fbb9f03f15134735f9d2dcc7d067092ec9dd2","Lorenz Bauer","lmb@cloudflare.com","1583752360","Daniel Borkmann","daniel@iogearbox.net","1583789699","6ea0cbec3f1bb90ef42ff8be10f84338254cc839","7b98cd42b0492237887b62f5ba05931169bcfcf6","selftests: bpf: Don't listen() on UDP sockets Most tests for TCP sockmap can be adapted to UDP sockmap if the listen call is skipped. Rename listen_loopback, etc. to socket_loopback and skip listen() for SOCK_DGRAM. Signed-off-by: Lorenz Bauer Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Sitnicki Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200309111243.6982-10-lmb@cloudflare.com",".../selftests/bpf/prog_tests/sockmap_listen.c | 47 ++++++++++++----------; 1 file changed, 25 insertions(+), 22 deletions(-)","The commit modifies self-tests for BPF to adapt TCP sockmap tests for UDP by skipping the listen call.","selftests,sockmap,UDP","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"7b98cd42b0492237887b62f5ba05931169bcfcf6","7b98cd42b0492237887b62f5ba05931169bcfcf6","Lorenz Bauer","lmb@cloudflare.com","1583752359","Daniel Borkmann","daniel@iogearbox.net","1583789698","f9517ca385503edea277acde13b0ab9f9896fa10","edc6741cc66059532ba621928e3f1b02a53a2f39","bpf: sockmap: Add UDP support Allow adding hashed UDP sockets to sockmaps. Signed-off-by: Lorenz Bauer Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200309111243.6982-9-lmb@cloudflare.com","net/core/sock_map.c | 37 +++++++++++++++++++++++++++++++++----; 1 file changed, 33 insertions(+), 4 deletions(-)","This commit adds UDP socket support to sockmaps in the BPF subsystem.","UDP,sockmap,support","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"edc6741cc66059532ba621928e3f1b02a53a2f39","edc6741cc66059532ba621928e3f1b02a53a2f39","Lorenz Bauer","lmb@cloudflare.com","1583752358","Daniel Borkmann","daniel@iogearbox.net","1583789698","cefa40db3ea5e03a027f2ab6e0299f8e80c6a159","cb21802b39632ba1fa9b31ea134d2079a47600ef","bpf: Add sockmap hooks for UDP sockets Add basic psock hooks for UDP sockets. This allows adding and removing sockets, as well as automatic removal on unhash and close. Signed-off-by: Lorenz Bauer Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200309111243.6982-8-lmb@cloudflare.com","MAINTAINERS | 1 +; include/net/udp.h | 5 +++++; net/ipv4/Makefile | 1 +; net/ipv4/udp_bpf.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++++; 4 files changed, 60 insertions(+)","This commit introduces psock hooks for UDP sockets in the Linux BPF subsystem to manage socket addition and removal.","sockmap,UDP,psock","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"cb21802b39632ba1fa9b31ea134d2079a47600ef","cb21802b39632ba1fa9b31ea134d2079a47600ef","Lorenz Bauer","lmb@cloudflare.com","1583752357","Daniel Borkmann","daniel@iogearbox.net","1583789698","f136611115fda88b630e6b8f3ad0363665eb61a6","f747632b608f90217a4e9ebb1deba8a37612aa32","bpf: sockmap: Simplify sock_map_init_proto We can take advantage of the fact that both callers of sock_map_init_proto are holding a RCU read lock, and have verified that psock is valid. Signed-off-by: Lorenz Bauer Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Sitnicki Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200309111243.6982-7-lmb@cloudflare.com","net/core/sock_map.c | 19 ++++---------------; 1 file changed, 4 insertions(+), 15 deletions(-)","The commit simplifies sock_map initialization by utilizing existing RCU locks and psock checks in the calling functions.","sockmap, simplify, RCU","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"f747632b608f90217a4e9ebb1deba8a37612aa32","f747632b608f90217a4e9ebb1deba8a37612aa32","Lorenz Bauer","lmb@cloudflare.com","1583752356","Daniel Borkmann","daniel@iogearbox.net","1583789698","9cdce568e9a4fe81b8c4eb81513bb9690000e5f4","5da0040442312a2b696748f8240243ce543a4970","bpf: sockmap: Move generic sockmap hooks from BPF TCP The init, close and unhash handlers from TCP sockmap are generic, and can be reused by UDP sockmap. Move the helpers into the sockmap code base and expose them. This requires tcp_bpf_get_proto and tcp_bpf_clone to be conditional on BPF_STREAM_PARSER. The moved functions are unmodified, except that sk_psock_unlink is renamed to sock_map_unlink to better match its behaviour. Signed-off-by: Lorenz Bauer Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Sitnicki Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200309111243.6982-6-lmb@cloudflare.com","include/linux/bpf.h | 4 +-; include/linux/skmsg.h | 28 -------------; include/net/tcp.h | 15 ++++---; net/core/sock_map.c | 106 +++++++++++++++++++++++++++++++++++++++++++++++---; net/ipv4/tcp_bpf.c | 84 +++------------------------------------; 5 files changed, 118 insertions(+), 119 deletions(-)","This commit refactors sockmap hooks to be more generic for both TCP and UDP protocols.","sockmap,TCP,UDP","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime."", ""I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear.""]" +"5da0040442312a2b696748f8240243ce543a4970","5da0040442312a2b696748f8240243ce543a4970","Lorenz Bauer","lmb@cloudflare.com","1583752355","Daniel Borkmann","daniel@iogearbox.net","1583789698","ddfbd323d0b4352ac9fb7711ff61b6f1f421468c","d19da360ee0f3e6c1375391db1a724b66fd43312","bpf: tcp: Guard declarations with CONFIG_NET_SOCK_MSG tcp_bpf.c is only included in the build if CONFIG_NET_SOCK_MSG is selected. The declaration should therefore be guarded as such. Signed-off-by: Lorenz Bauer Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Sitnicki Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200309111243.6982-5-lmb@cloudflare.com","include/net/tcp.h | 4 ++--; 1 file changed, 2 insertions(+), 2 deletions(-)","The commit adds CONFIG_NET_SOCK_MSG guards to tcp_bpf.c declarations for correct building conditions.","CONFIG_NET_SOCK_MSG, tcp_bpf.c, build","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"d19da360ee0f3e6c1375391db1a724b66fd43312","d19da360ee0f3e6c1375391db1a724b66fd43312","Lorenz Bauer","lmb@cloudflare.com","1583752354","Daniel Borkmann","daniel@iogearbox.net","1583789698","b21f3e34ff2a865b68592c282f2148040cde2494","1a2e20132db7bb76dd4f97b8364bd167227dd15f","bpf: tcp: Move assertions into tcp_bpf_get_proto We need to ensure that sk->sk_prot uses certain callbacks, so that code that directly calls e.g. tcp_sendmsg in certain corner cases works. To avoid spurious asserts, we must to do this only if sk_psock_update_proto has not yet been called. The same invariants apply for tcp_bpf_check_v6_needs_rebuild, so move the call as well. Doing so allows us to merge tcp_bpf_init and tcp_bpf_reinit. Signed-off-by: Lorenz Bauer Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Sitnicki Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200309111243.6982-4-lmb@cloudflare.com","include/net/tcp.h | 1 -; net/core/sock_map.c | 25 +++++++++----------------; net/ipv4/tcp_bpf.c | 42 ++++++++++++++++++++++--------------------; 3 files changed, 31 insertions(+), 37 deletions(-)","The commit refactors the placement of assertions within tcp_bpf_get_proto for better callback compatibility and merges related functions for tidiness.","assertions,tcp,merge","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"1a2e20132db7bb76dd4f97b8364bd167227dd15f","1a2e20132db7bb76dd4f97b8364bd167227dd15f","Lorenz Bauer","lmb@cloudflare.com","1583752353","Daniel Borkmann","daniel@iogearbox.net","1583789698","f8428f3a74bf1039a1acb7d63ed6a601eb660461","7b70973d7edb2f005511102d5a2e0116464a46a1","skmsg: Update saved hooks only once Only update psock->saved_* if psock->sk_proto has not been initialized yet. This allows us to get rid of tcp_bpf_reinit_sk_prot. Signed-off-by: Lorenz Bauer Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Sitnicki Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200309111243.6982-3-lmb@cloudflare.com","include/linux/skmsg.h | 20 ++++++++++++++++----; net/ipv4/tcp_bpf.c | 16 +---------------; 2 files changed, 17 insertions(+), 19 deletions(-)","The commit optimizes skmsg initialization logic by only updating saved hooks if the socket protocol is not already set.","skmsg,saved_hooks,socket","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"7b70973d7edb2f005511102d5a2e0116464a46a1","7b70973d7edb2f005511102d5a2e0116464a46a1","Lorenz Bauer","lmb@cloudflare.com","1583752352","Daniel Borkmann","daniel@iogearbox.net","1583789698","ef6bdfbf69c5c495f1f1878eaf5000da0c0afa45","3e7c67d90e3ed2f34fce42699f11b150dd1d3999","bpf: sockmap: Only check ULP for TCP sockets The sock map code checks that a socket does not have an active upper layer protocol before inserting it into the map. This requires casting via inet_csk, which isn't valid for UDP sockets. Guard checks for ULP by checking inet_sk(sk)->is_icsk first. Signed-off-by: Lorenz Bauer Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Sitnicki Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200309111243.6982-2-lmb@cloudflare.com","include/linux/skmsg.h | 8 +++++++-; include/net/inet_connection_sock.h | 6 ++++++; net/core/sock_map.c | 6 ++----; net/ipv4/tcp_ulp.c | 7 -------; 4 files changed, 15 insertions(+), 12 deletions(-)","The commit corrects ULP checks for TCP sockets in sockmap to prevent issues with UDP sockets.","sockmap,ULP,TCP","A bug fix. It primarily resolves a bug or issue in the code.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime."", ""I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear.""]" +"93e5fbb18cec70b3b5c614f67b65388829113bdd","93e5fbb18cec70b3b5c614f67b65388829113bdd","Luke Nelson","lukenels@cs.washington.edu","1583451853","Daniel Borkmann","daniel@iogearbox.net","1583500659","a9b5fbfd1959ae5818079c25d33d3dd89cba4cf6","80f1f85036355e5581ec0b99913410345ad3491b","selftests: bpf: Add test for JMP32 JSET BPF_X with upper bits set The existing tests attempt to check that JMP32 JSET ignores the upper bits in the operand registers. However, the tests missed one such bug in the x32 JIT that is only uncovered when a previous instruction pollutes the upper 32 bits of the registers. This patch adds a new test case that catches the bug by first executing a 64-bit JSET to pollute the upper 32-bits of the temporary registers, followed by a 32-bit JSET which should ignore the upper 32 bits. Co-developed-by: Xi Wang Signed-off-by: Xi Wang Signed-off-by: Luke Nelson Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200305234416.31597-2-luke.r.nels@gmail.com","tools/testing/selftests/bpf/verifier/jmp32.c | 15 +++++++++++++++; 1 file changed, 15 insertions(+)","Adds a self-test to catch an issue in JMP32 JSET handling with upper bits set in BPF's x32 JIT.","selftests,JMP32,JSET","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"80f1f85036355e5581ec0b99913410345ad3491b","80f1f85036355e5581ec0b99913410345ad3491b","Luke Nelson","lukenels@cs.washington.edu","1583451852","Daniel Borkmann","daniel@iogearbox.net","1583500659","596ca8286ec4352d4d5df575f886ccdabff2e244","849b4d94582a966ecb533448415462846da1f0fa","bpf, x32: Fix bug with JMP32 JSET BPF_X checking upper bits The current x32 BPF JIT is incorrect for JMP32 JSET BPF_X when the upper 32 bits of operand registers are non-zero in certain situations. The problem is in the following code: case BPF_JMP | BPF_JSET | BPF_X: case BPF_JMP32 | BPF_JSET | BPF_X: ... /* and dreg_lo,sreg_lo */ EMIT2(0x23, add_2reg(0xC0, sreg_lo, dreg_lo)); /* and dreg_hi,sreg_hi */ EMIT2(0x23, add_2reg(0xC0, sreg_hi, dreg_hi)); /* or dreg_lo,dreg_hi */ EMIT2(0x09, add_2reg(0xC0, dreg_lo, dreg_hi)); This code checks the upper bits of the operand registers regardless if the BPF instruction is BPF_JMP32 or BPF_JMP64. Registers dreg_hi and dreg_lo are not loaded from the stack for BPF_JMP32, however, they can still be polluted with values from previous instructions. The following BPF program demonstrates the bug. The jset64 instruction loads the temporary registers and performs the jump, since ((u64)r7 & (u64)r8) is non-zero. The jset32 should _not_ be taken, as the lower 32 bits are all zero, however, the current JIT will take the branch due the pollution of temporary registers from the earlier jset64. mov64 r0, 0 ld64 r7, 0x8000000000000000 ld64 r8, 0x8000000000000000 jset64 r7, r8, 1 exit jset32 r7, r8, 1 mov64 r0, 2 exit The expected return value of this program is 2; under the buggy x32 JIT it returns 0. The fix is to skip using the upper 32 bits for jset32 and compare the upper 32 bits for jset64 only. All tests in test_bpf.ko and selftests/bpf/test_verifier continue to pass with this change. We found this bug using our automated verification tool, Serval. Fixes: 69f827eb6e14 (""x32: bpf: implement jitting of JMP32"") Co-developed-by: Xi Wang Signed-off-by: Xi Wang Signed-off-by: Luke Nelson Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200305234416.31597-1-luke.r.nels@gmail.com","arch/x86/net/bpf_jit_comp32.c | 10 ++++++----; 1 file changed, 6 insertions(+), 4 deletions(-)","The commit fixes a bug in the x32 BPF JIT compiler related to upper bits checking in JMP32 JSET BPF_X instructions.","bug,JMP32,JIT","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"3e7c67d90e3ed2f34fce42699f11b150dd1d3999","3e7c67d90e3ed2f34fce42699f11b150dd1d3999","KP Singh","kpsingh@google.com","1583445687","Alexei Starovoitov","ast@kernel.org","1583450098","a0c66b42f9fbcf54ce17127cf87662379593829d","69191754ff299a64575003d9e2a79db190d27115","bpf: Fix bpf_prog_test_run_tracing for !CONFIG_NET test_run.o is not built when CONFIG_NET is not set and bpf_prog_test_run_tracing being referenced in bpf_trace.o causes the linker error: ld: kernel/trace/bpf_trace.o:(.rodata+0x38): undefined reference to `bpf_prog_test_run_tracing' Add a __weak function in bpf_trace.c to handle this. Fixes: da00d2f117a0 (""bpf: Add test ops for BPF_PROG_TYPE_TRACING"") Signed-off-by: KP Singh Reported-by: Randy Dunlap Acked-by: Randy Dunlap Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200305220127.29109-1-kpsingh@chromium.org","kernel/trace/bpf_trace.c | 7 +++++++; 1 file changed, 7 insertions(+)","Fixes a linker error by adding a weak function in bpf_trace.c for non-NET configurations.","linker,error,function","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.']" +"69191754ff299a64575003d9e2a79db190d27115","69191754ff299a64575003d9e2a79db190d27115","KP Singh","kpsingh@google.com","1583441395","Alexei Starovoitov","ast@kernel.org","1583447242","7eca4e53a82b517dba3d314bdbacbd1e4e44f160","dad737c926b5b286b9c91abbda66811a8a6618e9","bpf: Remove unnecessary CAP_MAC_ADMIN check While well intentioned, checking CAP_MAC_ADMIN for attaching BPF_MODIFY_RETURN tracing programs to ""security_"" functions is not necessary as tracing BPF programs already require CAP_SYS_ADMIN. Fixes: 6ba43b761c41 (""bpf: Attachment verification for BPF_MODIFY_RETURN"") Signed-off-by: KP Singh Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200305204955.31123-1-kpsingh@chromium.org","kernel/bpf/verifier.c | 13 +++----------; 1 file changed, 3 insertions(+), 10 deletions(-)","The commit removes an unnecessary CAP_MAC_ADMIN check for BPF_MODIFY_RETURN programs, relying instead on the existing CAP_SYS_ADMIN requirement.","CAP_MAC_ADMIN,CAP_SYS_ADMIN,BPF_MODIFY_RETURN","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.']" +"849b4d94582a966ecb533448415462846da1f0fa","849b4d94582a966ecb533448415462846da1f0fa","Martin KaFai Lau","kafai@fb.com","1583372094","Alexei Starovoitov","ast@kernel.org","1583446549","05c047714baaed5bea5da823c7d391ea3f00185b","8e5290e710f4ffe8e9f8813e2ed0397a94d7b2f1","bpf: Do not allow map_freeze in struct_ops map struct_ops map cannot support map_freeze. Otherwise, a struct_ops cannot be unregistered from the subsystem. Fixes: 85d33df357b6 (""bpf: Introduce BPF_MAP_TYPE_STRUCT_OPS"") Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200305013454.535397-1-kafai@fb.com","kernel/bpf/syscall.c | 5 +++++; 1 file changed, 5 insertions(+)","The commit fixes a bug that prevents the freezing of maps in struct_ops to allow proper unregistration from subsystems.","map_freeze, struct_ops, subsystem","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","['Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems.']" +"8e5290e710f4ffe8e9f8813e2ed0397a94d7b2f1","8e5290e710f4ffe8e9f8813e2ed0397a94d7b2f1","Martin KaFai Lau","kafai@fb.com","1583372087","Alexei Starovoitov","ast@kernel.org","1583446548","62f38b9dceaca7363c23fa392c3dedf95b34939e","a35a76faad53429b52a8937b69fdeee5b4e5f935","bpf: Return better error value in delete_elem for struct_ops map The current always succeed behavior in bpf_struct_ops_map_delete_elem() is not ideal for userspace tool. It can be improved to return proper error value. If it is in TOBEFREE, it means unregistration has been already done before but it is in progress and waiting for the subsystem to clear the refcnt to zero, so -EINPROGRESS. If it is INIT, it means the struct_ops has not been registered yet, so -ENOENT. Fixes: 85d33df357b6 (""bpf: Introduce BPF_MAP_TYPE_STRUCT_OPS"") Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200305013447.535326-1-kafai@fb.com","kernel/bpf/bpf_struct_ops.c | 14 +++++++++++---; 1 file changed, 11 insertions(+), 3 deletions(-)","This commit improves error handling in bpf_struct_ops_map_delete_elem by returning specific error values for different states.","error,struct_ops,delete_elem","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"a35a76faad53429b52a8937b69fdeee5b4e5f935","a35a76faad53429b52a8937b69fdeee5b4e5f935","Alexei Starovoitov","ast@kernel.org","1583445553","Alexei Starovoitov","ast@kernel.org","1583446162","92d864323c3302206195a100bc8cc17e4d2530da","52e7c083b417417bb4352ebf3a6409988b6af238 c4ef2f3256e3bc008f98121cad39ee5467db07a6","Merge branch 'fix_bpf_send_signal' Yonghong Song says: ==================== Commit 8b401f9ed244 (""bpf: implement bpf_send_signal() helper"") introduced bpf_send_signal() helper and Commit 8482941f0906 (""bpf: Add bpf_send_signal_thread() helper"") added bpf_send_signal_thread() helper. Both helpers try to send a signel to current process or thread. When bpf_prog is called with scheduler rq_lock held, a deadlock could happen since bpf_send_signal() and bpf_send_signal_thread() will call group_send_sig_info() which may ultimately want to acquire rq_lock() again. This happens in 5.2 and 4.16 based kernels in our production environment with perf_sw_event. In a different scenario, the following is also possible in the last kernel: cpu 1: do_task_stat <- holding sighand->siglock ... task_sched_runtime <- trying to grab rq_lock cpu 2: __schedule <- holding rq_lock ... do_send_sig_info <- trying to grab sighand->siglock Commit eac9153f2b58 (""bpf/stackmap: Fix deadlock with rq_lock in bpf_get_stack()"") has a similar issue with above rq_lock() deadlock. This patch set addressed the issue in a similar way. Patch #1 provided kernel solution and Patch #2 added a selftest. Changelogs: v2 -> v3: . simplify selftest send_signal_sched_switch(). The previous version has mmap/munmap inherited from Song's reproducer. They are not necessary in this context. v1 -> v2: . previous fix using task_work in nmi() is incorrect. there is no nmi() involvement here. Using task_work in all cases might be a solution. But decided to use a similar fix as in Commit eac9153f2b58. ==================== Signed-off-by: Alexei Starovoitov ","","This commit merges fixes for a deadlock issue with bpf_send_signal() and bpf_send_signal_thread() helpers affecting rq_lock in kernel scheduling.","deadlock,bpf_send_signal,rq_lock","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"c4ef2f3256e3bc008f98121cad39ee5467db07a6","c4ef2f3256e3bc008f98121cad39ee5467db07a6","Yonghong Song","yhs@fb.com","1583349065","Alexei Starovoitov","ast@kernel.org","1583445761","92d864323c3302206195a100bc8cc17e4d2530da","1bc7896e9ef44fd77858b3ef0b8a6840be3a4494","selftests/bpf: Add send_signal_sched_switch test Added one test, send_signal_sched_switch, to test bpf_send_signal() helper triggered by sched/sched_switch tracepoint. This test can be used to verify kernel deadlocks fixed by the previous commit. The test itself is heavily borrowed from Commit eac9153f2b58 (""bpf/stackmap: Fix deadlock with rq_lock in bpf_get_stack()""). Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Cc: Song Liu Link: https://lore.kernel.org/bpf/20200304191105.2796601-1-yhs@fb.com",".../bpf/prog_tests/send_signal_sched_switch.c | 60 ++++++++++++++++++++++; .../selftests/bpf/progs/test_send_signal_kern.c | 6 +++; 2 files changed, 66 insertions(+)","This commit introduces a new selftest for the bpf_send_signal() helper using the sched/sched_switch tracepoint.","selftests bpf tracepoint","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.']" +"1bc7896e9ef44fd77858b3ef0b8a6840be3a4494","1bc7896e9ef44fd77858b3ef0b8a6840be3a4494","Yonghong Song","yhs@fb.com","1583349064","Alexei Starovoitov","ast@kernel.org","1583445742","8bab21e6bcf78a3a7b7a7a17a6919ce3ea924bd3","52e7c083b417417bb4352ebf3a6409988b6af238","bpf: Fix deadlock with rq_lock in bpf_send_signal() When experimenting with bpf_send_signal() helper in our production environment (5.2 based), we experienced a deadlock in NMI mode: #5 [ffffc9002219f770] queued_spin_lock_slowpath at ffffffff8110be24 #6 [ffffc9002219f770] _raw_spin_lock_irqsave at ffffffff81a43012 #7 [ffffc9002219f780] try_to_wake_up at ffffffff810e7ecd #8 [ffffc9002219f7e0] signal_wake_up_state at ffffffff810c7b55 #9 [ffffc9002219f7f0] __send_signal at ffffffff810c8602 #10 [ffffc9002219f830] do_send_sig_info at ffffffff810ca31a #11 [ffffc9002219f868] bpf_send_signal at ffffffff8119d227 #12 [ffffc9002219f988] bpf_overflow_handler at ffffffff811d4140 #13 [ffffc9002219f9e0] __perf_event_overflow at ffffffff811d68cf #14 [ffffc9002219fa10] perf_swevent_overflow at ffffffff811d6a09 #15 [ffffc9002219fa38] ___perf_sw_event at ffffffff811e0f47 #16 [ffffc9002219fc30] __schedule at ffffffff81a3e04d #17 [ffffc9002219fc90] schedule at ffffffff81a3e219 #18 [ffffc9002219fca0] futex_wait_queue_me at ffffffff8113d1b9 #19 [ffffc9002219fcd8] futex_wait at ffffffff8113e529 #20 [ffffc9002219fdf0] do_futex at ffffffff8113ffbc #21 [ffffc9002219fec0] __x64_sys_futex at ffffffff81140d1c #22 [ffffc9002219ff38] do_syscall_64 at ffffffff81002602 #23 [ffffc9002219ff50] entry_SYSCALL_64_after_hwframe at ffffffff81c00068 The above call stack is actually very similar to an issue reported by Commit eac9153f2b58 (""bpf/stackmap: Fix deadlock with rq_lock in bpf_get_stack()"") by Song Liu. The only difference is bpf_send_signal() helper instead of bpf_get_stack() helper. The above deadlock is triggered with a perf_sw_event. Similar to Commit eac9153f2b58, the below almost identical reproducer used tracepoint point sched/sched_switch so the issue can be easily caught. /* stress_test.c */ #include #include #include #include #include #include #include #define THREAD_COUNT 1000 char *filename; void *worker(void *p) { void *ptr; int fd; char *pptr; fd = open(filename, O_RDONLY); if (fd < 0) return NULL; while (1) { struct timespec ts = {0, 1000 + rand() % 2000}; ptr = mmap(NULL, 4096 * 64, PROT_READ, MAP_PRIVATE, fd, 0); usleep(1); if (ptr == MAP_FAILED) { printf(""failed to mmap\n""); break; } munmap(ptr, 4096 * 64); usleep(1); pptr = malloc(1); usleep(1); pptr[0] = 1; usleep(1); free(pptr); usleep(1); nanosleep(&ts, NULL); } close(fd); return NULL; } int main(int argc, char *argv[]) { void *ptr; int i; pthread_t threads[THREAD_COUNT]; if (argc < 2) return 0; filename = argv[1]; for (i = 0; i < THREAD_COUNT; i++) { if (pthread_create(threads + i, NULL, worker, NULL)) { fprintf(stderr, ""Error creating thread\n""); return 0; } } for (i = 0; i < THREAD_COUNT; i++) pthread_join(threads[i], NULL); return 0; } and the following command: 1. run `stress_test /bin/ls` in one windown 2. hack bcc trace.py with the following change: --- a/tools/trace.py +++ b/tools/trace.py @@ -513,6 +513,7 @@ BPF_PERF_OUTPUT(%s); __data.tgid = __tgid; __data.pid = __pid; bpf_get_current_comm(&__data.comm, sizeof(__data.comm)); + bpf_send_signal(10); %s %s %s.perf_submit(%s, &__data, sizeof(__data)); 3. in a different window run ./trace.py -p $(pidof stress_test) t:sched:sched_switch The deadlock can be reproduced in our production system. Similar to Song's fix, the fix is to delay sending signal if irqs is disabled to avoid deadlocks involving with rq_lock. With this change, my above stress-test in our production system won't cause deadlock any more. I also implemented a scale-down version of reproducer in the selftest (a subsequent commit). With latest bpf-next, it complains for the following potential deadlock. [ 32.832450] -> #1 (&p->pi_lock){-.-.}: [ 32.833100] _raw_spin_lock_irqsave+0x44/0x80 [ 32.833696] task_rq_lock+0x2c/0xa0 [ 32.834182] task_sched_runtime+0x59/0xd0 [ 32.834721] thread_group_cputime+0x250/0x270 [ 32.835304] thread_group_cputime_adjusted+0x2e/0x70 [ 32.835959] do_task_stat+0x8a7/0xb80 [ 32.836461] proc_single_show+0x51/0xb0 ... [ 32.839512] -> #0 (&(&sighand->siglock)->rlock){....}: [ 32.840275] __lock_acquire+0x1358/0x1a20 [ 32.840826] lock_acquire+0xc7/0x1d0 [ 32.841309] _raw_spin_lock_irqsave+0x44/0x80 [ 32.841916] __lock_task_sighand+0x79/0x160 [ 32.842465] do_send_sig_info+0x35/0x90 [ 32.842977] bpf_send_signal+0xa/0x10 [ 32.843464] bpf_prog_bc13ed9e4d3163e3_send_signal_tp_sched+0x465/0x1000 [ 32.844301] trace_call_bpf+0x115/0x270 [ 32.844809] perf_trace_run_bpf_submit+0x4a/0xc0 [ 32.845411] perf_trace_sched_switch+0x10f/0x180 [ 32.846014] __schedule+0x45d/0x880 [ 32.846483] schedule+0x5f/0xd0 ... [ 32.853148] Chain exists of: [ 32.853148] &(&sighand->siglock)->rlock --> &p->pi_lock --> &rq->lock [ 32.853148] [ 32.854451] Possible unsafe locking scenario: [ 32.854451] [ 32.855173] CPU0 CPU1 [ 32.855745] ---- ---- [ 32.856278] lock(&rq->lock); [ 32.856671] lock(&p->pi_lock); [ 32.857332] lock(&rq->lock); [ 32.857999] lock(&(&sighand->siglock)->rlock); Deadlock happens on CPU0 when it tries to acquire &sighand->siglock but it has been held by CPU1 and CPU1 tries to grab &rq->lock and cannot get it. This is not exactly the callstack in our production environment, but sympotom is similar and both locks are using spin_lock_irqsave() to acquire the lock, and both involves rq_lock. The fix to delay sending signal when irq is disabled also fixed this issue. Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Cc: Song Liu Link: https://lore.kernel.org/bpf/20200304191104.2796501-1-yhs@fb.com","kernel/trace/bpf_trace.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","Fixes a deadlock issue in bpf_send_signal() by delaying signal sending when IRQs are disabled in eBPF trace helper.","deadlock,bpf_send_signal,trace","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.', 'kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"af33d2433b03d63ed31fcfda842f46676a5e1afc","af33d2433b03d63ed31fcfda842f46676a5e1afc","Tycho Andersen","tycho@tycho.ws","1581175097","Palmer Dabbelt","palmerdabbelt@google.com","1583445495","4aae7642246944934b2a73377eac670fd38994be","0a91330b2af9f71ceeeed483f92774182b58f6d9","riscv: fix seccomp reject syscall code path If secure_computing() rejected a system call, we were previously setting the system call number to -1, to indicate to later code that the syscall failed. However, if something (e.g. a user notification) was sleeping, and received a signal, we may set a0 to -ERESTARTSYS and re-try the system call again. In this case, seccomp ""denies"" the syscall (because of the signal), and we would set a7 to -1, thus losing the value of the system call we want to restart. Instead, let's return -1 from do_syscall_trace_enter() to indicate that the syscall was rejected, so we don't clobber the value in case of -ERESTARTSYS or whatever. This commit fixes the user_notification_signal seccomp selftest on riscv to no longer hang. That test expects the system call to be re-issued after the signal, and it wasn't due to the above bug. Now that it is, everything works normally. Note that in the ptrace (tracer) case, the tracer can set the register values to whatever they want, so we still need to keep the code that handles out-of-bounds syscalls. However, we can drop the comment. We can also drop syscall_set_nr(), since it is no longer used anywhere, and the code that re-loads the value in a7 because of it. Reported in: https://lore.kernel.org/bpf/CAEn-LTp=ss0Dfv6J00=rCAy+N78U2AmhqJNjfqjr2FDpPYjxEQ@mail.gmail.com/ Reported-by: David Abdurachmanov Signed-off-by: Tycho Andersen Reviewed-by: Kees Cook Signed-off-by: Palmer Dabbelt ","arch/riscv/include/asm/syscall.h | 7 -------; arch/riscv/kernel/entry.S | 11 +++--------; arch/riscv/kernel/ptrace.c | 11 +++++------; 3 files changed, 8 insertions(+), 21 deletions(-)","Fixes seccomp syscall rejection handling on RISC-V architecture to prevent missing retries on signals.","seccomp,RISC-V,syscall","A bug fix. It primarily resolves a bug or issue in the code.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.","It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.","[""It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.""]" +"52e7c083b417417bb4352ebf3a6409988b6af238","52e7c083b417417bb4352ebf3a6409988b6af238","Quentin Monnet","quentin@isovalent.com","1582737233","Alexei Starovoitov","ast@kernel.org","1583434989","a0ed645303215b160e2f04c73230fa4a0d422d2e","209c65b61d94344522c41a83cd6ce51aac5fd0a4","mailmap: Update email address My Netronome address is no longer active. I am no maintainer, but get_maintainer.pl sometimes returns my name for a small number of files (BPF-related). Add an entry to .mailmap for good measure. Signed-off-by: Quentin Monnet Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200226171353.18982-1-quentin@isovalent.com Signed-off-by: Alexei Starovoitov ",".mailmap | 1 +; 1 file changed, 1 insertion(+)","Update .mailmap for author's email change to maintain BPF-related file references.","mailmap,email,BPF","A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.","It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.","[""It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.""]" +"dad737c926b5b286b9c91abbda66811a8a6618e9","dad737c926b5b286b9c91abbda66811a8a6618e9","Luke Nelson","lukenels@cs.washington.edu","1583384527","Daniel Borkmann","daniel@iogearbox.net","1583421327","da3b9b4fed4b6bc9a8758c8c8f4a60f08ea5d813","06b741521622331eb01b67123e8cdda6ca8be187","MAINTAINERS: Add entry for RV32G BPF JIT Add a new entry for the 32-bit RISC-V JIT to MAINTAINERS and change mailing list to netdev and bpf following the guidelines from commit e42da4c62abb (""docs/bpf: Update bpf development Q/A file""). Signed-off-by: Xi Wang Signed-off-by: Luke Nelson Signed-off-by: Daniel Borkmann Reviewed-by: Björn Töpel Acked-by: Björn Töpel Link: https://lore.kernel.org/bpf/20200305050207.4159-5-luke.r.nels@gmail.com","MAINTAINERS | 13 ++++++++++++-; 1 file changed, 12 insertions(+), 1 deletion(-)","Adds a 32-bit RISC-V JIT entry to the MAINTAINERS file and updates mailing list instructions.","MAINTAINERS,RV32G,JIT","A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","I'm not sure about the logic component of the commit. The affected logic component is unclear.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"06b741521622331eb01b67123e8cdda6ca8be187","06b741521622331eb01b67123e8cdda6ca8be187","Luke Nelson","lukenels@cs.washington.edu","1583384526","Daniel Borkmann","daniel@iogearbox.net","1583421227","a6b4e4b53ca26ae27f674ac701f13c30609d21d9","5f316b65e99f109942c556dc8790abd4c75bcb34","bpf, doc: Add BPF JIT for RV32G to BPF documentation Update filter.txt and admin-guide to mention the BPF JIT for RV32G. Co-developed-by: Xi Wang Signed-off-by: Xi Wang Signed-off-by: Luke Nelson Signed-off-by: Daniel Borkmann Reviewed-by: Björn Töpel Acked-by: Björn Töpel Link: https://lore.kernel.org/bpf/20200305050207.4159-4-luke.r.nels@gmail.com","Documentation/admin-guide/sysctl/net.rst | 3 ++-; Documentation/networking/filter.txt | 2 +-; 2 files changed, 3 insertions(+), 2 deletions(-)","This commit updates documentation to include the BPF JIT for RV32G.","BPF,documentation,JIT","A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"5f316b65e99f109942c556dc8790abd4c75bcb34","5f316b65e99f109942c556dc8790abd4c75bcb34","Luke Nelson","lukenels@cs.washington.edu","1583384525","Daniel Borkmann","daniel@iogearbox.net","1583421227","8c914f9bc6bd05a85ad4e16332f049f0a3dd5fdc","ca6cb5447ceca6a87d6b62c9e5d41042c34f7ffa","riscv, bpf: Add RV32G eBPF JIT This is an eBPF JIT for RV32G, adapted from the JIT for RV64G and the 32-bit ARM JIT. There are two main changes required for this to work compared to the RV64 JIT. First, eBPF registers are 64-bit, while RV32G registers are 32-bit. BPF registers either map directly to 2 RISC-V registers, or reside in stack scratch space and are saved and restored when used. Second, many 64-bit ALU operations do not trivially map to 32-bit operations. Operations that move bits between high and low words, such as ADD, LSH, MUL, and others must emulate the 64-bit behavior in terms of 32-bit instructions. This patch also makes related changes to bpf_jit.h, such as adding RISC-V instructions required by the RV32 JIT. Supported features: The RV32 JIT supports the same features and instructions as the RV64 JIT, with the following exceptions: - ALU64 DIV/MOD: Requires loops to implement on 32-bit hardware. - BPF_XADD | BPF_DW: There's no 8-byte atomic instruction in RV32. These features are also unsupported on other BPF JITs for 32-bit architectures. Testing: - lib/test_bpf.c test_bpf: Summary: 378 PASSED, 0 FAILED, [349/366 JIT'ed] test_bpf: test_skb_segment: Summary: 2 PASSED, 0 FAILED The tests that are not JITed are all due to use of 64-bit div/mod or 64-bit xadd. - tools/testing/selftests/bpf/test_verifier.c Summary: 1415 PASSED, 122 SKIPPED, 43 FAILED Tested both with and without BPF JIT hardening. This is the same set of tests that pass using the BPF interpreter with the JIT disabled. Verification and synthesis: We developed the RV32 JIT using our automated verification tool, Serval. We have used Serval in the past to verify patches to the RV64 JIT. We also used Serval to superoptimize the resulting code through program synthesis. You can find the tool and a guide to the approach and results here: https://github.com/uw-unsat/serval-bpf/tree/rv32-jit-v5 Co-developed-by: Xi Wang Signed-off-by: Xi Wang Signed-off-by: Luke Nelson Signed-off-by: Daniel Borkmann Reviewed-by: Björn Töpel Acked-by: Björn Töpel Link: https://lore.kernel.org/bpf/20200305050207.4159-3-luke.r.nels@gmail.com","arch/riscv/Kconfig | 2 +-; arch/riscv/net/Makefile | 8 +-; arch/riscv/net/bpf_jit.h | 48 ++; arch/riscv/net/bpf_jit_comp32.c | 1310 +++++++++++++++++++++++++++++++++++++++; 4 files changed, 1366 insertions(+), 2 deletions(-)","Add an eBPF JIT for RISC-V RV32G architecture with adaptations from RV64G and ARM JIT implementations.","eBPF JIT,RV32G,RISC-V","A new feature. It adds a new capability or feature that was not previously present.","Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"ca6cb5447ceca6a87d6b62c9e5d41042c34f7ffa","ca6cb5447ceca6a87d6b62c9e5d41042c34f7ffa","Luke Nelson","lukenels@cs.washington.edu","1583384524","Daniel Borkmann","daniel@iogearbox.net","1583421227","85a27cd2f9fcdaa06a2d508bba75d91539bad684","9ce6010290587f4b0c57e2819481bd5ba9668349","riscv, bpf: Factor common RISC-V JIT code This patch factors out code that can be used by both the RV64 and RV32 BPF JITs to a common bpf_jit.h and bpf_jit_core.c. Move struct definitions and macro-like functions to header. Rename rv_sb_insn/rv_uj_insn to rv_b_insn/rv_j_insn to match the RISC-V specification. Move reusable functions emit_body() and bpf_int_jit_compile() to bpf_jit_core.c with minor simplifications. Rename emit_insn() and build_{prologue,epilogue}() to be prefixed with ""bpf_jit_"" as they are no longer static. Rename bpf_jit_comp.c to bpf_jit_comp64.c to be more explicit. Co-developed-by: Xi Wang Signed-off-by: Xi Wang Signed-off-by: Luke Nelson Signed-off-by: Daniel Borkmann Reviewed-by: Björn Töpel Acked-by: Björn Töpel Link: https://lore.kernel.org/bpf/20200305050207.4159-2-luke.r.nels@gmail.com","arch/riscv/net/Makefile | 3 +-; arch/riscv/net/bpf_jit.h | 466 +++++++++++; arch/riscv/net/bpf_jit_comp.c | 1698 ---------------------------------------; arch/riscv/net/bpf_jit_comp64.c | 1103 +++++++++++++++++++++++++; arch/riscv/net/bpf_jit_core.c | 166 ++++; 5 files changed, 1737 insertions(+), 1699 deletions(-)","The commit refactors and consolidates common RISC-V BPF JIT code into shared files for RV64 and RV32 architectures.","RISC-V,JIT,refactor","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"9ce6010290587f4b0c57e2819481bd5ba9668349","9ce6010290587f4b0c57e2819481bd5ba9668349","Alexei Starovoitov","ast@kernel.org","1583358066","Alexei Starovoitov","ast@kernel.org","1583358436","7e9836d1926fce0e65362a47474fed446ea75f8c","cc6fa771024ffdb428bdf25a94309cf21e8ef1b9 3d08b6f29cf33aeaf301553d8d3805f0aa609df7","Merge branch 'bpf_modify_ret' KP Singh says: ==================== v3 -> v4: * Fix a memory leak noticed by Daniel. v2 -> v3: * bpf_trampoline_update_progs -> bpf_trampoline_get_progs + const qualification. * Typos in commit messages. * Added Andrii's Acks. v1 -> v2: * Adressed Andrii's feedback. * Fixed a bug that Alexei noticed about nop generation. * Rebase. This was brought up in the KRSI v4 discussion and found to be useful both for security and tracing programs. https://lore.kernel.org/bpf/20200225193108.GB22391@chromium.org/ The modify_return programs are allowed for security hooks (with an extra CAP_MAC_ADMIN check) and functions whitelisted for error injection (ALLOW_ERROR_INJECTION). The ""security_"" check is expected to be cleaned up with the KRSI patch series. Here is an example of how a fmod_ret program behaves: int func_to_be_attached(int a, int b) { <--- do_fentry do_fmod_ret: if (ret != 0) goto do_fexit; original_function: } <--- do_fexit ALLOW_ERROR_INJECTION(func_to_be_attached, ERRNO) The fmod_ret program attached to this function can be defined as: SEC(""fmod_ret/func_to_be_attached"") int BPF_PROG(func_name, int a, int b, int ret) { // This will skip the original function logic. return -1; } ==================== Signed-off-by: Alexei Starovoitov ","","This commit merges changes for security and tracing programs focused on function return modifications and error injections in eBPF.","security, tracing, merge","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","['LSM type related programs. It relates to eBPF programs used with Linux Security Modules (LSMs) for security enhancements.', 'Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.', ""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"3d08b6f29cf33aeaf301553d8d3805f0aa609df7","3d08b6f29cf33aeaf301553d8d3805f0aa609df7","KP Singh","kpsingh@google.com","1583349533","Alexei Starovoitov","ast@kernel.org","1583358066","7e9836d1926fce0e65362a47474fed446ea75f8c","da00d2f117a08fbca262db5ea422c80a568b112b","bpf: Add selftests for BPF_MODIFY_RETURN Test for two scenarios: * When the fmod_ret program returns 0, the original function should be called along with fentry and fexit programs. * When the fmod_ret program returns a non-zero value, the original function should not be called, no side effect should be observed and fentry and fexit programs should be called. The result from the kernel function call and whether a side-effect is observed is returned via the retval attr of the BPF_PROG_TEST_RUN (bpf) syscall. Signed-off-by: KP Singh Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Acked-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200304191853.1529-8-kpsingh@chromium.org","net/bpf/test_run.c | 22 +++++++-; .../selftests/bpf/prog_tests/modify_return.c | 65 ++++++++++++++++++++++; tools/testing/selftests/bpf/progs/modify_return.c | 49 ++++++++++++++++; 3 files changed, 135 insertions(+), 1 deletion(-)","This commit adds self-tests for BPF_MODIFY_RETURN to verify correct behavior of fmod_ret programs in different scenarios.","selftests,BPF_MODIFY_RETURN,fmod_ret","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"da00d2f117a08fbca262db5ea422c80a568b112b","da00d2f117a08fbca262db5ea422c80a568b112b","KP Singh","kpsingh@google.com","1583349532","Alexei Starovoitov","ast@kernel.org","1583358066","81519be4eb8e8c8b69ca88d834f79aae9f925db8","aca228cd3387447d99d3ebaee3ebcc2b015a3e46","bpf: Add test ops for BPF_PROG_TYPE_TRACING The current fexit and fentry tests rely on a different program to exercise the functions they attach to. Instead of doing this, implement the test operations for tracing which will also be used for BPF_MODIFY_RETURN in a subsequent patch. Also, clean up the fexit test to use the generated skeleton. Signed-off-by: KP Singh Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Acked-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200304191853.1529-7-kpsingh@chromium.org","include/linux/bpf.h | 10 ++++; kernel/trace/bpf_trace.c | 1 +; net/bpf/test_run.c | 37 +++++++++---; .../selftests/bpf/prog_tests/fentry_fexit.c | 12 +---; .../testing/selftests/bpf/prog_tests/fentry_test.c | 14 ++---; .../testing/selftests/bpf/prog_tests/fexit_test.c | 69 +++++++---------------; 6 files changed, 67 insertions(+), 76 deletions(-)","Add test operations for BPF_PROG_TYPE_TRACING and clean up existing fexit and fentry tests.","test, tracing, fexit","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"aca228cd3387447d99d3ebaee3ebcc2b015a3e46","aca228cd3387447d99d3ebaee3ebcc2b015a3e46","KP Singh","kpsingh@google.com","1583349531","Alexei Starovoitov","ast@kernel.org","1583358065","503f9b1ed65eb5b0d797c0e7858e6d718730492a","6ba43b761c41349140662e223401bec0e48950e7","tools/libbpf: Add support for BPF_MODIFY_RETURN Signed-off-by: KP Singh Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Acked-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200304191853.1529-6-kpsingh@chromium.org","tools/lib/bpf/libbpf.c | 4 ++++; 1 file changed, 4 insertions(+)","The commit adds support for BPF_MODIFY_RETURN in the libbpf library.","libbpf,BPF_MODIFY_RETURN,support","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"6ba43b761c41349140662e223401bec0e48950e7","6ba43b761c41349140662e223401bec0e48950e7","KP Singh","kpsingh@google.com","1583349530","Alexei Starovoitov","ast@kernel.org","1583358065","7967b279148889ace27e59721f4300fa5ee8f268","ae24082331d9bbaae283aafbe930a8f0eb85605a","bpf: Attachment verification for BPF_MODIFY_RETURN - Allow BPF_MODIFY_RETURN attachment only to functions that are: * Whitelisted for error injection by checking within_error_injection_list. Similar discussions happened for the bpf_override_return helper. * security hooks, this is expected to be cleaned up with the LSM changes after the KRSI patches introduce the LSM_HOOK macro: https://lore.kernel.org/bpf/20200220175250.10795-1-kpsingh@chromium.org/ - The attachment is currently limited to functions that return an int. This can be extended later other types (e.g. PTR). Signed-off-by: KP Singh Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Acked-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200304191853.1529-5-kpsingh@chromium.org","kernel/bpf/btf.c | 28 ++++++++++++++++++++--------; kernel/bpf/verifier.c | 31 +++++++++++++++++++++++++++++++; 2 files changed, 51 insertions(+), 8 deletions(-)","The commit adds validation for BPF_MODIFY_RETURN attachments, restricting them to whitelisted functions or security hooks.","BPF_MODIFY_RETURN, validation, hooks","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['LSM type related programs. It relates to eBPF programs used with Linux Security Modules (LSMs) for security enhancements.']" +"ae24082331d9bbaae283aafbe930a8f0eb85605a","ae24082331d9bbaae283aafbe930a8f0eb85605a","KP Singh","kpsingh@google.com","1583349529","Alexei Starovoitov","ast@kernel.org","1583358065","606f33bff29d3661e0a72921237c74162daabeb8","7e639208e88d60abf83d48dfda4c0ad325a77b58","bpf: Introduce BPF_MODIFY_RETURN When multiple programs are attached, each program receives the return value from the previous program on the stack and the last program provides the return value to the attached function. The fmod_ret bpf programs are run after the fentry programs and before the fexit programs. The original function is only called if all the fmod_ret programs return 0 to avoid any unintended side-effects. The success value, i.e. 0 is not currently configurable but can be made so where user-space can specify it at load time. For example: int func_to_be_attached(int a, int b) { <--- do_fentry do_fmod_ret: if (ret != 0) goto do_fexit; original_function: } <--- do_fexit The fmod_ret program attached to this function can be defined as: SEC(""fmod_ret/func_to_be_attached"") int BPF_PROG(func_name, int a, int b, int ret) { // This will skip the original function logic. return 1; } The first fmod_ret program is passed 0 in its return argument. Signed-off-by: KP Singh Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Acked-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200304191853.1529-4-kpsingh@chromium.org","arch/x86/net/bpf_jit_comp.c | 130 +++++++++++++++++++++++++++++++++++++----; include/linux/bpf.h | 1 +; include/uapi/linux/bpf.h | 1 +; kernel/bpf/btf.c | 3 +-; kernel/bpf/syscall.c | 1 +; kernel/bpf/trampoline.c | 5 +-; kernel/bpf/verifier.c | 1 +; tools/include/uapi/linux/bpf.h | 1 +; 8 files changed, 130 insertions(+), 13 deletions(-)","Introduces BPF_MODIFY_RETURN feature to control execution of original functions through return values in eBPF programs.","BPF_MODIFY_RETURN,fmod_ret,return","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"7e639208e88d60abf83d48dfda4c0ad325a77b58","7e639208e88d60abf83d48dfda4c0ad325a77b58","KP Singh","kpsingh@google.com","1583349528","Alexei Starovoitov","ast@kernel.org","1583358065","77a39fcd235e0282cd23fb6890d488384540685e","88fd9e5352fe05f7fe57778293aebd4cd106960b","bpf: JIT helpers for fmod_ret progs * Split the invoke_bpf program to prepare for special handling of fmod_ret programs introduced in a subsequent patch. * Move the definition of emit_cond_near_jump and emit_nops as they are needed for fmod_ret. * Refactor branch target alignment into its own generic helper function i.e. emit_align. Signed-off-by: KP Singh Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Acked-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200304191853.1529-3-kpsingh@chromium.org","arch/x86/net/bpf_jit_comp.c | 148 +++++++++++++++++++++++++-------------------; 1 file changed, 85 insertions(+), 63 deletions(-)","Refactor eBPF JIT helpers for improved handling of fmod_ret programs.","JIT,fmod_ret,refactor","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"88fd9e5352fe05f7fe57778293aebd4cd106960b","88fd9e5352fe05f7fe57778293aebd4cd106960b","KP Singh","kpsingh@google.com","1583349527","Alexei Starovoitov","ast@kernel.org","1583358065","a8bc1ce304a0f7e5594666995fe5d3863dbda3e5","cc6fa771024ffdb428bdf25a94309cf21e8ef1b9","bpf: Refactor trampoline update code As we need to introduce a third type of attachment for trampolines, the flattened signature of arch_prepare_bpf_trampoline gets even more complicated. Refactor the prog and count argument to arch_prepare_bpf_trampoline to use bpf_tramp_progs to simplify the addition and accounting for new attachment types. Signed-off-by: KP Singh Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Acked-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200304191853.1529-2-kpsingh@chromium.org","arch/x86/net/bpf_jit_comp.c | 31 ++++++++++++-----------; include/linux/bpf.h | 13 ++++++++--; kernel/bpf/bpf_struct_ops.c | 10 +++++++-; kernel/bpf/trampoline.c | 62 +++++++++++++++++++++++++--------------------; 4 files changed, 71 insertions(+), 45 deletions(-)","Refactor the trampoline code to simplify addition of new attachment types using bpf_tramp_progs.","trampoline, refactor, attachment","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"cc6fa771024ffdb428bdf25a94309cf21e8ef1b9","cc6fa771024ffdb428bdf25a94309cf21e8ef1b9","Andrii Nakryiko","andriin@fb.com","1583347416","Alexei Starovoitov","ast@kernel.org","1583352005","24bb4d39df3788a10cae4429b58ecdff650c199a","af73d78bd384aa9b8789aa6e7ddbb165f971276f","selftests/bpf: Support out-of-tree vmlinux builds for VMLINUX_BTF Add detection of out-of-tree built vmlinux image for the purpose of VMLINUX_BTF detection. According to Documentation/kbuild/kbuild.rst, O takes precedence over KBUILD_OUTPUT. Also ensure ~/path/to/build/dir also works by relying on wildcard's resolution first, but then applying $(abspath) at the end to also handle O=../../whatever cases. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200304184336.165766-1-andriin@fb.com","tools/testing/selftests/bpf/Makefile | 11 +++++++----; 1 file changed, 7 insertions(+), 4 deletions(-)","This commit enhances the VMLINUX_BTF detection logic to support out-of-tree vmlinux builds in eBPF selftests.","vmlinux,VMLINUX_BTF,out-of-tree","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"af73d78bd384aa9b8789aa6e7ddbb165f971276f","af73d78bd384aa9b8789aa6e7ddbb165f971276f","Kees Cook","keescook@chromium.org","1583288314","Daniel Borkmann","daniel@iogearbox.net","1583343393","9fa6615db19920fb595e45cd9abdf69b53ee764f","0641cadac46710bf7f87fa46067194ec1d932d90","kbuild: Remove debug info from kallsyms linking When CONFIG_DEBUG_INFO is enabled, the two kallsyms linking steps spend time collecting and writing the dwarf sections to the temporary output files. kallsyms does not need this information, and leaving it off halves their linking time. This is especially noticeable without CONFIG_DEBUG_INFO_REDUCED. The BTF linking stage, however, does still need those details. Refactor the BTF and kallsyms generation stages slightly for more regularized temporary names. Skip debug during kallsyms links. Additionally move ""info BTF"" to the correct place since commit 8959e39272d6 (""kbuild: Parameterize kallsyms generation and correct reporting""), which added ""info LD ..."" to vmlinux_link calls. For a full debug info build with BTF, my link time goes from 1m06s to 0m54s, saving about 12 seconds, or 18%. Signed-off-by: Kees Cook Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/202003031814.4AEA3351@keescook","scripts/link-vmlinux.sh | 28 +++++++++++++++++++---------; 1 file changed, 19 insertions(+), 9 deletions(-)","The commit optimizes build performance by removing unnecessary debug info during kallsyms linking, reducing link time by 18%.","kallsyms,debug,optimization","A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.","It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.","[""It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.""]" +"0641cadac46710bf7f87fa46067194ec1d932d90","0641cadac46710bf7f87fa46067194ec1d932d90","Daniel Borkmann","daniel@iogearbox.net","1583337606","Daniel Borkmann","daniel@iogearbox.net","1583337610","f226fe625bc79e1ea70a223dac69fdf33e434383","320a36063e1441210106aa33997ad3770d4c86b4 367d82f17eff53cec531920eb0de9973fac89ec1","Merge branch 'bpf-uapi-enums' Andrii Nakryiko says: ==================== Convert BPF-related UAPI constants, currently defined as #define macro, into anonymous enums. This has no difference in terms of usage of such constants in C code (they are still could be used in all the compile-time contexts that `#define`s can), but they are recorded as part of DWARF type info, and subsequently get recorded as part of kernel's BTF type info. This allows those constants to be emitted as part of vmlinux.h auto-generated header file and be used from BPF programs. Which is especially convenient for all kinds of BPF helper flags and makes CO-RE BPF programs nicer to write. libbpf's btf_dump logic currently assumes enum values are signed 32-bit values, but that doesn't match a typical case, so switch it to emit unsigned values. Once BTF encoding of BTF_KIND_ENUM is extended to capture signedness properly, this will be made more flexible. As an immediate validation of the approach, runqslower's copy of BPF_F_CURRENT_CPU #define is dropped in favor of its enum variant from vmlinux.h. v2->v3: - convert only constants usable from BPF programs (BPF helper flags, map create flags, etc) (Alexei); v1->v2: - fix up btf_dump test to use max 32-bit unsigned value instead of negative one. ==================== Signed-off-by: Daniel Borkmann ","","The commit merges changes to convert BPF UAPI constants from macros to enums for better BTF use in BPF programs.","enums,UAPI,BTF","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"367d82f17eff53cec531920eb0de9973fac89ec1","367d82f17eff53cec531920eb0de9973fac89ec1","Andrii Nakryiko","andriin@fb.com","1583195553","Daniel Borkmann","daniel@iogearbox.net","1583337606","f226fe625bc79e1ea70a223dac69fdf33e434383","7cb30aaab3f277aa88e20a008faf57e0fb1119ec","tools/runqslower: Drop copy/pasted BPF_F_CURRENT_CPU definiton With BPF_F_CURRENT_CPU being an enum, it is now captured in vmlinux.h and is readily usable by runqslower. So drop local copy/pasted definition in favor of the one coming from vmlinux.h. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200303003233.3496043-4-andriin@fb.com","tools/bpf/runqslower/runqslower.bpf.c | 3 ---; 1 file changed, 3 deletions(-)","The commit removes a redundant local definition of BPF_F_CURRENT_CPU in runqslower, using vmlinux.h instead.","BPF_F_CURRENT_CPU, runqslower, vmlinux","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"7cb30aaab3f277aa88e20a008faf57e0fb1119ec","7cb30aaab3f277aa88e20a008faf57e0fb1119ec","Andrii Nakryiko","andriin@fb.com","1583195552","Daniel Borkmann","daniel@iogearbox.net","1583337606","6c4b74c76a30b236f29194e04c01d292f171e862","1aae4bdd787998ea331a56f3db9d8595790fe2f9","libbpf: Assume unsigned values for BTF_KIND_ENUM Currently, BTF_KIND_ENUM type doesn't record whether enum values should be interpreted as signed or unsigned. In Linux, most enums are unsigned, though, so interpreting them as unsigned matches real world better. Change btf_dump test case to test maximum 32-bit value, instead of negative value. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200303003233.3496043-3-andriin@fb.com","tools/lib/bpf/btf_dump.c | 8 ++++----; tools/testing/selftests/bpf/progs/btf_dump_test_case_syntax.c | 2 +-; 2 files changed, 5 insertions(+), 5 deletions(-)","Updated libbpf to interpret BTF_KIND_ENUM as unsigned and adjusted test cases accordingly.","unsigned, enums, libbpf","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"1aae4bdd787998ea331a56f3db9d8595790fe2f9","1aae4bdd787998ea331a56f3db9d8595790fe2f9","Andrii Nakryiko","andriin@fb.com","1583195551","Daniel Borkmann","daniel@iogearbox.net","1583337605","a8d1ec71196488587623275fe0e3cda509fde599","320a36063e1441210106aa33997ad3770d4c86b4","bpf: Switch BPF UAPI #define constants used from BPF program side to enums Switch BPF UAPI constants, previously defined as #define macro, to anonymous enum values. This preserves constants values and behavior in expressions, but has added advantaged of being captured as part of DWARF and, subsequently, BTF type info. Which, in turn, greatly improves usefulness of generated vmlinux.h for BPF applications, as it will not require BPF users to copy/paste various flags and constants, which are frequently used with BPF helpers. Only those constants that are used/useful from BPF program side are converted. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200303003233.3496043-2-andriin@fb.com","include/uapi/linux/bpf.h | 175 +++++++++++++++++++++++++---------------; tools/include/uapi/linux/bpf.h | 177 +++++++++++++++++++++++++----------------; 2 files changed, 219 insertions(+), 133 deletions(-)","The commit refactors BPF UAPI constants to enums, enhancing vmlinux.h generation for BPF applications.","BPF,UAPI,enums","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.","The syscall interface. It changes the system calls through which user-space programs interact with eBPF.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"320a36063e1441210106aa33997ad3770d4c86b4","320a36063e1441210106aa33997ad3770d4c86b4","Andrii Nakryiko","andriin@fb.com","1583258880","Alexei Starovoitov","ast@kernel.org","1583282496","a8b7de3d5af8f83f95546557c6a888d52396ca94","5fc40f37396cec199d40a417df74b39c8e458ca6","libbpf: Fix handling of optional field_name in btf_dump__emit_type_decl Internal functions, used by btf_dump__emit_type_decl(), assume field_name is never going to be NULL. Ensure it's always the case. Fixes: 9f81654eebe8 (""libbpf: Expose BTF-to-C type declaration emitting API"") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200303180800.3303471-1-andriin@fb.com","tools/lib/bpf/btf_dump.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","The commit fixes handling of optional field names in libbpf's BTF dump functionality to prevent NULL assumptions.","libbpf,field_name,BTF","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"5fc40f37396cec199d40a417df74b39c8e458ca6","5fc40f37396cec199d40a417df74b39c8e458ca6","Alexei Starovoitov","ast@kernel.org","1583281440","Alexei Starovoitov","ast@kernel.org","1583281444","e7884bbcfc7096d416345e55158d6334f8849825","abbc61a5f26d52a5d3abbbe552b275360b2c6631 62511ceadf6e217f09d4ab1f9198d2bb5cc70e7c","Merge branch 'bpf_gso_size' Willem de Bruijn says: ==================== See first patch for details. Patch split across three parts { kernel feature, uapi header, tools } following the custom for such __sk_buff changes. ==================== Acked-by: Petar Penkov Signed-off-by: Alexei Starovoitov ","","The commit merges the 'bpf_gso_size' branch addressing kernel features, uapi headers, and tools related to eBPF changes.","merge,bpf,gso","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"62511ceadf6e217f09d4ab1f9198d2bb5cc70e7c","62511ceadf6e217f09d4ab1f9198d2bb5cc70e7c","Willem de Bruijn","willemb@google.com","1583265903","Alexei Starovoitov","ast@kernel.org","1583281439","e7884bbcfc7096d416345e55158d6334f8849825","b0ac4941aa2a249bbb06de86110cd9e2e53980ca","selftests/bpf: Test new __sk_buff field gso_size Analogous to the gso_segs selftests introduced in commit d9ff286a0f59 (""bpf: allow BPF programs access skb_shared_info->gso_segs field""). Signed-off-by: Willem de Bruijn Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200303200503.226217-4-willemdebruijn.kernel@gmail.com","tools/testing/selftests/bpf/prog_tests/skb_ctx.c | 1 +; tools/testing/selftests/bpf/progs/test_skb_ctx.c | 2 +; tools/testing/selftests/bpf/verifier/ctx_skb.c | 47 ++++++++++++++++++++++++; 3 files changed, 50 insertions(+)","The commit adds a test for the gso_size field in BPF selftests.","selftests,gso_size,skb","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"b0ac4941aa2a249bbb06de86110cd9e2e53980ca","b0ac4941aa2a249bbb06de86110cd9e2e53980ca","Willem de Bruijn","willemb@google.com","1583265902","Alexei Starovoitov","ast@kernel.org","1583281439","d7b68f7b3b4eb0c2e681c0b32436d18d6eef9766","cf62089b0edd7e74a1f474844b4d9f7b5697fb5c","bpf: Sync uapi bpf.h to tools/ sync tools/include/uapi/linux/bpf.h to match include/uapi/linux/bpf.h Signed-off-by: Willem de Bruijn Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200303200503.226217-3-willemdebruijn.kernel@gmail.com","tools/include/uapi/linux/bpf.h | 1 +; 1 file changed, 1 insertion(+)","Sync uapi bpf.h file between kernel source and tools directory for consistency.","bpf,sync,tools","A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"cf62089b0edd7e74a1f474844b4d9f7b5697fb5c","cf62089b0edd7e74a1f474844b4d9f7b5697fb5c","Willem de Bruijn","willemb@google.com","1583265901","Alexei Starovoitov","ast@kernel.org","1583281439","9daf8bfb7c74ff98ca4c507f8d5bf8184c4d7bec","abbc61a5f26d52a5d3abbbe552b275360b2c6631","bpf: Add gso_size to __sk_buff BPF programs may want to know whether an skb is gso. The canonical answer is skb_is_gso(skb), which tests that gso_size != 0. Expose this field in the same manner as gso_segs. That field itself is not a sufficient signal, as the comment in skb_shared_info makes clear: gso_segs may be zero, e.g., from dodgy sources. Also prepare net/bpf/test_run for upcoming BPF_PROG_TEST_RUN tests of the feature. Signed-off-by: Willem de Bruijn Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200303200503.226217-2-willemdebruijn.kernel@gmail.com","include/uapi/linux/bpf.h | 1 +; net/bpf/test_run.c | 7 +++++++; net/core/filter.c | 44 ++++++++++++++++++++++++++++++--------------; 3 files changed, 38 insertions(+), 14 deletions(-)","This commit adds gso_size to __sk_buff and prepares test infrastructure for BPF_PROG_TEST_RUN tests of this field.","gso_size,__sk_buff,BPF_PROG_TEST_RUN","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"abbc61a5f26d52a5d3abbbe552b275360b2c6631","abbc61a5f26d52a5d3abbbe552b275360b2c6631","Alexei Starovoitov","ast@kernel.org","1583215588","Alexei Starovoitov","ast@kernel.org","1583216011","ca5fb6ac35ee781923f2f2be5bb66b83e4e29c1b","775a2be52da1c55fc810a5d151049f86f0fd5362 6489b8e1e3cf0eb8639e96610002837c53a677cd","Merge branch 'bpf_link' Andrii Nakryiko says: ==================== This patch series adds bpf_link abstraction, analogous to libbpf's already existing bpf_link abstraction. This formalizes and makes more uniform existing bpf_link-like BPF program link (attachment) types (raw tracepoint and tracing links), which are FD-based objects that are automatically detached when last file reference is closed. These types of BPF program links are switched to using bpf_link framework. FD-based bpf_link approach provides great safety guarantees, by ensuring there is not going to be an abandoned BPF program attached, if user process suddenly exits or forgets to clean up after itself. This is especially important in production environment and is what all the recent new BPF link types followed. One of the previously existing inconveniences of FD-based approach, though, was the scenario in which user process wants to install BPF link and exit, but let attached BPF program run. Now, with bpf_link abstraction in place, it's easy to support pinning links in BPF FS, which is done as part of the same patch #1. This allows FD-based BPF program links to survive exit of a user process and original file descriptor being closed, by creating an file entry in BPF FS. This provides great safety by default, with simple way to opt out for cases where it's needed. Corresponding libbpf APIs are added in the same patch set, as well as selftests for this functionality. Other types of BPF program attachments (XDP, cgroup, perf_event, etc) are going to be converted in subsequent patches to follow similar approach. v1->v2: - use bpf_link_new_fd() uniformly (Alexei). ==================== Signed-off-by: Alexei Starovoitov ","","The commit merges the 'bpf_link' branch, introducing a bpf_link abstraction to standardize BPF program link attachment and improve safety using an FD-based approach.","bpf_link,abstraction,safety","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"6489b8e1e3cf0eb8639e96610002837c53a677cd","6489b8e1e3cf0eb8639e96610002837c53a677cd","Andrii Nakryiko","andriin@fb.com","1583209919","Alexei Starovoitov","ast@kernel.org","1583215587","ca5fb6ac35ee781923f2f2be5bb66b83e4e29c1b","c016b68edc7a2adf3db0f11fb649797c1f9216ea","selftests/bpf: Add link pinning selftests Add selftests validating link pinning/unpinning and associated BPF link (attachment) lifetime. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200303043159.323675-4-andriin@fb.com",".../selftests/bpf/prog_tests/link_pinning.c | 105 +++++++++++++++++++++; .../selftests/bpf/progs/test_link_pinning.c | 25 +++++; 2 files changed, 130 insertions(+)","This commit adds selftests for verifying BPF link pinning and attachment lifetime.","selftests link pinning","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"c016b68edc7a2adf3db0f11fb649797c1f9216ea","c016b68edc7a2adf3db0f11fb649797c1f9216ea","Andrii Nakryiko","andriin@fb.com","1583209918","Alexei Starovoitov","ast@kernel.org","1583215587","6b16138cd92c3ca9c36ddfadff2e1ccbb3082ab4","70ed506c3bbcfa846d4636b23051ca79fa4781f7","libbpf: Add bpf_link pinning/unpinning With bpf_link abstraction supported by kernel explicitly, add pinning/unpinning API for links. Also allow to create (open) bpf_link from BPF FS file. This API allows to have an ""ephemeral"" FD-based BPF links (like raw tracepoint or fexit/freplace attachments) surviving user process exit, by pinning them in a BPF FS, which is an important use case for long-running BPF programs. As part of this, expose underlying FD for bpf_link. While legacy bpf_link's might not have a FD associated with them (which will be expressed as a bpf_link with fd=-1), kernel's abstraction is based around FD-based usage, so match it closely. This, subsequently, allows to have a generic pinning/unpinning API for generalized bpf_link. For some types of bpf_links kernel might not support pinning, in which case bpf_link__pin() will return error. With FD being part of generic bpf_link, also get rid of bpf_link_fd in favor of using vanialla bpf_link. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200303043159.323675-3-andriin@fb.com","tools/lib/bpf/libbpf.c | 131 +++++++++++++++++++++++++++++++++++++----------; tools/lib/bpf/libbpf.h | 5 ++; tools/lib/bpf/libbpf.map | 5 ++; 3 files changed, 114 insertions(+), 27 deletions(-)","Adds API for pinning and unpinning bpf_links to support long-running BPF programs by preserving link states across user process exits.","bpf_link, pinning, API","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"70ed506c3bbcfa846d4636b23051ca79fa4781f7","70ed506c3bbcfa846d4636b23051ca79fa4781f7","Andrii Nakryiko","andriin@fb.com","1583209917","Alexei Starovoitov","ast@kernel.org","1583215587","82ef162ee20b4d3b4b501c8768ed1c7c4007d968","775a2be52da1c55fc810a5d151049f86f0fd5362","bpf: Introduce pinnable bpf_link abstraction Introduce bpf_link abstraction, representing an attachment of BPF program to a BPF hook point (e.g., tracepoint, perf event, etc). bpf_link encapsulates ownership of attached BPF program, reference counting of a link itself, when reference from multiple anonymous inodes, as well as ensures that release callback will be called from a process context, so that users can safely take mutex locks and sleep. Additionally, with a new abstraction it's now possible to generalize pinning of a link object in BPF FS, allowing to explicitly prevent BPF program detachment on process exit by pinning it in a BPF FS and let it open from independent other process to keep working with it. Convert two existing bpf_link-like objects (raw tracepoint and tracing BPF program attachments) into utilizing bpf_link framework, making them pinnable in BPF FS. More FD-based bpf_links will be added in follow up patches. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200303043159.323675-2-andriin@fb.com","include/linux/bpf.h | 13 +++; kernel/bpf/inode.c | 42 +++++++++-; kernel/bpf/syscall.c | 223 +++++++++++++++++++++++++++++++++++++++++----------; 3 files changed, 232 insertions(+), 46 deletions(-)","The commit introduces a bpf_link abstraction to represent BPF program attachments, making them pinnable and enhancing reference management.","bpf_link,pinnable,abstraction","A new feature. It adds a new capability or feature that was not previously present.","Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.","The syscall interface. It changes the system calls through which user-space programs interact with eBPF.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"775a2be52da1c55fc810a5d151049f86f0fd5362","775a2be52da1c55fc810a5d151049f86f0fd5362","Toke Høiland-Jørgensen","toke@redhat.com","1583160828","Alexei Starovoitov","ast@kernel.org","1583197241","7f137e140f276375d6fcf7c238f5e4cdfcbfa758","441420a1f0b3031f228453697406c86f110e59d4","selftests/bpf: Declare bpf_log_buf variables as static The cgroup selftests did not declare the bpf_log_buf variable as static, leading to a linker error with GCC 10 (which defaults to -fno-common). Fix this by adding the missing static declarations. Fixes: 257c88559f36 (""selftests/bpf: Convert test_cgroup_attach to prog_tests"") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Acked-by: Andrey Ignatov Link: https://lore.kernel.org/bpf/20200302145348.559177-1-toke@redhat.com","tools/testing/selftests/bpf/prog_tests/cgroup_attach_autodetach.c | 2 +-; tools/testing/selftests/bpf/prog_tests/cgroup_attach_multi.c | 2 +-; tools/testing/selftests/bpf/prog_tests/cgroup_attach_override.c | 2 +-; 3 files changed, 3 insertions(+), 3 deletions(-)","The commit adds static declarations to bpf_log_buf variables in cgroup selftests to fix linker errors with GCC 10.","static,declarations,cgroup","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups).']" +"441420a1f0b3031f228453697406c86f110e59d4","441420a1f0b3031f228453697406c86f110e59d4","Andrii Nakryiko","andriin@fb.com","1583050243","Alexei Starovoitov","ast@kernel.org","1583196595","d223a75dcdd795660206c0be228148de5c1aa944","82dbbfc822cd7230c657b49da6557c8bf2f6621d","bpf: Reliably preserve btf_trace_xxx types btf_trace_xxx types, crucial for tp_btf BPF programs (raw tracepoint with verifier-checked direct memory access), have to be preserved in kernel BTF to allow verifier do its job and enforce type/memory safety. It was reported ([0]) that for kernels built with Clang current type-casting approach doesn't preserve these types. This patch fixes it by declaring an anonymous union for each registered tracepoint, capturing both struct bpf_raw_event_map information, as well as recording btf_trace_##call type reliably. Structurally, it's still the same content as for a plain struct bpf_raw_event_map, so no other changes are necessary. [0] https://github.com/iovisor/bcc/issues/2770#issuecomment-591007692 Fixes: e8c423fb31fa (""bpf: Add typecast to raw_tracepoints to help BTF generation"") Reported-by: Wenbo Zhang Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200301081045.3491005-2-andriin@fb.com","include/trace/bpf_probe.h | 18 +++++++++++-------; 1 file changed, 11 insertions(+), 7 deletions(-)","The commit fixes the preservation of btf_trace_xxx types in kernel BTF by using anonymous unions for tp_btf BPF programs.","btf_trace_xxx,kernel BTF,tracepoint","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.']" +"82dbbfc822cd7230c657b49da6557c8bf2f6621d","82dbbfc822cd7230c657b49da6557c8bf2f6621d","Alexei Starovoitov","ast@kernel.org","1583195115","Alexei Starovoitov","ast@kernel.org","1583195122","b8393760f038a2a900c3f565514e9b326589439e","15070919f801348e9a9a2ea96f427d8b621f3cd5 df8ff35311c8d10d90b4604c02b32c361dc997aa","Merge branch 'move_BPF_PROG_to_libbpf' Andrii Nakryiko says: ==================== Move BPF_PROG, BPF_KPROBE, and BPF_KRETPROBE helper macros from private selftests helpers to public libbpf ones. These helpers are extremely helpful for writing tracing BPF applications and have been requested to be exposed for easy use (e.g., [0]). As part of this move, fix up BPF_KRETPROBE to not allow for capturing input arguments (as it's unreliable and they will be often clobbered). Also, add vmlinux.h header guard to allow multi-time inclusion, if necessary; but also to let PT_REGS_PARM do proper detection of struct pt_regs field names on x86 arch. See relevant patches for more details. [0] https://github.com/iovisor/bcc/pull/2778#issue-381642907 ==================== Signed-off-by: Alexei Starovoitov ","","This commit merges helper macros for BPF tracing applications from private selftests into the public libbpf library.","merge,libbpf,tracing","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.', 'kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"df8ff35311c8d10d90b4604c02b32c361dc997aa","df8ff35311c8d10d90b4604c02b32c361dc997aa","Andrii Nakryiko","andriin@fb.com","1583017872","Alexei Starovoitov","ast@kernel.org","1583195114","b8393760f038a2a900c3f565514e9b326589439e","396f544ed5e5a9c40de5663b774f643644cba059","libbpf: Merge selftests' bpf_trace_helpers.h into libbpf's bpf_tracing.h Move BPF_PROG, BPF_KPROBE, and BPF_KRETPROBE macro into libbpf's bpf_tracing.h header to make it available for non-selftests users. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200229231112.1240137-5-andriin@fb.com","tools/lib/bpf/bpf_tracing.h | 118 ++++++++++++++++++++; tools/testing/selftests/bpf/bpf_tcp_helpers.h | 2 +-; tools/testing/selftests/bpf/bpf_trace_helpers.h | 121 ---------------------; tools/testing/selftests/bpf/progs/bpf_dctcp.c | 2 +-; tools/testing/selftests/bpf/progs/fentry_test.c | 2 +-; tools/testing/selftests/bpf/progs/fexit_bpf2bpf.c | 2 +-; .../selftests/bpf/progs/fexit_bpf2bpf_simple.c | 2 +-; tools/testing/selftests/bpf/progs/fexit_test.c | 2 +-; tools/testing/selftests/bpf/progs/kfree_skb.c | 2 +-; .../selftests/bpf/progs/test_attach_probe.c | 2 +-; tools/testing/selftests/bpf/progs/test_overhead.c | 1 -; .../selftests/bpf/progs/test_perf_branches.c | 2 +-; .../testing/selftests/bpf/progs/test_perf_buffer.c | 2 +-; .../testing/selftests/bpf/progs/test_probe_user.c | 1 -; .../selftests/bpf/progs/test_trampoline_count.c | 3 +-; .../testing/selftests/bpf/progs/test_xdp_bpf2bpf.c | 2 +-; 16 files changed, 131 insertions(+), 135 deletions(-)","The commit integrates bpf_trace_helpers.h into libbpf's bpf_tracing.h to extend macro availability beyond selftests.","libbpf, macros, tracing","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"396f544ed5e5a9c40de5663b774f643644cba059","396f544ed5e5a9c40de5663b774f643644cba059","Andrii Nakryiko","andriin@fb.com","1583017871","Alexei Starovoitov","ast@kernel.org","1583195114","33208526d4177af87a61d5f2fdc6fdc521ccc8b9","fd56e0058412fb542db0e9556f425747cf3f8366","selftests/bpf: Fix BPF_KRETPROBE macro and use it in attach_probe test For kretprobes, there is no point in capturing input arguments from pt_regs, as they are going to be, most probably, clobbered by the time probed kernel function returns. So switch BPF_KRETPROBE to accept zero or one argument (optional return result). Fixes: ac065870d928 (""selftests/bpf: Add BPF_PROG, BPF_KPROBE, and BPF_KRETPROBE macros"") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200229231112.1240137-4-andriin@fb.com","tools/testing/selftests/bpf/bpf_trace_helpers.h | 13 +++++++------; tools/testing/selftests/bpf/progs/test_attach_probe.c | 3 ++-; tools/testing/selftests/bpf/progs/test_overhead.c | 6 ++----; 3 files changed, 11 insertions(+), 11 deletions(-)","This commit fixes the BPF_KRETPROBE macro for kretprobes in selftests and adjusts its usage to handle arguments correctly.","BPF_KRETPROBE,selftests,fix","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"fd56e0058412fb542db0e9556f425747cf3f8366","fd56e0058412fb542db0e9556f425747cf3f8366","Andrii Nakryiko","andriin@fb.com","1583017870","Alexei Starovoitov","ast@kernel.org","1583195114","fa11ac72a2bc294ab41dad229bb3142ef5996083","ca7dc2791b507f842d73e46b1a0453b36b69ffc2","libbpf: Fix use of PT_REGS_PARM macros with vmlinux.h Add detection of vmlinux.h to bpf_tracing.h header for PT_REGS macro. Currently, BPF applications have to define __KERNEL__ symbol to use correct definition of struct pt_regs on x86 arch. This is due to different field names under internal kernel vs UAPI conditions. To make this more transparent for users, detect vmlinux.h by checking __VMLINUX_H__ symbol. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200229231112.1240137-3-andriin@fb.com","tools/lib/bpf/bpf_tracing.h | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","Fixes PT_REGS_PARM macro usage in libbpf by adding vmlinux.h detection.","libbpf, vmlinux.h, PT_REGS","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"ca7dc2791b507f842d73e46b1a0453b36b69ffc2","ca7dc2791b507f842d73e46b1a0453b36b69ffc2","Andrii Nakryiko","andriin@fb.com","1583017869","Alexei Starovoitov","ast@kernel.org","1583195114","b68bae67d0fbce7f668f33eed823ddb2efa777f5","15070919f801348e9a9a2ea96f427d8b621f3cd5","bpftool: Add header guards to generated vmlinux.h Add canonical #ifndef/#define/#endif guard for generated vmlinux.h header with __VMLINUX_H__ symbol. __VMLINUX_H__ is also going to play double role of identifying whether vmlinux.h is being used, versus, say, BCC or non-CO-RE libbpf modes with dependency on kernel headers. This will make it possible to write helper macro/functions, agnostic to exact BPF program set up. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200229231112.1240137-2-andriin@fb.com","tools/bpf/bpftool/btf.c | 5 +++++; 1 file changed, 5 insertions(+)","Added header guards to the generated vmlinux.h in bpftool for better compatibility and identification across BPF setups.","header guards bpftool vmlinux.h","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"9f0ca0c1a50a7de5c71970aa452941199ed210d9","9f0ca0c1a50a7de5c71970aa452941199ed210d9","David S. Miller","davem@davemloft.net","1583020415","David S. Miller","davem@davemloft.net","1583020415","b7e19ab2e5bbc951141fb90489923b50b8f263f3","9a834f9b04bc5ed2db27eb45b0cc6415ce7c314c 812285fa5ab129e3a55682314bf235f701564310","Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next Alexei Starovoitov says: ==================== pull-request: bpf-next 2020-02-28 The following pull-request contains BPF updates for your *net-next* tree. We've added 41 non-merge commits during the last 7 day(s) which contain a total of 49 files changed, 1383 insertions(+), 499 deletions(-). The main changes are: 1) BPF and Real-Time nicely co-exist. 2) bpftool feature improvements. 3) retrieve bpf_sk_storage via INET_DIAG. ==================== Signed-off-by: David S. Miller ","","This commit merges 41 non-merge BPF-related updates into the net-next tree, including bpftool improvements and bpf_sk_storage access enhancement.","BPF,bpftool,INET_DIAG","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"812285fa5ab129e3a55682314bf235f701564310","812285fa5ab129e3a55682314bf235f701564310","Alexei Starovoitov","ast@kernel.org","1582858220","Alexei Starovoitov","ast@kernel.org","1582858417","c46fa77ecfc97e4120c02b7a8bd517e635afc7ee","d7f10df86202273155a9d8f8553bc2ad28e0dd46 085c20cacf2b72991ce1c9d99a5e2f1d9e73bb68","Merge branch 'bpf_sk_storage_via_inet_diag' Martin KaFai Lau says: ==================== The bpf_prog can store specific info to a sk by using bpf_sk_storage. In other words, a sk can be extended by a bpf_prog. This series is to support providing bpf_sk_storage data during inet_diag's dump. The primary target is the usage like iproute2's ""ss"". The first two patches are refactoring works in inet_diag to make adding bpf_sk_storage support easier. The next two patches do the actual work. Please see individual patch for details. v2: - Add commit message for u16 to u32 change in min_dump_alloc in Patch 4 (Song) - Add comment to explain the !skb->len check in __inet_diag_dump in Patch 4. - Do the map->map_type check earlier in Patch 3 for readability. ==================== Signed-off-by: Alexei Starovoitov ","","This commit merges bpf_sk_storage support into inet_diag to enhance socket information retrieval like iproute2's ss command.","bpf_sk_storage,inet_diag,merge","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"085c20cacf2b72991ce1c9d99a5e2f1d9e73bb68","085c20cacf2b72991ce1c9d99a5e2f1d9e73bb68","Martin KaFai Lau","kafai@fb.com","1582671867","Alexei Starovoitov","ast@kernel.org","1582858219","c46fa77ecfc97e4120c02b7a8bd517e635afc7ee","1ed4d92458a969e71e7914550b6f0c730c14d84e","bpf: inet_diag: Dump bpf_sk_storages in inet_diag_dump() This patch will dump out the bpf_sk_storages of a sk if the request has the INET_DIAG_REQ_SK_BPF_STORAGES nlattr. An array of SK_DIAG_BPF_STORAGE_REQ_MAP_FD can be specified in INET_DIAG_REQ_SK_BPF_STORAGES to select which bpf_sk_storage to dump. If no map_fd is specified, all bpf_sk_storages of a sk will be dumped. bpf_sk_storages can be added to the system at runtime. It is difficult to find a proper static value for cb->min_dump_alloc. This patch learns the nlattr size required to dump the bpf_sk_storages of a sk. If it happens to be the very first nlmsg of a dump and it cannot fit the needed bpf_sk_storages, it will try to expand the skb by ""pskb_expand_head()"". Instead of expanding it in inet_sk_diag_fill(), it is expanded at a sleepable context in __inet_diag_dump() so __GFP_DIRECT_RECLAIM can be used. In __inet_diag_dump(), it will retry as long as the skb is empty and the cb->min_dump_alloc becomes larger than before. cb->min_dump_alloc is bounded by KMALLOC_MAX_SIZE. The min_dump_alloc is also changed from 'u16' to 'u32' to accommodate a sk that may have a few large bpf_sk_storages. The updated cb->min_dump_alloc will also be used to allocate the skb in the next dump. This logic already exists in netlink_dump(). Here is the sample output of a locally modified 'ss' and it could be made more readable by using BTF later: [root@arch-fb-vm1 ~]# ss --bpf-map-id 14 --bpf-map-id 13 -t6an 'dst [::1]:8989' State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess ESTAB 0 0 [::1]:51072 [::1]:8989 bpf_map_id:14 value:[ 3feb ] bpf_map_id:13 value:[ 3f ] ESTAB 0 0 [::1]:51070 [::1]:8989 bpf_map_id:14 value:[ 3feb ] bpf_map_id:13 value:[ 3f ] [root@arch-fb-vm1 ~]# ~/devshare/github/iproute2/misc/ss --bpf-maps -t6an 'dst [::1]:8989' State Recv-Q Send-Q Local Address:Port Peer Address:Port Process ESTAB 0 0 [::1]:51072 [::1]:8989 bpf_map_id:14 value:[ 3feb ] bpf_map_id:13 value:[ 3f ] bpf_map_id:12 value:[ 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000... total:65407 ] ESTAB 0 0 [::1]:51070 [::1]:8989 bpf_map_id:14 value:[ 3feb ] bpf_map_id:13 value:[ 3f ] bpf_map_id:12 value:[ 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000... total:65407 ] Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200225230427.1976129-1-kafai@fb.com","include/linux/inet_diag.h | 4 +++; include/linux/netlink.h | 4 +--; include/uapi/linux/inet_diag.h | 2 ++; net/ipv4/inet_diag.c | 74 ++++++++++++++++++++++++++++++++++++++++++; 4 files changed, 82 insertions(+), 2 deletions(-)","Enhances socket diagnostics to support dumping eBPF storage data via netlink attributes.","inet_diag,bpf_sk_storages,netlink","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"1ed4d92458a969e71e7914550b6f0c730c14d84e","1ed4d92458a969e71e7914550b6f0c730c14d84e","Martin KaFai Lau","kafai@fb.com","1582671861","Alexei Starovoitov","ast@kernel.org","1582858219","2b7c46da8b9cdd96459f62268f583427b99dd693","0df6d32842b9a5f97a29ea90c8adc5cfac38341d","bpf: INET_DIAG support in bpf_sk_storage This patch adds INET_DIAG support to bpf_sk_storage. 1. Although this series adds bpf_sk_storage diag capability to inet sk, bpf_sk_storage is in general applicable to all fullsock. Hence, the bpf_sk_storage logic will operate on SK_DIAG_* nlattr. The caller will pass in its specific nesting nlattr (e.g. INET_DIAG_*) as the argument. 2. The request will be like: INET_DIAG_REQ_SK_BPF_STORAGES (nla_nest) (defined in latter patch) SK_DIAG_BPF_STORAGE_REQ_MAP_FD (nla_put_u32) SK_DIAG_BPF_STORAGE_REQ_MAP_FD (nla_put_u32) ...... Considering there could have multiple bpf_sk_storages in a sk, instead of reusing INET_DIAG_INFO (""ss -i""), the user can select some specific bpf_sk_storage to dump by specifying an array of SK_DIAG_BPF_STORAGE_REQ_MAP_FD. If no SK_DIAG_BPF_STORAGE_REQ_MAP_FD is specified (i.e. an empty INET_DIAG_REQ_SK_BPF_STORAGES), it will dump all bpf_sk_storages of a sk. 3. The reply will be like: INET_DIAG_BPF_SK_STORAGES (nla_nest) (defined in latter patch) SK_DIAG_BPF_STORAGE (nla_nest) SK_DIAG_BPF_STORAGE_MAP_ID (nla_put_u32) SK_DIAG_BPF_STORAGE_MAP_VALUE (nla_reserve_64bit) SK_DIAG_BPF_STORAGE (nla_nest) SK_DIAG_BPF_STORAGE_MAP_ID (nla_put_u32) SK_DIAG_BPF_STORAGE_MAP_VALUE (nla_reserve_64bit) ...... 4. Unlike other INET_DIAG info of a sk which is pretty static, the size required to dump the bpf_sk_storage(s) of a sk is dynamic as the system adding more bpf_sk_storage_map. It is hard to set a static min_dump_alloc size. Hence, this series learns it at the runtime and adjust the cb->min_dump_alloc as it iterates all sk(s) of a system. The ""unsigned int *res_diag_size"" in bpf_sk_storage_diag_put() is for this purpose. The next patch will update the cb->min_dump_alloc as it iterates the sk(s). Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200225230421.1975729-1-kafai@fb.com","include/linux/bpf.h | 1 +; include/net/bpf_sk_storage.h | 27 ++++; include/uapi/linux/sock_diag.h | 26 ++++; kernel/bpf/syscall.c | 15 +++; net/core/bpf_sk_storage.c | 283 ++++++++++++++++++++++++++++++++++++++++-; 5 files changed, 346 insertions(+), 6 deletions(-)","This commit adds INET_DIAG support for bpf_sk_storage, enabling socket diagnostics for multiple bpf_sk_storages.","INET_DIAG,bpf_sk_storage,storage","A new feature. It adds a new capability or feature that was not previously present.","Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"0df6d32842b9a5f97a29ea90c8adc5cfac38341d","0df6d32842b9a5f97a29ea90c8adc5cfac38341d","Martin KaFai Lau","kafai@fb.com","1582671855","Alexei Starovoitov","ast@kernel.org","1582858219","d9b50a11f25fb4c0f30505eed7cffae73879862b","5682d393b40e1fe7426a7b8c3471f05262f42010","inet_diag: Move the INET_DIAG_REQ_BYTECODE nlattr to cb->data The INET_DIAG_REQ_BYTECODE nlattr is currently re-found every time when the ""dump()"" is re-started. In a latter patch, it will also need to parse the new INET_DIAG_REQ_SK_BPF_STORAGES nlattr to learn the map_fds. Thus, this patch takes this chance to store the parsed nlattr in cb->data during the ""start"" time of a dump. By doing this, the ""bc"" argument also becomes unnecessary and is removed. Also, the two copies of the INET_DIAG_REQ_BYTECODE parsing-audit logic between compat/current version can be consolidated to one. Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200225230415.1975555-1-kafai@fb.com","include/linux/inet_diag.h | 11 ++--; include/uapi/linux/inet_diag.h | 3 +-; net/dccp/diag.c | 4 +-; net/ipv4/inet_diag.c | 117 ++++++++++++++++++++++++-----------------; net/ipv4/raw_diag.c | 6 ++-; net/ipv4/tcp_diag.c | 4 +-; net/ipv4/udp_diag.c | 15 +++---; net/sctp/diag.c | 2 +-; 8 files changed, 98 insertions(+), 64 deletions(-)","The commit optimizes INET_DIAG by storing parsed nlattr in cb->data during dump initialization.","INET_DIAG,nlattr,cb->data","A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.","It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.","[""It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here.""]" +"5682d393b40e1fe7426a7b8c3471f05262f42010","5682d393b40e1fe7426a7b8c3471f05262f42010","Martin KaFai Lau","kafai@fb.com","1582671849","Alexei Starovoitov","ast@kernel.org","1582858219","48be740a5335e7202c66d3f238ecbf9c808c2c05","d7f10df86202273155a9d8f8553bc2ad28e0dd46","inet_diag: Refactor inet_sk_diag_fill(), dump(), and dump_one() In a latter patch, there is a need to update ""cb->min_dump_alloc"" in inet_sk_diag_fill() as it learns the diffierent bpf_sk_storages stored in a sk while dumping all sk(s) (e.g. tcp_hashinfo). The inet_sk_diag_fill() currently does not take the ""cb"" as an argument. One of the reason is inet_sk_diag_fill() is used by both dump_one() and dump() (which belong to the ""struct inet_diag_handler"". The dump_one() interface does not pass the ""cb"" along. This patch is to make dump_one() pass a ""cb"". The ""cb"" is created in inet_diag_cmd_exact(). The ""nlh"" and ""in_skb"" are stored in ""cb"" as the dump() interface does. The total number of args in inet_sk_diag_fill() is also cut from 10 to 7 and that helps many callers to pass fewer args. In particular, ""struct user_namespace *user_ns"", ""u32 pid"", and ""u32 seq"" can be replaced by accessing ""cb->nlh"" and ""cb->skb"". A similar argument reduction is also made to inet_twsk_diag_fill() and inet_req_diag_fill(). inet_csk_diag_dump() and inet_csk_diag_fill() are also removed. They are mostly equivalent to inet_sk_diag_fill(). Their repeated usages are very limited. Thus, inet_sk_diag_fill() is directly used in those occasions. Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200225230409.1975173-1-kafai@fb.com","include/linux/inet_diag.h | 12 ++---; net/dccp/diag.c | 5 +-; net/ipv4/inet_diag.c | 116 ++++++++++++++++++----------------------------; net/ipv4/raw_diag.c | 18 +++----; net/ipv4/tcp_diag.c | 4 +-; net/ipv4/udp_diag.c | 26 +++++------; net/sctp/diag.c | 5 +-; 7 files changed, 73 insertions(+), 113 deletions(-)","Refactor inet_diag related functions to streamline argument passing and improve maintainability.","refactor, inet_diag, maintainability","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.","It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.","[""It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.""]" +"d7f10df86202273155a9d8f8553bc2ad28e0dd46","d7f10df86202273155a9d8f8553bc2ad28e0dd46","Gustavo A. R. Silva","gustavo@embeddedor.com","1582762664","Daniel Borkmann","daniel@iogearbox.net","1582849262","e253c06e6c409afbff1f057a5376fc77ac1dc01f","4bc988464bb193d67c93ddb2fcd1de127d815b6c","bpf: Replace zero-length array with flexible-array member The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: ""Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero.""[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f (""cxgb3/l2t: Fix undefined behaviour"") Signed-off-by: Gustavo A. R. Silva Signed-off-by: Daniel Borkmann Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200227001744.GA3317@embeddedor","include/linux/bpf-cgroup.h | 2 +-; include/linux/bpf.h | 2 +-; include/uapi/linux/bpf.h | 2 +-; kernel/bpf/bpf_struct_ops.c | 2 +-; kernel/bpf/hashtab.c | 2 +-; kernel/bpf/lpm_trie.c | 2 +-; 6 files changed, 6 insertions(+), 6 deletions(-)","This commit replaces zero-length arrays with flexible-array members in bpf-related structures for better safety and C99 compliance.","flexible-array, zero-length, C99","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"1eb1f43a6e37282348a41e3d68f5e9a6a4359212","1eb1f43a6e37282348a41e3d68f5e9a6a4359212","Taehee Yoo","ap420073@gmail.com","1582806266","David S. Miller","davem@davemloft.net","1582832707","a3f5b137d02ef02cf11c0c39b222605d962fc448","93b5cbfa9636d385126f211dca9efa7e3f683202","net: rmnet: fix NULL pointer dereference in rmnet_changelink() In the rmnet_changelink(), it uses IFLA_LINK without checking NULL pointer. tb[IFLA_LINK] could be NULL pointer. So, NULL-ptr-deref could occur. rmnet already has a lower interface (real_dev). So, after this patch, rmnet_changelink() does not use IFLA_LINK anymore. Test commands: modprobe rmnet ip link add dummy0 type dummy ip link add rmnet0 link dummy0 type rmnet mux_id 1 ip link set rmnet0 type rmnet mux_id 2 Splat looks like: [ 90.578726][ T1131] general protection fault, probably for non-canonical address 0xdffffc0000000000I [ 90.581121][ T1131] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] [ 90.582380][ T1131] CPU: 2 PID: 1131 Comm: ip Not tainted 5.6.0-rc1+ #447 [ 90.584285][ T1131] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 90.587506][ T1131] RIP: 0010:rmnet_changelink+0x5a/0x8a0 [rmnet] [ 90.588546][ T1131] Code: 83 ec 20 48 c1 ea 03 80 3c 02 00 0f 85 6f 07 00 00 48 8b 5e 28 48 b8 00 00 00 00 00 0 [ 90.591447][ T1131] RSP: 0018:ffff8880ce78f1b8 EFLAGS: 00010247 [ 90.592329][ T1131] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffff8880ce78f8b0 [ 90.593253][ T1131] RDX: 0000000000000000 RSI: ffff8880ce78f4a0 RDI: 0000000000000004 [ 90.594058][ T1131] RBP: ffff8880cf543e00 R08: 0000000000000002 R09: 0000000000000002 [ 90.594859][ T1131] R10: ffffffffc0586a40 R11: 0000000000000000 R12: ffff8880ca47c000 [ 90.595690][ T1131] R13: ffff8880ca47c000 R14: ffff8880cf545000 R15: 0000000000000000 [ 90.596553][ T1131] FS: 00007f21f6c7e0c0(0000) GS:ffff8880da400000(0000) knlGS:0000000000000000 [ 90.597504][ T1131] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 90.599418][ T1131] CR2: 0000556e413db458 CR3: 00000000c917a002 CR4: 00000000000606e0 [ 90.600289][ T1131] Call Trace: [ 90.600631][ T1131] __rtnl_newlink+0x922/0x1270 [ 90.601194][ T1131] ? lock_downgrade+0x6e0/0x6e0 [ 90.601724][ T1131] ? rtnl_link_unregister+0x220/0x220 [ 90.602309][ T1131] ? lock_acquire+0x164/0x3b0 [ 90.602784][ T1131] ? is_bpf_image_address+0xff/0x1d0 [ 90.603331][ T1131] ? rtnl_newlink+0x4c/0x90 [ 90.603810][ T1131] ? kernel_text_address+0x111/0x140 [ 90.604419][ T1131] ? __kernel_text_address+0xe/0x30 [ 90.604981][ T1131] ? unwind_get_return_address+0x5f/0xa0 [ 90.605616][ T1131] ? create_prof_cpu_mask+0x20/0x20 [ 90.606304][ T1131] ? arch_stack_walk+0x83/0xb0 [ 90.606985][ T1131] ? stack_trace_save+0x82/0xb0 [ 90.607656][ T1131] ? stack_trace_consume_entry+0x160/0x160 [ 90.608503][ T1131] ? deactivate_slab.isra.78+0x2c5/0x800 [ 90.609336][ T1131] ? kasan_unpoison_shadow+0x30/0x40 [ 90.610096][ T1131] ? kmem_cache_alloc_trace+0x135/0x350 [ 90.610889][ T1131] ? rtnl_newlink+0x4c/0x90 [ 90.611512][ T1131] rtnl_newlink+0x65/0x90 [ ... ] Fixes: 23790ef12082 (""net: qualcomm: rmnet: Allow to configure flags for existing devices"") Signed-off-by: Taehee Yoo Signed-off-by: David S. Miller ","drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c | 6 ++----; 1 file changed, 2 insertions(+), 4 deletions(-)","Fixes a null pointer dereference in the rmnet_changelink function by avoiding the use of IFLA_LINK.","rmnet,NULL,pointer","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.","It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.","[""It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.""]" +"93b5cbfa9636d385126f211dca9efa7e3f683202","93b5cbfa9636d385126f211dca9efa7e3f683202","Taehee Yoo","ap420073@gmail.com","1582806232","David S. Miller","davem@davemloft.net","1582832707","abf49eff22a8438a361f24b0a4af911cf462f678","b82cf17ff1957ec35eaee7dc519c365ecd06ba38","net: rmnet: fix NULL pointer dereference in rmnet_newlink() rmnet registers IFLA_LINK interface as a lower interface. But, IFLA_LINK could be NULL. In the current code, rmnet doesn't check IFLA_LINK. So, panic would occur. Test commands: modprobe rmnet ip link add rmnet0 type rmnet mux_id 1 Splat looks like: [ 36.826109][ T1115] general protection fault, probably for non-canonical address 0xdffffc0000000000I [ 36.838817][ T1115] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] [ 36.839908][ T1115] CPU: 1 PID: 1115 Comm: ip Not tainted 5.6.0-rc1+ #447 [ 36.840569][ T1115] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 36.841408][ T1115] RIP: 0010:rmnet_newlink+0x54/0x510 [rmnet] [ 36.841986][ T1115] Code: 83 ec 18 48 c1 e9 03 80 3c 01 00 0f 85 d4 03 00 00 48 8b 6a 28 48 b8 00 00 00 00 00 c [ 36.843923][ T1115] RSP: 0018:ffff8880b7e0f1c0 EFLAGS: 00010247 [ 36.844756][ T1115] RAX: dffffc0000000000 RBX: ffff8880d14cca00 RCX: 1ffff11016fc1e99 [ 36.845859][ T1115] RDX: 0000000000000000 RSI: ffff8880c3d04000 RDI: 0000000000000004 [ 36.846961][ T1115] RBP: 0000000000000000 R08: ffff8880b7e0f8b0 R09: ffff8880b6ac2d90 [ 36.848020][ T1115] R10: ffffffffc0589a40 R11: ffffed1016d585b7 R12: ffffffff88ceaf80 [ 36.848788][ T1115] R13: ffff8880c3d04000 R14: ffff8880b7e0f8b0 R15: ffff8880c3d04000 [ 36.849546][ T1115] FS: 00007f50ab3360c0(0000) GS:ffff8880da000000(0000) knlGS:0000000000000000 [ 36.851784][ T1115] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 36.852422][ T1115] CR2: 000055871afe5ab0 CR3: 00000000ae246001 CR4: 00000000000606e0 [ 36.853181][ T1115] Call Trace: [ 36.853514][ T1115] __rtnl_newlink+0xbdb/0x1270 [ 36.853967][ T1115] ? lock_downgrade+0x6e0/0x6e0 [ 36.854420][ T1115] ? rtnl_link_unregister+0x220/0x220 [ 36.854936][ T1115] ? lock_acquire+0x164/0x3b0 [ 36.855376][ T1115] ? is_bpf_image_address+0xff/0x1d0 [ 36.855884][ T1115] ? rtnl_newlink+0x4c/0x90 [ 36.856304][ T1115] ? kernel_text_address+0x111/0x140 [ 36.856857][ T1115] ? __kernel_text_address+0xe/0x30 [ 36.857440][ T1115] ? unwind_get_return_address+0x5f/0xa0 [ 36.858063][ T1115] ? create_prof_cpu_mask+0x20/0x20 [ 36.858644][ T1115] ? arch_stack_walk+0x83/0xb0 [ 36.859171][ T1115] ? stack_trace_save+0x82/0xb0 [ 36.859710][ T1115] ? stack_trace_consume_entry+0x160/0x160 [ 36.860357][ T1115] ? deactivate_slab.isra.78+0x2c5/0x800 [ 36.860928][ T1115] ? kasan_unpoison_shadow+0x30/0x40 [ 36.861520][ T1115] ? kmem_cache_alloc_trace+0x135/0x350 [ 36.862125][ T1115] ? rtnl_newlink+0x4c/0x90 [ 36.864073][ T1115] rtnl_newlink+0x65/0x90 [ ... ] Fixes: ceed73a2cf4a (""drivers: net: ethernet: qualcomm: rmnet: Initial implementation"") Signed-off-by: Taehee Yoo Signed-off-by: David S. Miller ","drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c | 5 +++++; 1 file changed, 5 insertions(+)","Fixes a NULL pointer dereference issue in the rmnet_newlink function within the Qualcomm Ethernet driver.","NULL pointer, rmnet_newlink, fix","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.","It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.","[""It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.""]" +"b6f6118901d1e867ac9177bbff3b00b185bd4fdc","b6f6118901d1e867ac9177bbff3b00b185bd4fdc","Eric Dumazet","edumazet@google.com","1582660349","David S. Miller","davem@davemloft.net","1582777258","86ffc1065b3adc5934a1c0b142c0597f2d29912a","51e3dfa8906ace90c809235b3d3afebc166b6433","ipv6: restrict IPV6_ADDRFORM operation IPV6_ADDRFORM is able to transform IPv6 socket to IPv4 one. While this operation sounds illogical, we have to support it. One of the things it does for TCP socket is to switch sk->sk_prot to tcp_prot. We now have other layers playing with sk->sk_prot, so we should make sure to not interfere with them. This patch makes sure sk_prot is the default pointer for TCP IPv6 socket. syzbot reported : BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD a0113067 P4D a0113067 PUD a8771067 PMD 0 Oops: 0010 [#1] PREEMPT SMP KASAN CPU: 0 PID: 10686 Comm: syz-executor.0 Not tainted 5.6.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:0x0 Code: Bad RIP value. RSP: 0018:ffffc9000281fce0 EFLAGS: 00010246 RAX: 1ffffffff15f48ac RBX: ffffffff8afa4560 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8880a69a8f40 RBP: ffffc9000281fd10 R08: ffffffff86ed9b0c R09: ffffed1014d351f5 R10: ffffed1014d351f5 R11: 0000000000000000 R12: ffff8880920d3098 R13: 1ffff1101241a613 R14: ffff8880a69a8f40 R15: 0000000000000000 FS: 00007f2ae75db700(0000) GS:ffff8880aea00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 00000000a3b85000 CR4: 00000000001406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: inet_release+0x165/0x1c0 net/ipv4/af_inet.c:427 __sock_release net/socket.c:605 [inline] sock_close+0xe1/0x260 net/socket.c:1283 __fput+0x2e4/0x740 fs/file_table.c:280 ____fput+0x15/0x20 fs/file_table.c:313 task_work_run+0x176/0x1b0 kernel/task_work.c:113 tracehook_notify_resume include/linux/tracehook.h:188 [inline] exit_to_usermode_loop arch/x86/entry/common.c:164 [inline] prepare_exit_to_usermode+0x480/0x5b0 arch/x86/entry/common.c:195 syscall_return_slowpath+0x113/0x4a0 arch/x86/entry/common.c:278 do_syscall_64+0x11f/0x1c0 arch/x86/entry/common.c:304 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x45c429 Code: ad b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f2ae75dac78 EFLAGS: 00000246 ORIG_RAX: 0000000000000036 RAX: 0000000000000000 RBX: 00007f2ae75db6d4 RCX: 000000000045c429 RDX: 0000000000000001 RSI: 000000000000011a RDI: 0000000000000004 RBP: 000000000076bf20 R08: 0000000000000038 R09: 0000000000000000 R10: 0000000020000180 R11: 0000000000000246 R12: 00000000ffffffff R13: 0000000000000a9d R14: 00000000004ccfb4 R15: 000000000076bf2c Modules linked in: CR2: 0000000000000000 ---[ end trace 82567b5207e87bae ]--- RIP: 0010:0x0 Code: Bad RIP value. RSP: 0018:ffffc9000281fce0 EFLAGS: 00010246 RAX: 1ffffffff15f48ac RBX: ffffffff8afa4560 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8880a69a8f40 RBP: ffffc9000281fd10 R08: ffffffff86ed9b0c R09: ffffed1014d351f5 R10: ffffed1014d351f5 R11: 0000000000000000 R12: ffff8880920d3098 R13: 1ffff1101241a613 R14: ffff8880a69a8f40 R15: 0000000000000000 FS: 00007f2ae75db700(0000) GS:ffff8880aea00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 00000000a3b85000 CR4: 00000000001406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Fixes: 604326b41a6f (""bpf, sockmap: convert to generic sk_msg interface"") Signed-off-by: Eric Dumazet Reported-by: syzbot+1938db17e275e85dc328@syzkaller.appspotmail.com Cc: Daniel Borkmann Signed-off-by: David S. Miller ","net/ipv6/ipv6_sockglue.c | 10 ++++++++--; 1 file changed, 8 insertions(+), 2 deletions(-)","Fix addresses kernel null pointer dereference issue in IPv6 to IPv4 socket transformation.","IPv6,TCP,sk_prot","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.","It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.","[""It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.""]" +"4bc988464bb193d67c93ddb2fcd1de127d815b6c","4bc988464bb193d67c93ddb2fcd1de127d815b6c","Daniel Borkmann","daniel@iogearbox.net","1582738474","Daniel Borkmann","daniel@iogearbox.net","1582738479","151ce51a79c919a4810982e05a76c62802281d43","3494bec0f6ac8ac06e0ad7c35933db345b2c5a83 736332740e295d9b6fc524f0447448f6089911d9","Merge branch 'bpf-bpftool-probes' Michal Rostecki says: ==================== Feature probes in bpftool related to bpf_probe_write_user and bpf_trace_printk helpers emit dmesg warnings which might be confusing for people running bpftool on production environments. This patch series addresses that by filtering them out by default and introducing the new positional argument ""full"" which enables all available probes. The main motivation behind those changes is ability the fact that some probes (for example those related to ""trace"" or ""write_user"" helpers) emit dmesg messages which might be confusing for people who are running on production environments. For details see the Cilium issue[0]. v1 -> v2: - Do not expose regex filters to users, keep filtering logic internal, expose only the ""full"" option for including probes which emit dmesg warnings. v2 -> v3: - Do not use regex for filtering out probes, use function IDs directly. - Fix bash completion - in v2 only ""prefix"" was proposed after ""macros"", ""dev"" and ""kernel"" were not. - Rephrase the man page paragraph, highlight helper function names. - Remove tests which parse the plain output of bpftool (except the header/macros test), focus on testing JSON output instead. - Add test which compares the output with and without ""full"" option. v3 -> v4: - Use enum to check for helper functions. - Make selftests compatible with older versions of Python 3.x than 3.7. [0] https://github.com/cilium/cilium/issues/10048 ==================== Signed-off-by: Daniel Borkmann ","","The commit merges improvements to bpftool to handle dmesg warnings with a new ""full"" option and update tests accordingly.","bpftool, probes, dmesg","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"736332740e295d9b6fc524f0447448f6089911d9","736332740e295d9b6fc524f0447448f6089911d9","Michal Rostecki","mrostecki@opensuse.org","1582736379","Daniel Borkmann","daniel@iogearbox.net","1582738474","151ce51a79c919a4810982e05a76c62802281d43","ad92b12a6e0ebfb6d32693f374ac8572f527c0c1","selftests/bpf: Add test for ""bpftool feature"" command Add Python module with tests for ""bpftool feature"" command, which mainly checks whether the ""full"" option is working properly. Signed-off-by: Michal Rostecki Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200226165941.6379-6-mrostecki@opensuse.org","tools/testing/selftests/.gitignore | 5 +-; tools/testing/selftests/bpf/Makefile | 3 +-; tools/testing/selftests/bpf/test_bpftool.py | 178 ++++++++++++++++++++++++++++; tools/testing/selftests/bpf/test_bpftool.sh | 5 +; 4 files changed, 189 insertions(+), 2 deletions(-)","This commit adds tests for the ""bpftool feature"" command to ensure the correct functionality of its options.","bpftool, feature, tests","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"ad92b12a6e0ebfb6d32693f374ac8572f527c0c1","ad92b12a6e0ebfb6d32693f374ac8572f527c0c1","Michal Rostecki","mrostecki@opensuse.org","1582736378","Daniel Borkmann","daniel@iogearbox.net","1582738474","8a05b9d283b7e1c1bc62aefc0509b8394b161e51","bcdacab6e70cf90bf3d8db94ae9226ff5117a61e","bpftool: Update bash completion for ""bpftool feature"" command Update bash completion for ""bpftool feature"" command with the new argument: ""full"". Signed-off-by: Michal Rostecki Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200226165941.6379-5-mrostecki@opensuse.org","tools/bpf/bpftool/bash-completion/bpftool | 3 ++-; 1 file changed, 2 insertions(+), 1 deletion(-)","The commit updates bash completion for the ""bpftool feature"" command by adding a new argument ""full"".","bash completion,bpftool,feature","A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"bcdacab6e70cf90bf3d8db94ae9226ff5117a61e","bcdacab6e70cf90bf3d8db94ae9226ff5117a61e","Michal Rostecki","mrostecki@opensuse.org","1582736377","Daniel Borkmann","daniel@iogearbox.net","1582738474","f883277bc616dc3c30d6c75395dc3dbf1a2b96c1","368cb0e7cdb5e67ad8c0cd52f1d71341c42a7e4b","bpftool: Update documentation of ""bpftool feature"" command Update documentation of ""bpftool feature"" command with information about new arguments: ""full"". Signed-off-by: Michal Rostecki Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200226165941.6379-4-mrostecki@opensuse.org","tools/bpf/bpftool/Documentation/bpftool-feature.rst | 19 ++++++++++---------; 1 file changed, 10 insertions(+), 9 deletions(-)","This commit updates the bpftool feature command documentation with new argument information.","bpftool,documentation,update","A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"368cb0e7cdb5e67ad8c0cd52f1d71341c42a7e4b","368cb0e7cdb5e67ad8c0cd52f1d71341c42a7e4b","Michal Rostecki","mrostecki@opensuse.org","1582736376","Daniel Borkmann","daniel@iogearbox.net","1582738474","7031a16848e12350bf8fdc2384ceacdbbc6901a4","6b52ca44e8af2c508ffbcd03261cf849a740756a","bpftool: Make probes which emit dmesg warnings optional Probes related to bpf_probe_write_user and bpf_trace_printk helpers emit dmesg warnings which might be confusing for people running bpftool on production environments. This change filters them out by default and introduces the new positional argument ""full"" which enables all available probes. Signed-off-by: Michal Rostecki Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200226165941.6379-3-mrostecki@opensuse.org","tools/bpf/bpftool/feature.c | 70 +++++++++++++++++++++++++++++++--------------; 1 file changed, 49 insertions(+), 21 deletions(-)","The commit makes certain bpftool probes that emit dmesg warnings optional by introducing a positional argument ""full"" to enable all probes.","bpftool, probes, warnings","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"6b52ca44e8af2c508ffbcd03261cf849a740756a","6b52ca44e8af2c508ffbcd03261cf849a740756a","Michal Rostecki","mrostecki@opensuse.org","1582736375","Daniel Borkmann","daniel@iogearbox.net","1582738474","62ed3f4f1c03147954ee4574768e8d7a6a7bff3f","3494bec0f6ac8ac06e0ad7c35933db345b2c5a83","bpftool: Move out sections to separate functions Remove all calls of print_end_then_start_section function and for loops out from the do_probe function. Instead, provide separate functions for each section (like i.e. section_helpers) which are called in do_probe. This change is motivated by better readability. Signed-off-by: Michal Rostecki Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200226165941.6379-2-mrostecki@opensuse.org","tools/bpf/bpftool/feature.c | 219 +++++++++++++++++++++++++-------------------; 1 file changed, 126 insertions(+), 93 deletions(-)","The commit refactors bpftool code by moving section logic into separate functions for better readability.","bpftool, refactor, readability","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"3494bec0f6ac8ac06e0ad7c35933db345b2c5a83","3494bec0f6ac8ac06e0ad7c35933db345b2c5a83","Andrey Ignatov","rdna@fb.com","1582670081","Daniel Borkmann","daniel@iogearbox.net","1582731653","7fc71cc9dc688cdb9e67865d33ac5d267884a5a4","3cd046f182aab72b922e35461b204a2b52587946","bpftool: Support struct_ops, tracing, ext prog types Add support for prog types that were added to kernel but not present in bpftool yet: struct_ops, tracing, ext prog types and corresponding section names. Before: # bpftool p l ... 184: type 26 name test_subprog3 tag dda135a7dc0daf54 gpl loaded_at 2020-02-25T13:28:33-0800 uid 0 xlated 112B jited 103B memlock 4096B map_ids 136 btf_id 85 185: type 28 name new_get_skb_len tag d2de5b87d8e5dc49 gpl loaded_at 2020-02-25T13:28:33-0800 uid 0 xlated 72B jited 69B memlock 4096B map_ids 136 btf_id 85 After: # bpftool p l ... 184: tracing name test_subprog3 tag dda135a7dc0daf54 gpl loaded_at 2020-02-25T13:28:33-0800 uid 0 xlated 112B jited 103B memlock 4096B map_ids 136 btf_id 85 185: ext name new_get_skb_len tag d2de5b87d8e5dc49 gpl loaded_at 2020-02-25T13:28:33-0800 uid 0 xlated 72B jited 69B memlock 4096B map_ids 136 btf_id 85 Signed-off-by: Andrey Ignatov Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200225223441.689109-1-rdna@fb.com","tools/bpf/bpftool/Documentation/bpftool-prog.rst | 3 ++-; tools/bpf/bpftool/bash-completion/bpftool | 3 ++-; tools/bpf/bpftool/main.h | 3 +++; tools/bpf/bpftool/prog.c | 4 ++--; 4 files changed, 9 insertions(+), 4 deletions(-)","The commit adds support for struct_ops, tracing, and ext prog types in bpftool.","struct_ops,tracing,bpftool","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"3cd046f182aab72b922e35461b204a2b52587946","3cd046f182aab72b922e35461b204a2b52587946","Scott Branden","scott.branden@broadcom.com","1582664066","Daniel Borkmann","daniel@iogearbox.net","1582728141","00e61646fe630ed6f48f527f571a8d6316564476","503d539a6e417b018616bf3060e0b5814fafce47","scripts/bpf: Switch to more portable python3 shebang Change ""/usr/bin/python3"" to ""/usr/bin/env python3"" for more portable solution in bpf_helpers_doc.py. Signed-off-by: Scott Branden Signed-off-by: Daniel Borkmann Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200225205426.6975-1-scott.branden@broadcom.com","scripts/bpf_helpers_doc.py | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","The commit updates the Python3 shebang in bpf_helpers_doc.py for better portability.","shebang, python3, portability","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"4c45945aa418f5e2f31cdaf0b1484e146e29f72f","4c45945aa418f5e2f31cdaf0b1484e146e29f72f","Ingo Molnar","mingo@kernel.org","1582726685","Ingo Molnar","mingo@kernel.org","1582726685","1c6228bfab8f9d1a708349866c7fcf5fb0bfe436","c5f86891185c408b2241ba9a82ae8622d8386aff b103de53e09f20d645eb313477f52d1993347605","Merge tag 'perf-urgent-for-mingo-5.6-20200220' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent Pull perf/urgent fixes from Arnaldo Carvalho de Melo: auxtrace: Adrian Hunter: - Fix endless record after being terminated on arm-spe. Wei Li: - Fix endless record after being terminated on Intel PT and BTS and on ARM's cs-etm. perf test: Thomas Richter - Fix test trace+probe_vfs_getname.sh on s390 PowerPC: Arnaldo Carvalho de Melo: - Sync powerpc syscall.tbl with the kernel sources. BPF: Arnaldo Carvalho de Melo: - Remove extraneous bpf/ subdir from bpf.h headers used to build bpf events. Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Ingo Molnar ","","Merge commit addressing perf/urgent fixes including BPF header path adjustment.","perf, merge, fixes","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"503d539a6e417b018616bf3060e0b5814fafce47","503d539a6e417b018616bf3060e0b5814fafce47","Yuya Kusakabe","yuya.kusakabe@gmail.com","1582601532","Daniel Borkmann","daniel@iogearbox.net","1582667455","3999130006b4ac5b8593f683765f4feca5e381ad","f1d4884d6871ded0592604b0e72e4a7bd292eab9","virtio_net: Add XDP meta data support Implement support for transferring XDP meta data into skb for virtio_net driver; before calling into the program, xdp.data_meta points to xdp.data, where on program return with pass verdict, we call into skb_metadata_set(). Tested with the script at https://github.com/higebu/virtio_net-xdp-metadata-test. Signed-off-by: Yuya Kusakabe Signed-off-by: Daniel Borkmann Acked-by: Jason Wang Acked-by: Michael S. Tsirkin Link: https://lore.kernel.org/bpf/20200225033212.437563-2-yuya.kusakabe@gmail.com","drivers/net/virtio_net.c | 52 +++++++++++++++++++++++++++++-------------------; 1 file changed, 32 insertions(+), 20 deletions(-)","The commit adds support for XDP metadata handling in the virtio_net driver, enabling metadata transfer to skb within the XDP framework.","XDP,metadata,virtio_net","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.']" +"f1d4884d6871ded0592604b0e72e4a7bd292eab9","f1d4884d6871ded0592604b0e72e4a7bd292eab9","Yuya Kusakabe","yuya.kusakabe@gmail.com","1582601531","Daniel Borkmann","daniel@iogearbox.net","1582667455","8dc007db074025902c81b2d0a43e5df0c9fd0fb1","9fb156bb82a33f01708fbbb8828836a4219efc3d","virtio_net: Keep vnet header zeroed if XDP is loaded for small buffer We do not want to care about the vnet header in receive_small() if XDP is loaded, since we can not know whether or not the packet is modified by XDP. Fixes: f6b10209b90d (""virtio-net: switch to use build_skb() for small buffer"") Signed-off-by: Yuya Kusakabe Signed-off-by: Daniel Borkmann Acked-by: Jason Wang Acked-by: Michael S. Tsirkin Link: https://lore.kernel.org/bpf/20200225033212.437563-1-yuya.kusakabe@gmail.com","drivers/net/virtio_net.c | 4 ++--; 1 file changed, 2 insertions(+), 2 deletions(-)","The commit ensures the vnet header remains zeroed when XDP is loaded in virtio_net for small buffer to handle potential packet modifications by XDP.","vnet header,XDP,virtio_net","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.']" +"9fb156bb82a33f01708fbbb8828836a4219efc3d","9fb156bb82a33f01708fbbb8828836a4219efc3d","Andrii Nakryiko","andriin@fb.com","1582589327","Daniel Borkmann","daniel@iogearbox.net","1582666982","24fd43ddb77218730ed80f56a87ff40a9913eccc","e0360423d0204eb22f97ed89ba56da496bb9a094","selftests/bpf: Print backtrace on SIGSEGV in test_progs Due to various bugs in tests clean up code (usually), if host system is misconfigured, it happens that test_progs will just crash in the middle of running a test with little to no indication of where and why the crash happened. For cases where coredump is not readily available (e.g., inside a CI), it's very helpful to have a stack trace, which lead to crash, to be printed out. This change adds a signal handler that will capture and print out symbolized backtrace: $ sudo ./test_progs -t mmap test_mmap:PASS:skel_open_and_load 0 nsec test_mmap:PASS:bss_mmap 0 nsec test_mmap:PASS:data_mmap 0 nsec Caught signal #11! Stack trace: ./test_progs(crash_handler+0x18)[0x42a888] /lib64/libpthread.so.0(+0xf5d0)[0x7f2aab5175d0] ./test_progs(test_mmap+0x3c0)[0x41f0a0] ./test_progs(main+0x160)[0x407d10] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7f2aab15d3d5] ./test_progs[0x407ebc] [1] 1988412 segmentation fault (core dumped) sudo ./test_progs -t mmap Unfortunately, glibc's symbolization support is unable to symbolize static functions, only global ones will be present in stack trace. But it's still a step forward without adding extra libraries to get a better symbolization. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200225000847.3965188-1-andriin@fb.com","tools/testing/selftests/bpf/Makefile | 2 +-; tools/testing/selftests/bpf/test_progs.c | 25 +++++++++++++++++++++++++; 2 files changed, 26 insertions(+), 1 deletion(-)","Add signal handler to print stack trace on test_progs SEGFAULT for debugging.","signal,backtrace,selftests","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"e0360423d0204eb22f97ed89ba56da496bb9a094","e0360423d0204eb22f97ed89ba56da496bb9a094","Jakub Sitnicki","jakub@cloudflare.com","1582552407","Alexei Starovoitov","ast@kernel.org","1582590916","1c9c7e0962f45a2bddc71ce52d8c6a3ceb474b9e","779e422d11985e408fc148f0cca0f4b403f6c5fa","selftests/bpf: Run SYN cookies with reuseport BPF test only for TCP Currently we run SYN cookies test for all socket types and mark the test as skipped if socket type is not compatible. This causes confusion because skipped test might indicate a problem with the testing environment. Instead, run the test only for the socket type which supports SYN cookies. Also, switch to using designated initializers when setting up tests, so that we can tweak only some test parameters, leaving the rest initialized to default values. Fixes: eecd618b4516 (""selftests/bpf: Mark SYN cookie test skipped for UDP sockets"") Reported-by: Alexei Starovoitov Signed-off-by: Jakub Sitnicki Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200224135327.121542-2-jakub@cloudflare.com",".../testing/selftests/bpf/prog_tests/select_reuseport.c | 17 +++++++++--------; 1 file changed, 9 insertions(+), 8 deletions(-)","Adjusts SYN cookies test in selftests to run exclusively for supported TCP socket type and refines test setup.","SYN,cookies,test","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"779e422d11985e408fc148f0cca0f4b403f6c5fa","779e422d11985e408fc148f0cca0f4b403f6c5fa","Jakub Sitnicki","jakub@cloudflare.com","1582552406","Alexei Starovoitov","ast@kernel.org","1582590916","0fa803d180871f26cfe7181be2b769f8e9ed669b","80a836c2506b2b249a9934fbe373eb7a4a98db86","selftests/bpf: Run reuseport tests only with supported socket types SOCKMAP and SOCKHASH map types can be used with reuseport BPF programs but don't support yet storing UDP sockets. Instead of marking UDP tests with SOCK{MAP,HASH} as skipped, don't run them at all. Skipped test might signal that the test environment is not suitable for running the test, while in reality the functionality is not implemented in the kernel yet. Before: sh# ./test_progs -t select_reuseport … #40 select_reuseport:OK Summary: 1/126 PASSED, 30 SKIPPED, 0 FAILED After: sh# ./test_progs -t select_reuseport … #40 select_reuseport:OK Summary: 1/98 PASSED, 2 SKIPPED, 0 FAILED The remaining two skipped tests are SYN cookies tests, which will be addressed in the subsequent patch. Fixes: 11318ba8cafd (""selftests/bpf: Extend SK_REUSEPORT tests to cover SOCKMAP/SOCKHASH"") Reported-by: Alexei Starovoitov Signed-off-by: Jakub Sitnicki Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200224135327.121542-1-jakub@cloudflare.com","tools/testing/selftests/bpf/prog_tests/select_reuseport.c | 13 ++++++-------; 1 file changed, 6 insertions(+), 7 deletions(-)","This commit modifies BPF reuseport self-tests to avoid running unsupported UDP tests with SOCKMAP and SOCKHASH.","reuseport,self-tests,SOCKMAP","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"80a836c2506b2b249a9934fbe373eb7a4a98db86","80a836c2506b2b249a9934fbe373eb7a4a98db86","Alexei Starovoitov","ast@kernel.org","1582589541","Alexei Starovoitov","ast@kernel.org","1582590010","38d6b44dc8654900cfb0e735cd8d027ce00d4e53","8eece07c011f88da0ccf4127fca9a4e4faaf58ae 099bfaa731ec347d3f16a463ae53b88a1700c0af","Merge branch 'BPF_and_RT' Thomas Gleixner says: ==================== This is the third version of the BPF/RT patch set which makes both coexist nicely. The long explanation can be found in the cover letter of the V1 submission: https://lore.kernel.org/r/20200214133917.304937432@linutronix.de V2 is here: https://lore.kernel.org/r/20200220204517.863202864@linutronix.de The following changes vs. V2 have been made: - Rebased to bpf-next, adjusted to the lock changes in the hashmap code. - Split the preallocation enforcement patch for instrumentation type BPF programs into two pieces: 1) Emit a one-time warning on !RT kernels when any instrumentation type BPF program uses run-time allocation. Emit also a corresponding warning in the verifier log. But allow the program to run for backward compatibility sake. After a grace period this should be enforced. 2) On RT reject such programs because on RT the memory allocator cannot be called from truly atomic contexts. - Fixed the fallout from V2 as reported by Alexei and 0-day - Removed the redundant preempt_disable() from trace_call_bpf() - Removed the unused export of trace_call_bpf() ==================== Signed-off-by: Alexei Starovoitov ","","This commit merges updates for better coexistence of BPF and RT, including lock and memory allocation changes.","BPF,merge,RT","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"099bfaa731ec347d3f16a463ae53b88a1700c0af","099bfaa731ec347d3f16a463ae53b88a1700c0af","David Miller","davem@davemloft.net","1582552913","Alexei Starovoitov","ast@kernel.org","1582590010","38d6b44dc8654900cfb0e735cd8d027ce00d4e53","66150d0dde030c5ee68ccd93e4c54a73c47ebebd","bpf/stackmap: Dont trylock mmap_sem with PREEMPT_RT and interrupts disabled In a RT kernel down_read_trylock() cannot be used from NMI context and up_read_non_owner() is another problematic issue. So in such a configuration, simply elide the annotated stackmap and just report the raw IPs. In the longer term, it might be possible to provide a atomic friendly versions of the page cache traversal which will at least provide the info if the pages are resident and don't need to be paged in. [ tglx: Use IS_ENABLED() to avoid the #ifdeffery, fixup the irq work callback and add a comment ] Signed-off-by: David S. Miller Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145644.708960317@linutronix.de","kernel/bpf/stackmap.c | 18 +++++++++++++++---; 1 file changed, 15 insertions(+), 3 deletions(-)","Fixes stackmap handling in RT kernels by avoiding trylock usage in NMI context.","stackmap RT NMI","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.', 'kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"66150d0dde030c5ee68ccd93e4c54a73c47ebebd","66150d0dde030c5ee68ccd93e4c54a73c47ebebd","Thomas Gleixner","tglx@linutronix.de","1582552912","Alexei Starovoitov","ast@kernel.org","1582590010","0d39c932913bd7bd18238e6cdd60393292c0a0c7","7f805d17f1523c7b2c0da319ddb427d6c5d94ff1","bpf, lpm: Make locking RT friendly The LPM trie map cannot be used in contexts like perf, kprobes and tracing as this map type dynamically allocates memory. The memory allocation happens with a raw spinlock held which is a truly spinning lock on a PREEMPT RT enabled kernel which disables preemption and interrupts. As RT does not allow memory allocation from such a section for various reasons, convert the raw spinlock to a regular spinlock. On a RT enabled kernel these locks are substituted by 'sleeping' spinlocks which provide the proper protection but keep the code preemptible. On a non-RT kernel regular spinlocks map to raw spinlocks, i.e. this does not cause any functional change. Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145644.602129531@linutronix.de","kernel/bpf/lpm_trie.c | 12 ++++++------; 1 file changed, 6 insertions(+), 6 deletions(-)","The commit modifies lock type in the LPM trie map to suit real-time kernel constraints.","LPM, spinlock, RT","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"7f805d17f1523c7b2c0da319ddb427d6c5d94ff1","7f805d17f1523c7b2c0da319ddb427d6c5d94ff1","Thomas Gleixner","tglx@linutronix.de","1582552911","Alexei Starovoitov","ast@kernel.org","1582590010","fb19756b8a5dda36fcba75006c8c2be6391566ad","d01f9b198ca985b49717d8cd0b1f57806cb1319a","bpf: Prepare hashtab locking for PREEMPT_RT PREEMPT_RT forbids certain operations like memory allocations (even with GFP_ATOMIC) from atomic contexts. This is required because even with GFP_ATOMIC the memory allocator calls into code pathes which acquire locks with long held lock sections. To ensure the deterministic behaviour these locks are regular spinlocks, which are converted to 'sleepable' spinlocks on RT. The only true atomic contexts on an RT kernel are the low level hardware handling, scheduling, low level interrupt handling, NMIs etc. None of these contexts should ever do memory allocations. As regular device interrupt handlers and soft interrupts are forced into thread context, the existing code which does spin_lock*(); alloc(GPF_ATOMIC); spin_unlock*(); just works. In theory the BPF locks could be converted to regular spinlocks as well, but the bucket locks and percpu_freelist locks can be taken from arbitrary contexts (perf, kprobes, tracepoints) which are required to be atomic contexts even on RT. These mechanisms require preallocated maps, so there is no need to invoke memory allocations within the lock held sections. BPF maps which need dynamic allocation are only used from (forced) thread context on RT and can therefore use regular spinlocks which in turn allows to invoke memory allocations from the lock held section. To achieve this make the hash bucket lock a union of a raw and a regular spinlock and initialize and lock/unlock either the raw spinlock for preallocated maps or the regular variant for maps which require memory allocations. On a non RT kernel this distinction is neither possible nor required. spinlock maps to raw_spinlock and the extra code and conditional is optimized out by the compiler. No functional change. Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145644.509685912@linutronix.de","kernel/bpf/hashtab.c | 65 ++++++++++++++++++++++++++++++++++++++++++++--------; 1 file changed, 56 insertions(+), 9 deletions(-)","Adjusts BPF hash table locking to accommodate real-time kernel requirements without functional changes.","PREEMPT_RT,spinlocks,hashtab","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"d01f9b198ca985b49717d8cd0b1f57806cb1319a","d01f9b198ca985b49717d8cd0b1f57806cb1319a","Thomas Gleixner","tglx@linutronix.de","1582552910","Alexei Starovoitov","ast@kernel.org","1582590010","2c04f166fcf15540ae2183b0e089425a57bd41e9","b6e5dae15a61b0cc9219799926813baad0b58967","bpf: Factor out hashtab bucket lock operations As a preparation for making the BPF locking RT friendly, factor out the hash bucket lock operations into inline functions. This allows to do the necessary RT modification in one place instead of sprinkling it all over the place. No functional change. The now unused htab argument of the lock/unlock functions will be used in the next step which adds PREEMPT_RT support. Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145644.420416916@linutronix.de","kernel/bpf/hashtab.c | 69 ++++++++++++++++++++++++++++++++++------------------; 1 file changed, 46 insertions(+), 23 deletions(-)","The commit factors out hash bucket lock operations into inline functions for RT friendliness without functional changes.","hashbucket,lock,RT","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"b6e5dae15a61b0cc9219799926813baad0b58967","b6e5dae15a61b0cc9219799926813baad0b58967","Thomas Gleixner","tglx@linutronix.de","1582552909","Alexei Starovoitov","ast@kernel.org","1582590010","54d5a5804fe457956725474e079ec989054cba3c","085fee1a72a9fba101a4a68a2c02fa8bd2b6f913","bpf: Replace open coded recursion prevention in sys_bpf() The required protection is that the caller cannot be migrated to a different CPU as these functions end up in places which take either a hash bucket lock or might trigger a kprobe inside the memory allocator. Both scenarios can lead to deadlocks. The deadlock prevention is per CPU by incrementing a per CPU variable which temporarily blocks the invocation of BPF programs from perf and kprobes. Replace the open coded preempt_[dis|en]able and __this_cpu_[inc|dec] pairs with the new helper functions. These functions are already prepared to make BPF work on PREEMPT_RT enabled kernels. No functional change for !RT kernels. Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145644.317843926@linutronix.de","kernel/bpf/syscall.c | 27 ++++++++-------------------; 1 file changed, 8 insertions(+), 19 deletions(-)","Refactors sys_bpf by replacing custom recursion prevention with helper functions for enhanced RT kernel compatibility.","recursion,prevention,sys_bpf","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The syscall interface. It changes the system calls through which user-space programs interact with eBPF.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"085fee1a72a9fba101a4a68a2c02fa8bd2b6f913","085fee1a72a9fba101a4a68a2c02fa8bd2b6f913","Thomas Gleixner","tglx@linutronix.de","1582552908","Alexei Starovoitov","ast@kernel.org","1582590010","e215f625f6ca1185cd82d9fd65a2585c109f6b5d","c518cfa0c5ad75ddf3d743f1e35b9cf5fc2c346e","bpf: Use recursion prevention helpers in hashtab code The required protection is that the caller cannot be migrated to a different CPU as these places take either a hash bucket lock or might trigger a kprobe inside the memory allocator. Both scenarios can lead to deadlocks. The deadlock prevention is per CPU by incrementing a per CPU variable which temporarily blocks the invocation of BPF programs from perf and kprobes. Replace the open coded preempt_disable/enable() and this_cpu_inc/dec() pairs with the new recursion prevention helpers to prepare BPF to work on PREEMPT_RT enabled kernels. On a non-RT kernel the migrate disable/enable in the helpers map to preempt_disable/enable(), i.e. no functional change. Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145644.211208533@linutronix.de","kernel/bpf/hashtab.c | 12 ++++--------; 1 file changed, 4 insertions(+), 8 deletions(-)","The commit updates bpf hashtab code using recursion prevention helpers to enhance PREEMPT_RT kernel compatibility.","recursion prevention, kernel compatibility, hashtab","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"c518cfa0c5ad75ddf3d743f1e35b9cf5fc2c346e","c518cfa0c5ad75ddf3d743f1e35b9cf5fc2c346e","Thomas Gleixner","tglx@linutronix.de","1582552907","Alexei Starovoitov","ast@kernel.org","1582590009","dc1af99817725ada8e5cae4c91e49dd113d41d0b","2a916f2f546ca1c1e3323e2a4269307f6d9890eb","bpf: Provide recursion prevention helpers The places which need to prevent the execution of trace type BPF programs to prevent deadlocks on the hash bucket lock do this open coded. Provide two inline functions, bpf_disable/enable_instrumentation() to replace these open coded protection constructs. Use migrate_disable/enable() instead of preempt_disable/enable() right away so this works on RT enabled kernels. On a !RT kernel migrate_disable / enable() are mapped to preempt_disable/enable(). These helpers use this_cpu_inc/dec() instead of __this_cpu_inc/dec() on an RT enabled kernel because migrate disabled regions are preemptible and preemption might hit in the middle of a RMW operation which can lead to inconsistent state. Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145644.103910133@linutronix.de","include/linux/bpf.h | 30 ++++++++++++++++++++++++++++++; 1 file changed, 30 insertions(+)","The commit adds inline functions to prevent deadlocks in trace type BPF programs by managing recursion prevention and instrumentation.","recursion, helpers, deadlocks","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.', 'kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.', ""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"2a916f2f546ca1c1e3323e2a4269307f6d9890eb","2a916f2f546ca1c1e3323e2a4269307f6d9890eb","David Miller","davem@davemloft.net","1582552906","Alexei Starovoitov","ast@kernel.org","1582590009","55001914de022407ab96c717dc6ba7aa90e124f1","02ad05965491ca72034327d47da6cb25f3a92603","bpf: Use migrate_disable/enable in array macros and cgroup/lirc code. Replace the preemption disable/enable with migrate_disable/enable() to reflect the actual requirement and to allow PREEMPT_RT to substitute it with an actual migration disable mechanism which does not disable preemption. Including the code paths that go via __bpf_prog_run_save_cb(). Signed-off-by: David S. Miller Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145643.998293311@linutronix.de","include/linux/bpf.h | 8 ++++----; include/linux/filter.h | 5 +++--; 2 files changed, 7 insertions(+), 6 deletions(-)","Replace preemption disable with migrate_disable in BPF array macros and cgroup/lirc code.","migrate_disable,array,cgroup","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups).', ""I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear."", ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"02ad05965491ca72034327d47da6cb25f3a92603","02ad05965491ca72034327d47da6cb25f3a92603","David Miller","davem@davemloft.net","1582552905","Alexei Starovoitov","ast@kernel.org","1582590009","3acf6c839448a780cf43252693653245f3cf51eb","6eac7795e8ef75de062c8f5bdb9520c9f0f065fa","bpf: Use migrate_disable/enabe() in trampoline code. Instead of preemption disable/enable to reflect the purpose. This allows PREEMPT_RT to substitute it with an actual migration disable implementation. On non RT kernels this is still mapped to preempt_disable/enable(). Signed-off-by: David S. Miller Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145643.891428873@linutronix.de","kernel/bpf/trampoline.c | 9 +++++----; 1 file changed, 5 insertions(+), 4 deletions(-)","This commit updates trampoline code to use migrate_disable/enable for better PREEMPT_RT compatibility.","trampoline migrate_disable PREEMPT_RT","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"6eac7795e8ef75de062c8f5bdb9520c9f0f065fa","6eac7795e8ef75de062c8f5bdb9520c9f0f065fa","David Miller","davem@davemloft.net","1582552904","Alexei Starovoitov","ast@kernel.org","1582590009","9ee0bb821124197be995ccbf76cead42a92c0581","3d9f773cf2876c01a505b9fe27270901d464e90a","bpf/tests: Use migrate disable instead of preempt disable Replace the preemption disable/enable with migrate_disable/enable() to reflect the actual requirement and to allow PREEMPT_RT to substitute it with an actual migration disable mechanism which does not disable preemption. [ tglx: Switched it over to migrate disable ] Signed-off-by: David S. Miller Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145643.785306549@linutronix.de","lib/test_bpf.c | 4 ++--; net/bpf/test_run.c | 8 ++++----; 2 files changed, 6 insertions(+), 6 deletions(-)","The commit updates eBPF tests to use migrate_disable instead of preempt_disable to improve PREEMPT_RT support.","migrate, preempt, tests","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"3d9f773cf2876c01a505b9fe27270901d464e90a","3d9f773cf2876c01a505b9fe27270901d464e90a","David Miller","davem@davemloft.net","1582552903","Alexei Starovoitov","ast@kernel.org","1582590009","d5ed0350db81b38cf8c0234d7c066f65595addff","37e1d9202225635772b32e340294208367279c2b","bpf: Use bpf_prog_run_pin_on_cpu() at simple call sites. All of these cases are strictly of the form: preempt_disable(); BPF_PROG_RUN(...); preempt_enable(); Replace this with bpf_prog_run_pin_on_cpu() which wraps BPF_PROG_RUN() with: migrate_disable(); BPF_PROG_RUN(...); migrate_enable(); On non RT enabled kernels this maps to preempt_disable/enable() and on RT enabled kernels this solely prevents migration, which is sufficient as there is no requirement to prevent reentrancy to any BPF program from a preempting task. The only requirement is that the program stays on the same CPU. Therefore, this is a trivially correct transformation. The seccomp loop does not need protection over the loop. It only needs protection per BPF filter program [ tglx: Converted to bpf_prog_run_pin_on_cpu() ] Signed-off-by: David S. Miller Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145643.691493094@linutronix.de","include/linux/filter.h | 4 +---; kernel/seccomp.c | 4 +---; net/core/flow_dissector.c | 4 +---; net/core/skmsg.c | 8 ++------; net/kcm/kcmsock.c | 4 +---; 5 files changed, 6 insertions(+), 18 deletions(-)","The commit uses bpf_prog_run_pin_on_cpu() for CPU-specific eBPF execution, enhancing consistency across kernel configurations.","bpf, CPU, refactoring","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"37e1d9202225635772b32e340294208367279c2b","37e1d9202225635772b32e340294208367279c2b","Thomas Gleixner","tglx@linutronix.de","1582552902","Alexei Starovoitov","ast@kernel.org","1582590009","fa994e5de8abf9a7007d9a11d67460b78cdefa2a","3c58482a382bae89410439247152eb342e9872f7","bpf: Replace cant_sleep() with cant_migrate() As already discussed in the previous change which introduced BPF_RUN_PROG_PIN_ON_CPU() BPF only requires to disable migration to guarantee per CPUness. If RT substitutes the preempt disable based migration protection then the cant_sleep() check will obviously trigger as preemption is not disabled. Replace it by cant_migrate() which maps to cant_sleep() on a non RT kernel and will verify that migration is disabled on a full RT kernel. Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145643.583038889@linutronix.de","include/linux/filter.h | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","Replace cant_sleep() with cant_migrate() for handling CPU migration in BPF programs.","cant_sleep,cant_migrate,BPF","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"3c58482a382bae89410439247152eb342e9872f7","3c58482a382bae89410439247152eb342e9872f7","Thomas Gleixner","tglx@linutronix.de","1582552901","Alexei Starovoitov","ast@kernel.org","1582590005","36943f70dc78e8dae90117db6dd41c6ceaf233b0","569de905ebc30b9c61be7aa557403aeb5a9141a4","bpf: Provide bpf_prog_run_pin_on_cpu() helper BPF programs require to run on one CPU to completion as they use per CPU storage, but according to Alexei they don't need reentrancy protection as obviously BPF programs running in thread context can always be 'preempted' by hard and soft interrupts and instrumentation and the same program can run concurrently on a different CPU. The currently used mechanism to ensure CPUness is to wrap the invocation into a preempt_disable/enable() pair. Disabling preemption is also disabling migration for a task. preempt_disable/enable() is used because there is no explicit way to reliably disable only migration. Provide a separate macro to invoke a BPF program which can be used in migrateable task context. It wraps BPF_PROG_RUN() in a migrate_disable/enable() pair which maps on non RT enabled kernels to preempt_disable/enable(). On RT enabled kernels this merely disables migration. Both methods ensure that the invoked BPF program runs on one CPU to completion. Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145643.474592620@linutronix.de","include/linux/filter.h | 26 ++++++++++++++++++++++++--; 1 file changed, 24 insertions(+), 2 deletions(-)","This commit introduces bpf_prog_run_pin_on_cpu to ensure BPF programs run on a single CPU by disabling migration effectively.","bpf, migration, cpu","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"569de905ebc30b9c61be7aa557403aeb5a9141a4","569de905ebc30b9c61be7aa557403aeb5a9141a4","Thomas Gleixner","tglx@linutronix.de","1582552900","Alexei Starovoitov","ast@kernel.org","1582589900","bb943982c132511cddfc78844fa10bfbb35dc50c","8a37963c7ac9ecb7f86f8ebda020e3f8d6d7b8a0","bpf: Dont iterate over possible CPUs with interrupts disabled pcpu_freelist_populate() is disabling interrupts and then iterates over the possible CPUs. The reason why this disables interrupts is to silence lockdep because the invoked ___pcpu_freelist_push() takes spin locks. Neither the interrupt disabling nor the locking are required in this function because it's called during initialization and the resulting map is not yet visible to anything. Split out the actual push assignement into an inline, call it from the loop and remove the interrupt disable. Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145643.365930116@linutronix.de","kernel/bpf/percpu_freelist.c | 20 ++++++++++----------; 1 file changed, 10 insertions(+), 10 deletions(-)","The commit refactors percpu_freelist to eliminate unnecessary interrupt disabling during the initialization phase.","interrupts, initialization, percpu_freelist","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"8a37963c7ac9ecb7f86f8ebda020e3f8d6d7b8a0","8a37963c7ac9ecb7f86f8ebda020e3f8d6d7b8a0","Thomas Gleixner","tglx@linutronix.de","1582552899","Alexei Starovoitov","ast@kernel.org","1582589900","ee849da409619592dbcaf62bdda95f53bcfdbb99","1d7bf6b7d3e8353c3fac648f3f9b3010458570c2","bpf: Remove recursion prevention from rcu free callback If an element is freed via RCU then recursion into BPF instrumentation functions is not a concern. The element is already detached from the map and the RCU callback does not hold any locks on which a kprobe, perf event or tracepoint attached BPF program could deadlock. Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145643.259118710@linutronix.de","kernel/bpf/hashtab.c | 8 --------; 1 file changed, 8 deletions(-)","The commit removes unnecessary recursion prevention from the RCU free callback in BPF maps, enhancing map management without deadlock risks.","recursion,RCU,BPF","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"1d7bf6b7d3e8353c3fac648f3f9b3010458570c2","1d7bf6b7d3e8353c3fac648f3f9b3010458570c2","Thomas Gleixner","tglx@linutronix.de","1582552898","Alexei Starovoitov","ast@kernel.org","1582589900","78fa90b9a7793a15078ea197fc19afb96539e356","b0a81b94cc50a112601721fcc2f91fab78d7b9f3","perf/bpf: Remove preempt disable around BPF invocation The BPF invocation from the perf event overflow handler does not require to disable preemption because this is called from NMI or at least hard interrupt context which is already non-preemptible. Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145643.151953573@linutronix.de","kernel/events/core.c | 2 --; 1 file changed, 2 deletions(-)","The commit removes redundant preemption disabling in the BPF call from the perf event overflow handler.","perf,BPF,preemption","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"b0a81b94cc50a112601721fcc2f91fab78d7b9f3","b0a81b94cc50a112601721fcc2f91fab78d7b9f3","Thomas Gleixner","tglx@linutronix.de","1582552897","Alexei Starovoitov","ast@kernel.org","1582589900","f4d7b2395896a53576f2743900dfb102ee86e261","70ed0706a48e3da3eb4515214fef658ff1184b9f","bpf/trace: Remove redundant preempt_disable from trace_call_bpf() Similar to __bpf_trace_run this is redundant because __bpf_trace_run() is invoked from a trace point via __DO_TRACE() which already disables preemption _before_ invoking any of the functions which are attached to a trace point. Remove it and add a cant_sleep() check. Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145643.059995527@linutronix.de","kernel/trace/bpf_trace.c | 3 +--; 1 file changed, 1 insertion(+), 2 deletions(-)","This commit removes redundant preemption logic from a tracing function in the eBPF trace code.","preempt_disable,trace_call_bpf,cant_sleep","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime."", ""It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here.""]" +"70ed0706a48e3da3eb4515214fef658ff1184b9f","70ed0706a48e3da3eb4515214fef658ff1184b9f","Alexei Starovoitov","ast@kernel.org","1582572435","Alexei Starovoitov","ast@kernel.org","1582589834","5386280db17266282a2020c44e3a15c47c484e6b","1b7a51a63b031092b8b8acda3f6820b62a8b5e5d","bpf: disable preemption for bpf progs attached to uprobe trace_call_bpf() no longer disables preemption on its own. All callers of this function has to do it explicitly. Signed-off-by: Alexei Starovoitov Acked-by: Thomas Gleixner ","kernel/trace/trace_uprobe.c | 11 +++++++++--; 1 file changed, 9 insertions(+), 2 deletions(-)","This commit changes preemption handling for BPF programs attached to uprobes, requiring explicit disabling by callers.","preemption,uprobes,bpf","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['uprobe/usdt like type user-space dynamic probe programs. It impacts user-space probes for tracing user-space applications. It can be other user-space probes in perf-events.']" +"1b7a51a63b031092b8b8acda3f6820b62a8b5e5d","1b7a51a63b031092b8b8acda3f6820b62a8b5e5d","Thomas Gleixner","tglx@linutronix.de","1582552896","Alexei Starovoitov","ast@kernel.org","1582589798","b63b23e6a969477d6d29cdf4d4b8759f15aed015","f03efe49bd16c017107ff5079d08ea428e390dde","bpf/trace: Remove EXPORT from trace_call_bpf() All callers are built in. No point to export this. Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov ","kernel/trace/bpf_trace.c | 1 -; 1 file changed, 1 deletion(-)","Removed export of trace_call_bpf() as all callers are built-in.","trace_call_bpf, remove, export","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime."", ""I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear.""]" +"f03efe49bd16c017107ff5079d08ea428e390dde","f03efe49bd16c017107ff5079d08ea428e390dde","Thomas Gleixner","tglx@linutronix.de","1582552895","Alexei Starovoitov","ast@kernel.org","1582589540","50cd6a079cead0ca2eb56fd805f860599238eaaf","dbca151cad736c99f4817076daf9fd02ed0c2daa","bpf/tracing: Remove redundant preempt_disable() in __bpf_trace_run() __bpf_trace_run() disables preemption around the BPF_PROG_RUN() invocation. This is redundant because __bpf_trace_run() is invoked from a trace point via __DO_TRACE() which already disables preemption _before_ invoking any of the functions which are attached to a trace point. Remove it and add a cant_sleep() check. Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145642.847220186@linutronix.de","kernel/trace/bpf_trace.c | 3 +--; 1 file changed, 1 insertion(+), 2 deletions(-)","The commit removes redundant preemption disabling in __bpf_trace_run and adds a cant_sleep check in the bpf tracing code.","preemption,tracing,__bpf_trace_run","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.']" +"dbca151cad736c99f4817076daf9fd02ed0c2daa","dbca151cad736c99f4817076daf9fd02ed0c2daa","Thomas Gleixner","tglx@linutronix.de","1582552894","Alexei Starovoitov","ast@kernel.org","1582589540","1c700844ea53f82eec530d9fdf37d7776f9938df","2ed905c521e56aead6987df94c083efb0ee59895","bpf: Update locking comment in hashtab code The comment where the bucket lock is acquired says: /* bpf_map_update_elem() can be called in_irq() */ which is not really helpful and aside of that it does not explain the subtle details of the hash bucket locks expecially in the context of BPF and perf, kprobes and tracing. Add a comment at the top of the file which explains the protection scopes and the details how potential deadlocks are prevented. Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145642.755793061@linutronix.de","kernel/bpf/hashtab.c | 24 ++++++++++++++++++++----; 1 file changed, 20 insertions(+), 4 deletions(-)","This commit updates the locking comment in the eBPF hashtab code to clarify protection scopes and prevent potential deadlocks.","locking,hashtab,comment","A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"2ed905c521e56aead6987df94c083efb0ee59895","2ed905c521e56aead6987df94c083efb0ee59895","Thomas Gleixner","tglx@linutronix.de","1582552893","Alexei Starovoitov","ast@kernel.org","1582589539","da9db871359f60fed6910b5df34298e5ecada9a6","94dacdbd5d2dfa2cffd308f128d78c99f855f5be","bpf: Enforce preallocation for instrumentation programs on RT Aside of the general unsafety of run-time map allocation for instrumentation type programs RT enabled kernels have another constraint: The instrumentation programs are invoked with preemption disabled, but the memory allocator spinlocks cannot be acquired in atomic context because they are converted to 'sleeping' spinlocks on RT. Therefore enforce map preallocation for these programs types when RT is enabled. Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145642.648784007@linutronix.de","kernel/bpf/verifier.c | 13 +++++++++----; 1 file changed, 9 insertions(+), 4 deletions(-)","The commit enforces map preallocation for instrumentation programs when real-time (RT) is enabled to prevent unsafe memory allocator usage.","preallocation,instrumentation,RT","A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.', 'kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"94dacdbd5d2dfa2cffd308f128d78c99f855f5be","94dacdbd5d2dfa2cffd308f128d78c99f855f5be","Thomas Gleixner","tglx@linutronix.de","1582552892","Alexei Starovoitov","ast@kernel.org","1582589539","5413c0a6b7298c349c1024711df31692c91d1d8d","8eece07c011f88da0ccf4127fca9a4e4faaf58ae","bpf: Tighten the requirements for preallocated hash maps The assumption that only programs attached to perf NMI events can deadlock on memory allocators is wrong. Assume the following simplified callchain: kmalloc() from regular non BPF context cache empty freelist empty lock(zone->lock); tracepoint or kprobe BPF() update_elem() lock(bucket) kmalloc() cache empty freelist empty lock(zone->lock); <- DEADLOCK There are other ways which do not involve locking to create wreckage: kmalloc() from regular non BPF context local_irq_save(); ... obj = slab_first(); kprobe() BPF() update_elem() lock(bucket) kmalloc() local_irq_save(); ... obj = slab_first(); <- Same object as above ... So preallocation _must_ be enforced for all variants of intrusive instrumentation. Unfortunately immediate enforcement would break backwards compatibility, so for now such programs still are allowed to run, but a one time warning is emitted in dmesg and the verifier emits a warning in the verifier log as well so developers are made aware about this and can fix their programs before the enforcement becomes mandatory. Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145642.540542802@linutronix.de","kernel/bpf/verifier.c | 39 ++++++++++++++++++++++++++++-----------; 1 file changed, 28 insertions(+), 11 deletions(-)","This commit tightens requirements for preallocated hash maps to prevent deadlocks in non-BPF contexts while issuing warnings for backward compatibility.","preallocated, deadlock, warnings","A bug fix. It primarily resolves a bug or issue in the code.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime."", ""I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear.""]" +"8eece07c011f88da0ccf4127fca9a4e4faaf58ae","8eece07c011f88da0ccf4127fca9a4e4faaf58ae","Alexei Starovoitov","ast@kernel.org","1582338467","Alexei Starovoitov","ast@kernel.org","1582338467","f4cd731284fc654cdd7ddfab41b07e1599d8084b","732a0dee501f9a693c9a711730838129f4587041 4e139c7711633365ebb52fbb63905395522a8413","Merge tag 'sched-for-bpf-2020-02-20' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip into bpf-next Two migrate disable related stubs for BPF to base the RT patches on","","This commit merges the 'sched-for-bpf-2020-02-20' tag from the tip tree into the bpf-next branch.","merge, sched, bpf","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"b105e8e281ac2dbea4229982ad57fbefab05963d","b105e8e281ac2dbea4229982ad57fbefab05963d","David S. Miller","davem@davemloft.net","1582327365","David S. Miller","davem@davemloft.net","1582327365","58ea551205dd646d809c789fccb2381b60b00d9e","e65ee2fb54d4745d7b7d9061d7fe33c5c5bf3b06 eb1e1478b6f4e70d99fee3f49bb7f7143c8c871d","Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next Daniel Borkmann says: ==================== pull-request: bpf-next 2020-02-21 The following pull-request contains BPF updates for your *net-next* tree. We've added 25 non-merge commits during the last 4 day(s) which contain a total of 33 files changed, 2433 insertions(+), 161 deletions(-). The main changes are: 1) Allow for adding TCP listen sockets into sock_map/hash so they can be used with reuseport BPF programs, from Jakub Sitnicki. 2) Add a new bpf_program__set_attach_target() helper for adding libbpf support to specify the tracepoint/function dynamically, from Eelco Chaudron. 3) Add bpf_read_branch_records() BPF helper which helps use cases like profile guided optimizations, from Daniel Xu. 4) Enable bpf_perf_event_read_value() in all tracing programs, from Song Liu. 5) Relax BTF mandatory check if only used for libbpf itself e.g. to process BTF defined maps, from Andrii Nakryiko. 6) Move BPF selftests -mcpu compilation attribute from 'probe' to 'v3' as it has been observed that former fails in envs with low memlock, from Yonghong Song. ==================== Signed-off-by: David S. Miller ","","This commit merges bpf-next updates into net-next containing various BPF enhancements and features.","merge,bpf,next","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"eb1e1478b6f4e70d99fee3f49bb7f7143c8c871d","eb1e1478b6f4e70d99fee3f49bb7f7143c8c871d","Daniel Borkmann","daniel@iogearbox.net","1582320586","Daniel Borkmann","daniel@iogearbox.net","1582320701","5273ac46e99e0b7e9e101e40adb370ba306e3fd9","e42da4c62abb547d9c9138e0e7fcd1f36057b5e8 44d28be2b8d41e3198052b8c9eded2e23eb9e08b","Merge branch 'bpf-sockmap-listen' Jakub Sitnicki says: ==================== This patch set turns SOCK{MAP,HASH} into generic collections for TCP sockets, both listening and established. Adding support for listening sockets enables us to use these BPF map types with reuseport BPF programs. Why? SOCKMAP and SOCKHASH, in comparison to REUSEPORT_SOCKARRAY, allow the socket to be in more than one map at the same time. Having a BPF map type that can hold listening sockets, and gracefully co-exist with reuseport BPF is important if, in the future, we want BPF programs that run at socket lookup time [0]. Cover letter for v1 of this series tells the full story of how we got here [1]. Although SOCK{MAP,HASH} are not a drop-in replacement for SOCKARRAY just yet, because UDP support is lacking, it's a step in this direction. We're working with Lorenz on extending SOCK{MAP,HASH} to hold UDP sockets, and expect to post RFC series for sockmap + UDP in the near future. I've dropped Acks from all patches that have been touched since v6. The audit for missing READ_ONCE annotations for access to sk_prot is ongoing. Thus far I've found one location specific to TCP listening sockets that needed annotating. This got fixed it in this iteration. I wonder if sparse checker could be put to work to identify places where we have sk_prot access while not holding sk_lock... The patch series depends on another one, posted earlier [2], that has been split out of it. v6 -> v7: - Extended the series to cover SOCKHASH. (patches 4-8, 10-11) (John) - Rebased onto recent bpf-next. Resolved conflicts in recent fixes to sk_state checks on sockmap/sockhash update path. (patch 4) - Added missing READ_ONCE annotation in sock_copy. (patch 1) - Split out patches that simplify sk_psock_restore_proto [2]. v5 -> v6: - Added a fix-up for patch 1 which I forgot to commit in v5. Sigh. v4 -> v5: - Rebase onto recent bpf-next to resolve conflicts. (Daniel) v3 -> v4: - Make tcp_bpf_clone parameter names consistent across function declaration and definition. (Martin) - Use sock_map_redirect_okay helper everywhere we need to take a different action for listening sockets. (Lorenz) - Expand comment explaining the need for a callback from reuseport to sockarray code in reuseport_detach_sock. (Martin) - Mention the possibility of using a u64 counter for reuseport IDs in the future in the description for patch 10. (Martin) v2 -> v3: - Generate reuseport ID when group is created. Please see patch 10 description for details. (Martin) - Fix the build when CONFIG_NET_SOCK_MSG is not selected by either CONFIG_BPF_STREAM_PARSER or CONFIG_TLS. (kbuild bot & John) - Allow updating sockmap from BPF on BPF_SOCK_OPS_TCP_LISTEN_CB callback. An oversight in previous iterations. Users may want to populate the sockmap with listening sockets from BPF as well. - Removed RCU read lock assertion in sock_map_lookup_sys. (Martin) - Get rid of a warning when child socket was cloned with parent's psock state. (John) - Check for tcp_bpf_unhash rather than tcp_bpf_recvmsg when deciding if sk_proto needs restoring on clone. Check for recvmsg in the context of listening socket cloning was confusing. (Martin) - Consolidate sock_map_sk_is_suitable with sock_map_update_okay. This led to adding dedicated predicates for sockhash. Update self-tests accordingly. (John) - Annotate unlikely branch in bpf_{sk,msg}_redirect_map when socket isn't in a map, or isn't a valid redirect target. (John) - Document paired READ/WRITE_ONCE annotations and cover shared access in more detail in patch 2 description. (John) - Correct a couple of log messages in sockmap_listen self-tests so the message reflects the actual failure. - Rework reuseport tests from sockmap_listen suite so that ENOENT error from bpf_sk_select_reuseport handler does not happen on happy path. v1 -> v2: - af_ops->syn_recv_sock callback is no longer overridden and burdened with restoring sk_prot and clearing sk_user_data in the child socket. As child socket is already hashed when syn_recv_sock returns, it is too late to put it in the right state. Instead patches 3 & 4 address restoring sk_prot and clearing sk_user_data before we hash the child socket. (Pointed out by Martin Lau) - Annotate shared access to sk->sk_prot with READ_ONCE/WRITE_ONCE macros as we write to it from sk_msg while socket might be getting cloned on another CPU. (Suggested by John Fastabend) - Convert tests for SOCKMAP holding listening sockets to return-on-error style, and hook them up to test_progs. Also use BPF skeleton for setup. Add new tests to cover the race scenario discovered during v1 review. RFC -> v1: - Switch from overriding proto->accept to af_ops->syn_recv_sock, which happens earlier. Clearing the psock state after accept() does not work for child sockets that become orphaned (never got accepted). v4-mapped sockets need special care. - Return the socket cookie on SOCKMAP lookup from syscall to be on par with REUSEPORT_SOCKARRAY. Requires SOCKMAP to take u64 on lookup/update from syscall. - Make bpf_sk_redirect_map (ingress) and bpf_msg_redirect_map (egress) SOCKMAP helpers fail when target socket is a listening one. - Make bpf_sk_select_reuseport helper fail when target is a TCP established socket. - Teach libbpf to recognize SK_REUSEPORT program type from section name. - Add a dedicated set of tests for SOCKMAP holding listening sockets, covering map operations, overridden socket callbacks, and BPF helpers. [0] https://lore.kernel.org/bpf/20190828072250.29828-1-jakub@cloudflare.com/ [1] https://lore.kernel.org/bpf/20191123110751.6729-1-jakub@cloudflare.com/ [2] https://lore.kernel.org/bpf/20200217121530.754315-1-jakub@cloudflare.com/ ==================== Signed-off-by: Daniel Borkmann ","","This commit merges changes enabling SOCKMAP and SOCKHASH to support listening TCP sockets, enhancing BPF program capabilities for socket lookup and reuseport scenarios.","SOCKMAP,SOCKHASH,reuseport","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.', ""It's likely a merge commit. It involves changes across multiple use cases or events."", ""I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear.""]" +"44d28be2b8d41e3198052b8c9eded2e23eb9e08b","44d28be2b8d41e3198052b8c9eded2e23eb9e08b","Jakub Sitnicki","jakub@cloudflare.com","1582045823","Daniel Borkmann","daniel@iogearbox.net","1582320586","5273ac46e99e0b7e9e101e40adb370ba306e3fd9","11318ba8cafd59105637b2b82b8a32719e44a2d2","selftests/bpf: Tests for sockmap/sockhash holding listening sockets Now that SOCKMAP and SOCKHASH map types can store listening sockets, user-space and BPF API is open to a new set of potential pitfalls. Exercise the map operations, with extra attention to code paths susceptible to races between map ops and socket cloning, and BPF helpers that work with SOCKMAP/SOCKHASH to gain confidence that all works as expected. Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200218171023.844439-12-jakub@cloudflare.com",".../selftests/bpf/prog_tests/sockmap_listen.c | 1496 ++++++++++++++++++++; .../selftests/bpf/progs/test_sockmap_listen.c | 98 ++; 2 files changed, 1594 insertions(+)","Add selftests to verify sockmap and sockhash functionality with listening sockets, targeting race conditions and socket cloning issues.","selftests,sockmap,listening","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime."", ""I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear.""]" +"11318ba8cafd59105637b2b82b8a32719e44a2d2","11318ba8cafd59105637b2b82b8a32719e44a2d2","Jakub Sitnicki","jakub@cloudflare.com","1582045822","Daniel Borkmann","daniel@iogearbox.net","1582320585","c563226648eec517924dd38d80970ffacd337992","035ff358f2d9e2f5e1639ba4defe4dc40ac642dd","selftests/bpf: Extend SK_REUSEPORT tests to cover SOCKMAP/SOCKHASH Parametrize the SK_REUSEPORT tests so that the map type for storing sockets is not hard-coded in the test setup routine. This, together with careful state cleaning after the tests, lets us run the test cases for REUSEPORT_ARRAY, SOCKMAP, and SOCKHASH to have test coverage for all supported map types. The last two support only TCP sockets at the moment. Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200218171023.844439-11-jakub@cloudflare.com",".../selftests/bpf/prog_tests/select_reuseport.c | 63 ++++++++++++++++++----; 1 file changed, 53 insertions(+), 10 deletions(-)","The commit extends SK_REUSEPORT test coverage to include SOCKMAP and SOCKHASH types by parameterizing the map type.","SK_REUSEPORT, SOCKMAP, SOCKHASH","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"035ff358f2d9e2f5e1639ba4defe4dc40ac642dd","035ff358f2d9e2f5e1639ba4defe4dc40ac642dd","Jakub Sitnicki","jakub@cloudflare.com","1582045821","Daniel Borkmann","daniel@iogearbox.net","1582320585","9ba549b82970dc38600b173ac2c17d8b0501c7f5","9fed9000c5c6cacfcaaa48aff74818072ae294cc","net: Generate reuseport group ID on group creation Commit 736b46027eb4 (""net: Add ID (if needed) to sock_reuseport and expose reuseport_lock"") has introduced lazy generation of reuseport group IDs that survive group resize. By comparing the identifier we check if BPF reuseport program is not trying to select a socket from a BPF map that belongs to a different reuseport group than the one the packet is for. Because SOCKARRAY used to be the only BPF map type that can be used with reuseport BPF, it was possible to delay the generation of reuseport group ID until a socket from the group was inserted into BPF map for the first time. Now that SOCK{MAP,HASH} can be used with reuseport BPF we have two options, either generate the reuseport ID on map update, like SOCKARRAY does, or allocate an ID from the start when reuseport group gets created. This patch takes the latter approach to keep sockmap free of calls into reuseport code. This streamlines the reuseport_id access as its lifetime now matches the longevity of reuseport object. The cost of this simplification, however, is that we allocate reuseport IDs for all SO_REUSEPORT users. Even those that don't use SOCKARRAY in their setups. With the way identifiers are currently generated, we can have at most S32_MAX reuseport groups, which hopefully is sufficient. If we ever get close to the limit, we can switch an u64 counter like sk_cookie. Another change is that we now always call into SOCKARRAY logic to unlink the socket from the map when unhashing or closing the socket. Previously we did it only when at least one socket from the group was in a BPF map. It is worth noting that this doesn't conflict with sockmap tear-down in case a socket is in a SOCK{MAP,HASH} and belongs to a reuseport group. sockmap tear-down happens first: prot->unhash `- tcp_bpf_unhash |- tcp_bpf_remove | `- while (sk_psock_link_pop(psock)) | `- sk_psock_unlink | `- sock_map_delete_from_link | `- __sock_map_delete | `- sock_map_unref | `- sk_psock_put | `- sk_psock_drop | `- rcu_assign_sk_user_data(sk, NULL) `- inet_unhash `- reuseport_detach_sock `- bpf_sk_reuseport_detach `- WRITE_ONCE(sk->sk_user_data, NULL) Suggested-by: Martin Lau Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200218171023.844439-10-jakub@cloudflare.com","include/net/sock_reuseport.h | 2 --; kernel/bpf/reuseport_array.c | 5 -----; net/core/filter.c | 12 +----------; net/core/sock_reuseport.c | 50 +++++++++++++++++++-------------------------; 4 files changed, 22 insertions(+), 47 deletions(-)","The commit generates reuseport group IDs during group creation to streamline reuseport ID access and avoid calls into reuseport code by sockmap.","reuseport, group, ID","A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"9fed9000c5c6cacfcaaa48aff74818072ae294cc","9fed9000c5c6cacfcaaa48aff74818072ae294cc","Jakub Sitnicki","jakub@cloudflare.com","1582045820","Daniel Borkmann","daniel@iogearbox.net","1582320585","66854f14a43c09c2aea3c3c5e6e5ed93a65a1aea","1d59f3bcee356caa933646dc45ff0836455535e8","bpf: Allow selecting reuseport socket from a SOCKMAP/SOCKHASH SOCKMAP & SOCKHASH now support storing references to listening sockets. Nothing keeps us from using these map types a collection of sockets to select from in BPF reuseport programs. Whitelist the map types with the bpf_sk_select_reuseport helper. The restriction that the socket has to be a member of a reuseport group still applies. Sockets in SOCKMAP/SOCKHASH that don't have sk_reuseport_cb set are not a valid target and we signal it with -EINVAL. The main benefit from this change is that, in contrast to REUSEPORT_SOCKARRAY, SOCK{MAP,HASH} don't impose a restriction that a listening socket can be just one BPF map at the same time. Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200218171023.844439-9-jakub@cloudflare.com","kernel/bpf/verifier.c | 10 +++++++---; net/core/filter.c | 15 ++++++++++-----; 2 files changed, 17 insertions(+), 8 deletions(-)","This commit allows using SOCKMAP and SOCKHASH for selecting reuseport sockets in BPF programs.","SOCKMAP, SOCKHASH, reuseport","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"1d59f3bcee356caa933646dc45ff0836455535e8","1d59f3bcee356caa933646dc45ff0836455535e8","Jakub Sitnicki","jakub@cloudflare.com","1582045819","Daniel Borkmann","daniel@iogearbox.net","1582320585","140c09532c45a138d3f1415f4eeb3b65765dfabd","c1cdf65da060a8e047a9f4433306fd6dac1f51a6","bpf, sockmap: Let all kernel-land lookup values in SOCKMAP/SOCKHASH Don't require the kernel code, like BPF helpers, that needs access to SOCK{MAP,HASH} map contents to live in net/core/sock_map.c. Expose the lookup operation to all kernel-land. Lookup from BPF context is not whitelisted yet. While syscalls have a dedicated lookup handler. Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200218171023.844439-8-jakub@cloudflare.com","net/core/sock_map.c | 9 +++++++--; 1 file changed, 7 insertions(+), 2 deletions(-)","Expose SOCKMAP/SOCKHASH lookup operation to kernel code outside net/core/sock_map.c.","SOCKMAP SOCKHASH lookup","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"c1cdf65da060a8e047a9f4433306fd6dac1f51a6","c1cdf65da060a8e047a9f4433306fd6dac1f51a6","Jakub Sitnicki","jakub@cloudflare.com","1582045818","Daniel Borkmann","daniel@iogearbox.net","1582320585","ec77dc322cb1085437d4e63ee2c19d6958297ac4","6e830c2f6c9641217e22330cec1372acff78dcef","bpf, sockmap: Return socket cookie on lookup from syscall Tooling that populates the SOCK{MAP,HASH} with sockets from user-space needs a way to inspect its contents. Returning the struct sock * that the map holds to user-space is neither safe nor useful. An approach established by REUSEPORT_SOCKARRAY is to return a socket cookie (a unique identifier) instead. Since socket cookies are u64 values, SOCK{MAP,HASH} need to support such a value size for lookup to be possible. This requires special handling on update, though. Attempts to do a lookup on a map holding u32 values will be met with ENOSPC error. Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200218171023.844439-7-jakub@cloudflare.com","net/core/sock_map.c | 57 +++++++++++++++++++++++++++++++++++++++++++++++++----; 1 file changed, 53 insertions(+), 4 deletions(-)","This commit enables the sockmap to return a socket cookie as a unique identifier during user-space lookup operations.","sockmap,cookie,lookup","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"6e830c2f6c9641217e22330cec1372acff78dcef","6e830c2f6c9641217e22330cec1372acff78dcef","Jakub Sitnicki","jakub@cloudflare.com","1582045817","Daniel Borkmann","daniel@iogearbox.net","1582320585","e11fdef619c774d023e2294796acb479511e4c77","8ca30379a40103bf6734ae127ec940da798534dd","bpf, sockmap: Don't set up upcalls and progs for listening sockets Now that sockmap/sockhash can hold listening sockets, when setting up the psock we will (i) grab references to verdict/parser progs, and (2) override socket upcalls sk_data_ready and sk_write_space. However, since we cannot redirect to listening sockets so we don't need to link the socket to the BPF progs. And more importantly we don't want the listening socket to have overridden upcalls because they would get inherited by child sockets cloned from it. Introduce a separate initialization path for listening sockets that does not change the upcalls and ignores the BPF progs. Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200218171023.844439-6-jakub@cloudflare.com","net/core/sock_map.c | 52 +++++++++++++++++++++++++++++++++++++++++++++-------; 1 file changed, 45 insertions(+), 7 deletions(-)","This commit separates initialization for listening sockets to avoid links to BPF programs in sockmap/sockhash.","sockmap,upcalls,sockets","A bug fix. It primarily resolves a bug or issue in the code.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"8ca30379a40103bf6734ae127ec940da798534dd","8ca30379a40103bf6734ae127ec940da798534dd","Jakub Sitnicki","jakub@cloudflare.com","1582045816","Daniel Borkmann","daniel@iogearbox.net","1582320585","adf458c5d38536d0e12590567aee965a862546f9","e80251555f0befd1271e74b080bccf0ff0348bfc","bpf, sockmap: Allow inserting listening TCP sockets into sockmap In order for sockmap/sockhash types to become generic collections for storing TCP sockets we need to loosen the checks during map update, while tightening the checks in redirect helpers. Currently sock{map,hash} require the TCP socket to be in established state, which prevents inserting listening sockets. Change the update pre-checks so the socket can also be in listening state. Since it doesn't make sense to redirect with sock{map,hash} to listening sockets, add appropriate socket state checks to BPF redirect helpers too. Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200218171023.844439-5-jakub@cloudflare.com","net/core/sock_map.c | 59 ++++++++++++++++++++++++---------; tools/testing/selftests/bpf/test_maps.c | 6 +---; 2 files changed, 45 insertions(+), 20 deletions(-)","This commit allows the insertion of listening TCP sockets into sockmap, enhancing generic collection capabilities.","bpf,sockmap,TCP","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"e80251555f0befd1271e74b080bccf0ff0348bfc","e80251555f0befd1271e74b080bccf0ff0348bfc","Jakub Sitnicki","jakub@cloudflare.com","1582045815","Daniel Borkmann","daniel@iogearbox.net","1582320585","3387dd45af325c1929a160a8fab7b84dd0142e08","f1ff5ce2cd5ef3335f19c0f6576582c87045b04f","tcp_bpf: Don't let child socket inherit parent protocol ops on copy Prepare for cloning listening sockets that have their protocol callbacks overridden by sk_msg. Child sockets must not inherit parent callbacks that access state stored in sk_user_data owned by the parent. Restore the child socket protocol callbacks before it gets hashed and any of the callbacks can get invoked. Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200218171023.844439-4-jakub@cloudflare.com","include/net/tcp.h | 7 +++++++; net/ipv4/tcp_bpf.c | 14 ++++++++++++++; net/ipv4/tcp_minisocks.c | 2 ++; 3 files changed, 23 insertions(+)","The commit ensures child sockets do not inherit parent protocol callbacks in tcp_bpf to prevent state access issues.","tcp_bpf,socket,protocol","A bug fix. It primarily resolves a bug or issue in the code.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"f1ff5ce2cd5ef3335f19c0f6576582c87045b04f","f1ff5ce2cd5ef3335f19c0f6576582c87045b04f","Jakub Sitnicki","jakub@cloudflare.com","1582045814","Daniel Borkmann","daniel@iogearbox.net","1582320585","f8005ba2ac8eccf17f9391cd27d77ef0fea4401b","b8e202d1d1d0f182f01062804efb523ea9a9008c","net, sk_msg: Clear sk_user_data pointer on clone if tagged sk_user_data can hold a pointer to an object that is not intended to be shared between the parent socket and the child that gets a pointer copy on clone. This is the case when sk_user_data points at reference-counted object, like struct sk_psock. One way to resolve it is to tag the pointer with a no-copy flag by repurposing its lowest bit. Based on the bit-flag value we clear the child sk_user_data pointer after cloning the parent socket. The no-copy flag is stored in the pointer itself as opposed to externally, say in socket flags, to guarantee that the pointer and the flag are copied from parent to child socket in an atomic fashion. Parent socket state is subject to change while copying, we don't hold any locks at that time. This approach relies on an assumption that sk_user_data holds a pointer to an object aligned at least 2 bytes. A manual audit of existing users of rcu_dereference_sk_user_data helper confirms our assumption. Also, an RCU-protected sk_user_data is not likely to hold a pointer to a char value or a pathological case of ""struct { char c; }"". To be safe, warn when the flag-bit is set when setting sk_user_data to catch any future misuses. It is worth considering why clearing sk_user_data unconditionally is not an option. There exist users, DRBD, NVMe, and Xen drivers being among them, that rely on the pointer being copied when cloning the listening socket. Potentially we could distinguish these users by checking if the listening socket has been created in kernel-space via sock_create_kern, and hence has sk_kern_sock flag set. However, this is not the case for NVMe and Xen drivers, which create sockets without marking them as belonging to the kernel. Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200218171023.844439-3-jakub@cloudflare.com","include/net/sock.h | 37 +++++++++++++++++++++++++++++++++++--; net/core/skmsg.c | 2 +-; net/core/sock.c | 6 ++++++; 3 files changed, 42 insertions(+), 3 deletions(-)","The commit tags sk_user_data with a no-copy flag to prevent undesired pointer sharing between cloned sockets.","sk_user_data,no-copy,clone","A bug fix. It primarily resolves a bug or issue in the code.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.","It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.","[""It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.""]" +"b8e202d1d1d0f182f01062804efb523ea9a9008c","b8e202d1d1d0f182f01062804efb523ea9a9008c","Jakub Sitnicki","jakub@cloudflare.com","1582045813","Daniel Borkmann","daniel@iogearbox.net","1582320585","57a1c1d075e2d470fd9c1487744286c2f3bed747","e42da4c62abb547d9c9138e0e7fcd1f36057b5e8","net, sk_msg: Annotate lockless access to sk_prot on clone sk_msg and ULP frameworks override protocol callbacks pointer in sk->sk_prot, while tcp accesses it locklessly when cloning the listening socket, that is with neither sk_lock nor sk_callback_lock held. Once we enable use of listening sockets with sockmap (and hence sk_msg), there will be shared access to sk->sk_prot if socket is getting cloned while being inserted/deleted to/from the sockmap from another CPU: Read side: tcp_v4_rcv sk = __inet_lookup_skb(...) tcp_check_req(sk) inet_csk(sk)->icsk_af_ops->syn_recv_sock tcp_v4_syn_recv_sock tcp_create_openreq_child inet_csk_clone_lock sk_clone_lock READ_ONCE(sk->sk_prot) Write side: sock_map_ops->map_update_elem sock_map_update_elem sock_map_update_common sock_map_link_no_progs tcp_bpf_init tcp_bpf_update_sk_prot sk_psock_update_proto WRITE_ONCE(sk->sk_prot, ops) sock_map_ops->map_delete_elem sock_map_delete_elem __sock_map_delete sock_map_unref sk_psock_put sk_psock_drop sk_psock_restore_proto tcp_update_ulp WRITE_ONCE(sk->sk_prot, proto) Mark the shared access with READ_ONCE/WRITE_ONCE annotations. Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200218171023.844439-2-jakub@cloudflare.com","include/linux/skmsg.h | 3 ++-; net/core/sock.c | 8 +++++---; net/ipv4/tcp_bpf.c | 4 +++-; net/ipv4/tcp_ulp.c | 3 ++-; net/tls/tls_main.c | 3 ++-; 5 files changed, 14 insertions(+), 7 deletions(-)","The commit adds annotations for lockless access to sk->sk_prot during socket cloning to prevent race conditions with sk_msg and ULP frameworks.","lockless, sk_prot, annotations","A bug fix. It primarily resolves a bug or issue in the code.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"3dc55dba67231fc22352483f5ca737df96cdc1e6","3dc55dba67231fc22352483f5ca737df96cdc1e6","Linus Torvalds","torvalds@linux-foundation.org","1582315191","Linus Torvalds","torvalds@linux-foundation.org","1582315191","5eec1f5ce42822cb744313ec394b761fab0f7ed6","b0dd1eb220c06892e0a4098378c4296650f3f8db 36a44bcdd8df092d76c11bc213e81c5817d4e302","Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from David Miller: 1) Limit xt_hashlimit hash table size to avoid OOM or hung tasks, from Cong Wang. 2) Fix deadlock in xsk by publishing global consumer pointers when NAPI is finished, from Magnus Karlsson. 3) Set table field properly to RT_TABLE_COMPAT when necessary, from Jethro Beekman. 4) NLA_STRING attributes are not necessary NULL terminated, deal wiht that in IFLA_ALT_IFNAME. From Eric Dumazet. 5) Fix checksum handling in atlantic driver, from Dmitry Bezrukov. 6) Handle mtu==0 devices properly in wireguard, from Jason A. Donenfeld. 7) Fix several lockdep warnings in bonding, from Taehee Yoo. 8) Fix cls_flower port blocking, from Jason Baron. 9) Sanitize internal map names in libbpf, from Toke Høiland-Jørgensen. 10) Fix RDMA race in qede driver, from Michal Kalderon. 11) Fix several false lockdep warnings by adding conditions to list_for_each_entry_rcu(), from Madhuparna Bhowmik. 12) Fix sleep in atomic in mlx5 driver, from Huy Nguyen. 13) Fix potential deadlock in bpf_map_do_batch(), from Yonghong Song. 14) Hey, variables declared in switch statement before any case statements are not initialized. I learn something every day. Get rids of this stuff in several parts of the networking, from Kees Cook. * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (99 commits) bnxt_en: Issue PCIe FLR in kdump kernel to cleanup pending DMAs. bnxt_en: Improve device shutdown method. net: netlink: cap max groups which will be considered in netlink_bind() net: thunderx: workaround BGX TX Underflow issue ionic: fix fw_status read net: disable BRIDGE_NETFILTER by default net: macb: Properly handle phylink on at91rm9200 s390/qeth: fix off-by-one in RX copybreak check s390/qeth: don't warn for napi with 0 budget s390/qeth: vnicc Fix EOPNOTSUPP precedence openvswitch: Distribute switch variables for initialization net: ip6_gre: Distribute switch variables for initialization net: core: Distribute switch variables for initialization udp: rehash on disconnect net/tls: Fix to avoid gettig invalid tls record bpf: Fix a potential deadlock with bpf_map_do_batch bpf: Do not grab the bucket spinlock by default on htab batch ops ice: Wait for VF to be reset/ready before configuration ice: Don't tell the OS that link is going down ice: Don't reject odd values of usecs set by user ...","","Merge networking fixes including deadlock prevention, lockdep warnings resolution, and adjustments in networking components from various contributors.","Merge,networking,fixes","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"e42da4c62abb547d9c9138e0e7fcd1f36057b5e8","e42da4c62abb547d9c9138e0e7fcd1f36057b5e8","Yonghong Song","yhs@fb.com","1582245834","Alexei Starovoitov","ast@kernel.org","1582250737","666bfe07a52a9416a53d1cf42a277812f7495796","006ed53e8caa0b3c1e21a51dc34d6b3b5ab0aab6","docs/bpf: Update bpf development Q/A file bpf now has its own mailing list bpf@vger.kernel.org. Update the bpf_devel_QA.rst file to reflect this. Also llvm has switch to github with llvm and clang in the same repo https://github.com/llvm/llvm-project.git. Update the QA file with newer build instructions. Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200221004354.930952-1-yhs@fb.com","Documentation/bpf/bpf_devel_QA.rst | 29 ++++++++++++-----------------; 1 file changed, 12 insertions(+), 17 deletions(-)","The commit updates the bpf_devel_QA.rst file to reflect new mailing list and LLVM GitHub repository details.","bpf_development, mailing_list, LLVM","A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.","It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"006ed53e8caa0b3c1e21a51dc34d6b3b5ab0aab6","006ed53e8caa0b3c1e21a51dc34d6b3b5ab0aab6","Andrii Nakryiko","andriin@fb.com","1582239946","Alexei Starovoitov","ast@kernel.org","1582250590","f2f6b1b8ea77194883a9355f10c11689d116e315","2c3a368127e1b56b32e147971ab804176ff4c9f3","selftests/bpf: Fix trampoline_count clean up logic Libbpf's Travis CI tests caught this issue. Ensure bpf_link and bpf_object clean up is performed correctly. Fixes: d633d57902a5 (""selftest/bpf: Add test for allowed trampolines count"") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Cc: Jiri Olsa Link: https://lore.kernel.org/bpf/20200220230546.769250-1-andriin@fb.com",".../selftests/bpf/prog_tests/trampoline_count.c | 25 ++++++++++++++++------; 1 file changed, 18 insertions(+), 7 deletions(-)","The commit fixes cleanup logic for trampoline_count in bpf selftests as caught by Libbpf's Travis CI.","selftests,bpf,trampoline_count","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"2c3a368127e1b56b32e147971ab804176ff4c9f3","2c3a368127e1b56b32e147971ab804176ff4c9f3","Alexei Starovoitov","ast@kernel.org","1582249720","Alexei Starovoitov","ast@kernel.org","1582249900","e4deb87a21fd976b52af9400335b73168437a9b9","5327644614a18f5d0ff845844a4e9976210b3d8d 933ce62d68dee5465cb5f5b359ab0638c9f665b1","Merge branch 'set_attach_target' Eelco Chaudron says: ==================== Currently when you want to attach a trace program to a bpf program the section name needs to match the tracepoint/function semantics. However the addition of the bpf_program__set_attach_target() API allows you to specify the tracepoint/function dynamically. The call flow would look something like this: xdp_fd = bpf_prog_get_fd_by_id(id); trace_obj = bpf_object__open_file(""func.o"", NULL); prog = bpf_object__find_program_by_title(trace_obj, ""fentry/myfunc""); bpf_program__set_expected_attach_type(prog, BPF_TRACE_FENTRY); bpf_program__set_attach_target(prog, xdp_fd, ""xdpfilt_blk_all""); bpf_object__load(trace_obj) v1 -> v2: Remove requirement for attach type hint in API v2 -> v3: Moved common warning to __find_vmlinux_btf_id, requested by Andrii Updated the xdp_bpf2bpf test to use this new API v3 -> v4: Split up patch, update libbpf.map version v4 -> v5: Fix return code, and prog assignment in test case ==================== Signed-off-by: Alexei Starovoitov ","","The commit involves merging a branch that introduces APIs for dynamically setting tracepoint/function targets for BPF program attachments.","merge, tracepoint, API","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.', 'XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"933ce62d68dee5465cb5f5b359ab0638c9f665b1","933ce62d68dee5465cb5f5b359ab0638c9f665b1","Eelco Chaudron","echaudro@redhat.com","1582205205","Alexei Starovoitov","ast@kernel.org","1582249720","e4deb87a21fd976b52af9400335b73168437a9b9","ff26ce5cd7680ebc9c5446cda013e2087decc60f","selftests/bpf: Update xdp_bpf2bpf test to use new set_attach_target API Use the new bpf_program__set_attach_target() API in the xdp_bpf2bpf selftest so it can be referenced as an example on how to use it. Signed-off-by: Eelco Chaudron Signed-off-by: Alexei Starovoitov Acked-by: Toke Høiland-Jørgensen Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/158220520562.127661.14289388017034825841.stgit@xdp-tutorial","tools/testing/selftests/bpf/prog_tests/xdp_bpf2bpf.c | 16 +++++++++++++---; tools/testing/selftests/bpf/progs/test_xdp_bpf2bpf.c | 4 ++--; 2 files changed, 15 insertions(+), 5 deletions(-)","The commit updates xdp_bpf2bpf test to utilize the new set_attach_target API in BPF selftests.","xdp_bpf2bpf,set_attach_target,selftests","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.']" +"ff26ce5cd7680ebc9c5446cda013e2087decc60f","ff26ce5cd7680ebc9c5446cda013e2087decc60f","Eelco Chaudron","echaudro@redhat.com","1582205195","Alexei Starovoitov","ast@kernel.org","1582249720","13503f7c233736c8f10bd27795597cb48012dd71","dd88aed92d017bed2a2c0023f22f0eef7cd29702","libbpf: Add support for dynamic program attach target Currently when you want to attach a trace program to a bpf program the section name needs to match the tracepoint/function semantics. However the addition of the bpf_program__set_attach_target() API allows you to specify the tracepoint/function dynamically. The call flow would look something like this: xdp_fd = bpf_prog_get_fd_by_id(id); trace_obj = bpf_object__open_file(""func.o"", NULL); prog = bpf_object__find_program_by_title(trace_obj, ""fentry/myfunc""); bpf_program__set_expected_attach_type(prog, BPF_TRACE_FENTRY); bpf_program__set_attach_target(prog, xdp_fd, ""xdpfilt_blk_all""); bpf_object__load(trace_obj) Signed-off-by: Eelco Chaudron Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/158220519486.127661.7964708960649051384.stgit@xdp-tutorial","tools/lib/bpf/libbpf.c | 34 ++++++++++++++++++++++++++++++----; tools/lib/bpf/libbpf.h | 4 ++++; tools/lib/bpf/libbpf.map | 2 ++; 3 files changed, 36 insertions(+), 4 deletions(-)","The commit adds dynamic attach target support to libbpf for trace programs.","dynamic, attach, libbpf","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime."", ""I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear.""]" +"dd88aed92d017bed2a2c0023f22f0eef7cd29702","dd88aed92d017bed2a2c0023f22f0eef7cd29702","Eelco Chaudron","echaudro@redhat.com","1582205184","Alexei Starovoitov","ast@kernel.org","1582249720","c7c9514b6313fba95054c98488f0c0ac7f65d60a","5327644614a18f5d0ff845844a4e9976210b3d8d","libbpf: Bump libpf current version to v0.0.8 New development cycles starts, bump to v0.0.8. Signed-off-by: Eelco Chaudron Signed-off-by: Alexei Starovoitov Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/158220518424.127661.8278643006567775528.stgit@xdp-tutorial","tools/lib/bpf/libbpf.map | 3 +++; 1 file changed, 3 insertions(+)","The commit updates libbpf version to v0.0.8 marking the start of a new development cycle.","libbpf,version,bump","A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"5327644614a18f5d0ff845844a4e9976210b3d8d","5327644614a18f5d0ff845844a4e9976210b3d8d","Andrii Nakryiko","andriin@fb.com","1582179995","Alexei Starovoitov","ast@kernel.org","1582225419","a21295e7bfb9fc349419565cb2af344b4b0e2f31","500897804a369358f4d27356787dcf9b33527fd7","libbpf: Relax check whether BTF is mandatory If BPF program is using BTF-defined maps, BTF is required only for libbpf itself to process map definitions. If after that BTF fails to be loaded into kernel (e.g., if it doesn't support BTF at all), this shouldn't prevent valid BPF program from loading. Existing retry-without-BTF logic for creating maps will succeed to create such maps without any problems. So, presence of .maps section shouldn't make BTF required for kernel. Update the check accordingly. Validated by ensuring simple BPF program with BTF-defined maps is still loaded on old kernel without BTF support and map is correctly parsed and created. Fixes: abd29c931459 (""libbpf: allow specifying map definitions using BTF"") Reported-by: Julia Kartseva Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200220062635.1497872-1-andriin@fb.com","tools/lib/bpf/libbpf.c | 4 +---; 1 file changed, 1 insertion(+), 3 deletions(-)","The commit updates libbpf to relax the requirement for BTF when loading BPF programs with BTF-defined maps on kernels without BTF support.","libbpf,BTF,maps","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"41f57cfde186dba6e357f9db25eafbed017e4487","41f57cfde186dba6e357f9db25eafbed017e4487","David S. Miller","davem@davemloft.net","1582159355","David S. Miller","davem@davemloft.net","1582159355","e5f3ab80902a1f921341d7846fbe956695fda351","fca07a937a27e720df7310bc5e68a11e5d2ff3c5 b9aff38de2cb166476988020428985c5f7412ffc","Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf Alexei Starovoitov says: ==================== pull-request: bpf 2020-02-19 The following pull-request contains BPF updates for your *net* tree. We've added 10 non-merge commits during the last 10 day(s) which contain a total of 10 files changed, 93 insertions(+), 31 deletions(-). The main changes are: 1) batched bpf hashtab fixes from Brian and Yonghong. 2) various selftests and libbpf fixes. ==================== Signed-off-by: David S. Miller ","","The commit merges BPF updates from another branch focusing on hashtab fixes and selftests improvements.","merge,hashtab,selftests","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"500897804a369358f4d27356787dcf9b33527fd7","500897804a369358f4d27356787dcf9b33527fd7","Alexei Starovoitov","ast@kernel.org","1582145714","Daniel Borkmann","daniel@iogearbox.net","1582157844","cd644f62558d27146f0d0d0c3b2f528edfa2fe64","83250f2b6940654a73a2cfab7ac112b804a5f648","selftests/bpf: Fix build of sockmap_ktls.c The selftests fails to build with: tools/testing/selftests/bpf/prog_tests/sockmap_ktls.c: In function ‘test_sockmap_ktls_disconnect_after_delete’: tools/testing/selftests/bpf/prog_tests/sockmap_ktls.c:72:37: error: ‘TCP_ULP’ undeclared (first use in this function) 72 | err = setsockopt(cli, IPPROTO_TCP, TCP_ULP, ""tls"", strlen(""tls"")); | ^~~~~~~ Similar to commit that fixes build of sockmap_basic.c on systems with old /usr/include fix the build of sockmap_ktls.c Fixes: d1ba1204f2ee (""selftests/bpf: Test unhashing kTLS socket after removing from map"") Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200219205514.3353788-1-ast@kernel.org","tools/testing/selftests/bpf/prog_tests/sockmap_ktls.c | 1 +; 1 file changed, 1 insertion(+)","Fix the build issue of sockmap_ktls.c related to undeclared TCP_ULP variable in eBPF selftests.","fix, build, sockmap_ktls","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"b9aff38de2cb166476988020428985c5f7412ffc","b9aff38de2cb166476988020428985c5f7412ffc","Yonghong Song","yhs@fb.com","1582156077","Alexei Starovoitov","ast@kernel.org","1582156885","dc2a29c67c3e5639fe511ba147e0d84b621c71d6","492e0d0d6f2eb4badfd2868addf9da0f651eba0e","bpf: Fix a potential deadlock with bpf_map_do_batch Commit 057996380a42 (""bpf: Add batch ops to all htab bpf map"") added lookup_and_delete batch operation for hash table. The current implementation has bpf_lru_push_free() inside the bucket lock, which may cause a deadlock. syzbot reports: -> #2 (&htab->buckets[i].lock#2){....}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x95/0xcd kernel/locking/spinlock.c:159 htab_lru_map_delete_node+0xce/0x2f0 kernel/bpf/hashtab.c:593 __bpf_lru_list_shrink_inactive kernel/bpf/bpf_lru_list.c:220 [inline] __bpf_lru_list_shrink+0xf9/0x470 kernel/bpf/bpf_lru_list.c:266 bpf_lru_list_pop_free_to_local kernel/bpf/bpf_lru_list.c:340 [inline] bpf_common_lru_pop_free kernel/bpf/bpf_lru_list.c:447 [inline] bpf_lru_pop_free+0x87c/0x1670 kernel/bpf/bpf_lru_list.c:499 prealloc_lru_pop+0x2c/0xa0 kernel/bpf/hashtab.c:132 __htab_lru_percpu_map_update_elem+0x67e/0xa90 kernel/bpf/hashtab.c:1069 bpf_percpu_hash_update+0x16e/0x210 kernel/bpf/hashtab.c:1585 bpf_map_update_value.isra.0+0x2d7/0x8e0 kernel/bpf/syscall.c:181 generic_map_update_batch+0x41f/0x610 kernel/bpf/syscall.c:1319 bpf_map_do_batch+0x3f5/0x510 kernel/bpf/syscall.c:3348 __do_sys_bpf+0x9b7/0x41e0 kernel/bpf/syscall.c:3460 __se_sys_bpf kernel/bpf/syscall.c:3355 [inline] __x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:3355 do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe -> #0 (&loc_l->lock){....}: check_prev_add kernel/locking/lockdep.c:2475 [inline] check_prevs_add kernel/locking/lockdep.c:2580 [inline] validate_chain kernel/locking/lockdep.c:2970 [inline] __lock_acquire+0x2596/0x4a00 kernel/locking/lockdep.c:3954 lock_acquire+0x190/0x410 kernel/locking/lockdep.c:4484 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x95/0xcd kernel/locking/spinlock.c:159 bpf_common_lru_push_free kernel/bpf/bpf_lru_list.c:516 [inline] bpf_lru_push_free+0x250/0x5b0 kernel/bpf/bpf_lru_list.c:555 __htab_map_lookup_and_delete_batch+0x8d4/0x1540 kernel/bpf/hashtab.c:1374 htab_lru_map_lookup_and_delete_batch+0x34/0x40 kernel/bpf/hashtab.c:1491 bpf_map_do_batch+0x3f5/0x510 kernel/bpf/syscall.c:3348 __do_sys_bpf+0x1f7d/0x41e0 kernel/bpf/syscall.c:3456 __se_sys_bpf kernel/bpf/syscall.c:3355 [inline] __x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:3355 do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe Possible unsafe locking scenario: CPU0 CPU2 ---- ---- lock(&htab->buckets[i].lock#2); lock(&l->lock); lock(&htab->buckets[i].lock#2); lock(&loc_l->lock); *** DEADLOCK *** To fix the issue, for htab_lru_map_lookup_and_delete_batch() in CPU0, let us do bpf_lru_push_free() out of the htab bucket lock. This can avoid the above deadlock scenario. Fixes: 057996380a42 (""bpf: Add batch ops to all htab bpf map"") Reported-by: syzbot+a38ff3d9356388f2fb83@syzkaller.appspotmail.com Reported-by: syzbot+122b5421d14e68f29cd1@syzkaller.appspotmail.com Suggested-by: Hillf Danton Suggested-by: Martin KaFai Lau Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Reviewed-by: Jakub Sitnicki Acked-by: Brian Vazquez Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200219234757.3544014-1-yhs@fb.com","kernel/bpf/hashtab.c | 34 +++++++++++++++++++++++++++++++---; 1 file changed, 31 insertions(+), 3 deletions(-)","The commit fixes a potential deadlock in bpf_map_do_batch related to lock operations in eBPF hash table maps.","deadlock, lock, hash table","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"492e0d0d6f2eb4badfd2868addf9da0f651eba0e","492e0d0d6f2eb4badfd2868addf9da0f651eba0e","Brian Vazquez","brianvv@google.com","1582046752","Alexei Starovoitov","ast@kernel.org","1582156770","2372a6369b60229833ad44472f920065f9e0e44c","113e6b7e15e23dc45d5c66eb66bb91a627812e36","bpf: Do not grab the bucket spinlock by default on htab batch ops Grabbing the spinlock for every bucket even if it's empty, was causing significant perfomance cost when traversing htab maps that have only a few entries. This patch addresses the issue by checking first the bucket_cnt, if the bucket has some entries then we go and grab the spinlock and proceed with the batching. Tested with a htab of size 50K and different value of populated entries. Before: Benchmark Time(ns) CPU(ns) --------------------------------------------- BM_DumpHashMap/1 2759655 2752033 BM_DumpHashMap/10 2933722 2930825 BM_DumpHashMap/200 3171680 3170265 BM_DumpHashMap/500 3639607 3635511 BM_DumpHashMap/1000 4369008 4364981 BM_DumpHashMap/5k 11171919 11134028 BM_DumpHashMap/20k 69150080 69033496 BM_DumpHashMap/39k 190501036 190226162 After: Benchmark Time(ns) CPU(ns) --------------------------------------------- BM_DumpHashMap/1 202707 200109 BM_DumpHashMap/10 213441 210569 BM_DumpHashMap/200 478641 472350 BM_DumpHashMap/500 980061 967102 BM_DumpHashMap/1000 1863835 1839575 BM_DumpHashMap/5k 8961836 8902540 BM_DumpHashMap/20k 69761497 69322756 BM_DumpHashMap/39k 187437830 186551111 Fixes: 057996380a42 (""bpf: Add batch ops to all htab bpf map"") Signed-off-by: Brian Vazquez Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200218172552.215077-1-brianvv@google.com","kernel/bpf/hashtab.c | 24 ++++++++++++++++++++++--; 1 file changed, 22 insertions(+), 2 deletions(-)","The commit optimizes htab batch operations by avoiding unnecessary spinlock acquisition, significantly improving performance for maps with few entries.","htab, spinlock, optimization","A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"83250f2b6940654a73a2cfab7ac112b804a5f648","83250f2b6940654a73a2cfab7ac112b804a5f648","Yonghong Song","yhs@fb.com","1582072956","Alexei Starovoitov","ast@kernel.org","1582154107","a4179458a107426f32ad5346bff8eba664bf4f92","03aa39558e74649b8ad19b2a3988a22bef23a517","selftests/bpf: Change llvm flag -mcpu=probe to -mcpu=v3 The latest llvm supports cpu version v3, which is cpu version v1 plus some additional 64bit jmp insns and 32bit jmp insn support. In selftests/bpf Makefile, the llvm flag -mcpu=probe did runtime probe into the host system. Depending on compilation environments, it is possible that runtime probe may fail, e.g., due to memlock issue. This will cause generated code with cpu version v1. This may cause confusion as the same compiler and the same C code generates different byte codes in different environment. Let us change the llvm flag -mcpu=probe to -mcpu=v3 so the generated code will be the same regardless of the compilation environment. Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200219004236.2291125-1-yhs@fb.com","tools/testing/selftests/bpf/Makefile | 4 ++--; 1 file changed, 2 insertions(+), 2 deletions(-)","The commit updates the LLVM flag in selftests to ensure consistent code generation by using -mcpu=v3 instead of -mcpu=probe.","LLVM,Makefile,selftests","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"03aa39558e74649b8ad19b2a3988a22bef23a517","03aa39558e74649b8ad19b2a3988a22bef23a517","Alexei Starovoitov","ast@kernel.org","1582151856","Alexei Starovoitov","ast@kernel.org","1582153272","9017e0f53548a512619ec8dc4ffd13f2c5a37540","2f14b2d9dd80427a1c07451b623afb8b85efef21 67306f84ca78c2ca5136f21791710c126a55a19b","Merge branch 'bpf_read_branch_records' Daniel Xu says: ==================== Branch records are a CPU feature that can be configured to record certain branches that are taken during code execution. This data is particularly interesting for profile guided optimizations. perf has had branch record support for a while but the data collection can be a bit coarse grained. We (Facebook) have seen in experiments that associating metadata with branch records can improve results (after postprocessing). We generally use bpf_probe_read_*() to get metadata out of userspace. That's why bpf support for branch records is useful. Aside from this particular use case, having branch data available to bpf progs can be useful to get stack traces out of userspace applications that omit frame pointers. Changes in v8: - Use globals instead of perf buffer - Call test_perf_branches__detach() before destroying skeleton - Fix typo in docs Changes in v7: - Const-ify and static-ify local var - Documentation formatting Changes in v6: - Move #ifdef a little to avoid unused variable warnings on !x86 - Test negative condition in selftest (-EINVAL on improperly configured perf event) - Skip positive condition selftest on setups that don't support branch records Changes in v5: - Rename bpf_perf_prog_read_branches() -> bpf_read_branch_records() - Rename BPF_F_GET_BR_SIZE -> BPF_F_GET_BRANCH_RECORDS_SIZE - Squash tools/ bpf.h sync into selftest commit Changes in v4: - Add BPF_F_GET_BR_SIZE flag - Return -ENOENT on unsupported architectures - Only accept initialized memory in helper - Check buffer size is multiple of sizeof(struct perf_branch_entry) - Use bpf skeleton in selftest - Add commit messages - Spelling and formatting Changes in v3: - Document filling unused buffer with zero - Formatting fixes - Rebase Changes in v2: - Change to a bpf helper instead of context access - Avoid mentioning Intel specific things ==================== Signed-off-by: Alexei Starovoitov ","","This merge commit integrates support for branch records into eBPF.","branch,metadata,eBPF","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Profile related type programs. It affects programs used for profiling system or application performance.', 'Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.', ""It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here.""]" +"67306f84ca78c2ca5136f21791710c126a55a19b","67306f84ca78c2ca5136f21791710c126a55a19b","Daniel Xu","dxu@dxuuu.xyz","1581995072","Alexei Starovoitov","ast@kernel.org","1582153267","9017e0f53548a512619ec8dc4ffd13f2c5a37540","fff7b64355eac6e29b50229ad1512315bc04b44e","selftests/bpf: Add bpf_read_branch_records() selftest Add a selftest to test: * default bpf_read_branch_records() behavior * BPF_F_GET_BRANCH_RECORDS_SIZE flag behavior * error path on non branch record perf events * using helper to write to stack * using helper to write to global On host with hardware counter support: # ./test_progs -t perf_branches #27/1 perf_branches_hw:OK #27/2 perf_branches_no_hw:OK #27 perf_branches:OK Summary: 1/2 PASSED, 0 SKIPPED, 0 FAILED On host without hardware counter support (VM): # ./test_progs -t perf_branches #27/1 perf_branches_hw:OK #27/2 perf_branches_no_hw:OK #27 perf_branches:OK Summary: 1/2 PASSED, 1 SKIPPED, 0 FAILED Also sync tools/include/uapi/linux/bpf.h. Signed-off-by: Daniel Xu Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200218030432.4600-3-dxu@dxuuu.xyz","tools/include/uapi/linux/bpf.h | 25 ++-; .../selftests/bpf/prog_tests/perf_branches.c | 170 +++++++++++++++++++++; .../selftests/bpf/progs/test_perf_branches.c | 50 ++++++; 3 files changed, 244 insertions(+), 1 deletion(-)","The commit adds a selftest for bpf_read_branch_records and synchronizes tools/include/uapi/linux/bpf.h.","selftest, perf_events, synchronization","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"fff7b64355eac6e29b50229ad1512315bc04b44e","fff7b64355eac6e29b50229ad1512315bc04b44e","Daniel Xu","dxu@dxuuu.xyz","1581995071","Alexei Starovoitov","ast@kernel.org","1582151856","ca8d642f593dee81cfdf303d8675ff5754dcb393","2f14b2d9dd80427a1c07451b623afb8b85efef21","bpf: Add bpf_read_branch_records() helper Branch records are a CPU feature that can be configured to record certain branches that are taken during code execution. This data is particularly interesting for profile guided optimizations. perf has had branch record support for a while but the data collection can be a bit coarse grained. We (Facebook) have seen in experiments that associating metadata with branch records can improve results (after postprocessing). We generally use bpf_probe_read_*() to get metadata out of userspace. That's why bpf support for branch records is useful. Aside from this particular use case, having branch data available to bpf progs can be useful to get stack traces out of userspace applications that omit frame pointers. Signed-off-by: Daniel Xu Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200218030432.4600-2-dxu@dxuuu.xyz","include/uapi/linux/bpf.h | 25 ++++++++++++++++++++++++-; kernel/trace/bpf_trace.c | 41 +++++++++++++++++++++++++++++++++++++++++; 2 files changed, 65 insertions(+), 1 deletion(-)","This commit introduces a new helper bpf_read_branch_records() for branch record data collection in eBPF.","bpf,branch,helper","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['Profile related type programs. It affects programs used for profiling system or application performance.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"2f14b2d9dd80427a1c07451b623afb8b85efef21","2f14b2d9dd80427a1c07451b623afb8b85efef21","Daniel Borkmann","daniel@iogearbox.net","1582127645","Daniel Borkmann","daniel@iogearbox.net","1582127664","20be453de9bbad27e82af5f26490e642ccda7437","b80b033bedae68dae8fc703ab8a69811ce678f2e d1ba1204f2eec134937cb32997ee47756d448aa2","Merge branch 'bpf-skmsg-simplify-restore' Jakub Sitnicki says: ==================== This series has been split out from ""Extend SOCKMAP to store listening sockets"" [0]. I think it stands on its own, and makes the latter series smaller, which will make the review easier, hopefully. The essence is that we don't need to do a complicated dance in sk_psock_restore_proto, if we agree that the contract with tcp_update_ulp is to restore callbacks even when the socket doesn't use ULP. This is what tcp_update_ulp currently does, and we just make use of it. Series is accompanied by a test for a particularly tricky case of restoring callbacks when we have both sockmap and tls callbacks configured in sk->sk_prot. [0] https://lore.kernel.org/bpf/20200127131057.150941-1-jakub@cloudflare.com/ ==================== Signed-off-by: Daniel Borkmann ","","The commit merges a branch simplifying sk_psock_restore_proto to improve handling of socket callbacks without complex dances.","merge,simplify,socket","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.', ""It's likely a merge commit. It involves changes across multiple use cases or events."", ""I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear.""]" +"d1ba1204f2eec134937cb32997ee47756d448aa2","d1ba1204f2eec134937cb32997ee47756d448aa2","Jakub Sitnicki","jakub@cloudflare.com","1581941730","Daniel Borkmann","daniel@iogearbox.net","1582127645","20be453de9bbad27e82af5f26490e642ccda7437","a178b4585865a4c756c41bc5376f63416b7d9271","selftests/bpf: Test unhashing kTLS socket after removing from map When a TCP socket gets inserted into a sockmap, its sk_prot callbacks get replaced with tcp_bpf callbacks built from regular tcp callbacks. If TLS gets enabled on the same socket, sk_prot callbacks get replaced once again, this time with kTLS callbacks built from tcp_bpf callbacks. Now, we allow removing a socket from a sockmap that has kTLS enabled. After removal, socket remains with kTLS configured. This is where things things get tricky. Since the socket has a set of sk_prot callbacks that are a mix of kTLS and tcp_bpf callbacks, we need to restore just the tcp_bpf callbacks to the original ones. At the moment, it comes down to the the unhash operation. We had a regression recently because tcp_bpf callbacks were not cleared in this particular scenario of removing a kTLS socket from a sockmap. It got fixed in commit 4da6a196f93b (""bpf: Sockmap/tls, during free we may call tcp_bpf_unhash() in loop""). Add a test that triggers the regression so that we don't reintroduce it in the future. Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200217121530.754315-4-jakub@cloudflare.com",".../selftests/bpf/prog_tests/sockmap_ktls.c | 123 +++++++++++++++++++++; 1 file changed, 123 insertions(+)","This commit adds a test case to verify kTLS socket behavior after sockmap removal to avoid regression.","kTLS,sockmap,test","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"a178b4585865a4c756c41bc5376f63416b7d9271","a178b4585865a4c756c41bc5376f63416b7d9271","Jakub Sitnicki","jakub@cloudflare.com","1581941729","Daniel Borkmann","daniel@iogearbox.net","1582127645","46c6266eb99a830456eea8a480e16f11d9d5a871","a4393861a351f66fef1102e775743c86a276afce","bpf, sk_msg: Don't clear saved sock proto on restore There is no need to clear psock->sk_proto when restoring socket protocol callbacks in sk->sk_prot. The psock is about to get detached from the sock and eventually destroyed. At worst we will restore the protocol callbacks and the write callback twice. This makes reasoning about psock state easier. Once psock is initialized, we can count on psock->sk_proto always being set. Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200217121530.754315-3-jakub@cloudflare.com","include/linux/skmsg.h | 8 +-------; 1 file changed, 1 insertion(+), 7 deletions(-)","The commit avoids clearing saved socket protocol during socket restore to simplify psock state management.","psock,socket,protocol","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime."", ""I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear.""]" +"a4393861a351f66fef1102e775743c86a276afce","a4393861a351f66fef1102e775743c86a276afce","Jakub Sitnicki","jakub@cloudflare.com","1581941728","Daniel Borkmann","daniel@iogearbox.net","1582127645","0cf81195a9212dcb6467d4a73f501e2c88d00abe","b80b033bedae68dae8fc703ab8a69811ce678f2e","bpf, sk_msg: Let ULP restore sk_proto and write_space callback We don't need a fallback for when the socket is not using ULP. tcp_update_ulp handles this case exactly the same as we do in sk_psock_restore_proto. Get rid of the duplicated code. Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200217121530.754315-2-jakub@cloudflare.com","include/linux/skmsg.h | 11 +----------; 1 file changed, 1 insertion(+), 10 deletions(-)","Refactor code to simplify restoration of sk_proto and write_space callback in sockets using ULP.","ULP, sk_proto, socket","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime."", ""I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear.""]" +"b80b033bedae68dae8fc703ab8a69811ce678f2e","b80b033bedae68dae8fc703ab8a69811ce678f2e","Song Liu","songliubraving@fb.com","1581723706","Daniel Borkmann","daniel@iogearbox.net","1582038507","58d2c30ae0127f991c0e2caf06edb38b38c97dc7","b182a66792feb706c62e50c31db8546ca4ff168e","bpf: Allow bpf_perf_event_read_value in all BPF programs bpf_perf_event_read_value() is NMI safe. Enable it for all BPF programs. This can be used in fentry/fexit to profile BPF program and individual kernel function with hardware counters. Signed-off-by: Song Liu Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200214234146.2910011-1-songliubraving@fb.com","kernel/trace/bpf_trace.c | 4 ++--; 1 file changed, 2 insertions(+), 2 deletions(-)","Enable bpf_perf_event_read_value() for use in all BPF programs to enhance profiling capabilities.","bpf_perf_event_read_value,BPF,profiling","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Profile related type programs. It affects programs used for profiling system or application performance.', 'kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"113e6b7e15e23dc45d5c66eb66bb91a627812e36","113e6b7e15e23dc45d5c66eb66bb91a627812e36","Toke Høiland-Jørgensen","toke@redhat.com","1581959821","Daniel Borkmann","daniel@iogearbox.net","1582036460","96d646cc04e8d070610f657cb716217268e2d3d9","f25975f42f2f8f2a01303054d6a70c7ceb1fcf54","libbpf: Sanitise internal map names so they are not rejected by the kernel The kernel only accepts map names with alphanumeric characters, underscores and periods in their name. However, the auto-generated internal map names used by libbpf takes their prefix from the user-supplied BPF object name, which has no such restriction. This can lead to ""Invalid argument"" errors when trying to load a BPF program using global variables. Fix this by sanitising the map names, replacing any non-allowed characters with underscores. Fixes: d859900c4c56 (""bpf, libbpf: support global data/bss/rodata sections"") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200217171701.215215-1-toke@redhat.com","tools/lib/bpf/libbpf.c | 8 +++++++-; 1 file changed, 7 insertions(+), 1 deletion(-)","Sanitise libbpf's internal map names to meet kernel's naming restrictions and avoid load errors.","libbpf,map,sanitise","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"f25975f42f2f8f2a01303054d6a70c7ceb1fcf54","f25975f42f2f8f2a01303054d6a70c7ceb1fcf54","Toke Høiland-Jørgensen","toke@redhat.com","1582031014","Daniel Borkmann","daniel@iogearbox.net","1582036291","9849341ec8a3232a5c9c909fdca5e12204350b55","e20d3a055a457a10a4c748ce5b7c2ed3173a1324","bpf, uapi: Remove text about bpf_redirect_map() giving higher performance The performance of bpf_redirect() is now roughly the same as that of bpf_redirect_map(). However, David Ahern pointed out that the header file has not been updated to reflect this, and still says that a significant performance increase is possible when using bpf_redirect_map(). Remove this text from the bpf_redirect_map() description, and reword the description in bpf_redirect() slightly. Also fix the 'Return' section of the bpf_redirect_map() documentation. Fixes: 1d233886dd90 (""xdp: Use bulking for non-map XDP_REDIRECT and consolidate code paths"") Reported-by: David Ahern Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200218130334.29889-1-toke@redhat.com","include/uapi/linux/bpf.h | 16 +++++++---------; tools/include/uapi/linux/bpf.h | 16 +++++++---------; 2 files changed, 14 insertions(+), 18 deletions(-)","The commit revises the documentation to accurately represent bpf_redirect() and bpf_redirect_map() performance equivalence.","bpf_redirect,bpf_redirect_map,uapi","A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"3b573bf318d894b4290e194c4d7dbcba8c1f6ead","3b573bf318d894b4290e194c4d7dbcba8c1f6ead","Arnaldo Carvalho de Melo","acme@redhat.com","1581708100","Arnaldo Carvalho de Melo","acme@redhat.com","1582031608","54e51d3a95094cfbf26abf9f6707dd5143a329e7","b1da3acc781ce445445d959b41064d209a27bc2d","perf bpf: Remove bpf/ subdir from bpf.h headers used to build bpf events The bpf.h file needed gets installed in /usr/lib/include/perf/bpf/bpf.h, and /usr/lib/include/perf/ is added to the include path passed to clang to build the eBPF bytecode, so just remove ""bpf/"", its directly in the path passed already. This was working by accident, fix it. I.e. now this is back working: # cat /home/acme/git/perf/tools/perf/examples/bpf/hello.c #include int syscall_enter(openat)(void *args) { puts(""Hello, world\n""); return 0; } license(GPL); # perf trace -e /home/acme/git/perf/tools/perf/examples/bpf/hello.c 0.000 pickup/21493 __bpf_stdout__(Hello, world) 56.462 sh/13539 __bpf_stdout__(Hello, world) 56.536 sh/13539 __bpf_stdout__(Hello, world) 56.673 sh/13539 __bpf_stdout__(Hello, world) 56.781 sh/13539 __bpf_stdout__(Hello, world) 56.707 perf/13182 __bpf_stdout__(Hello, world) 56.849 perf/13182 __bpf_stdout__(Hello, world) ^C # Cc: Adrian Hunter Cc: Jiri Olsa Cc: Namhyung Kim Link: https://lkml.kernel.org/n/tip-d9myswhgo8gfi3vmehdqpxa7@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo ","tools/perf/include/bpf/pid_filter.h | 2 +-; tools/perf/include/bpf/stdio.h | 2 +-; tools/perf/include/bpf/unistd.h | 2 +-; 3 files changed, 3 insertions(+), 3 deletions(-)","This commit refactors include paths for bpf.h in perf bpf to correct directory structure issues.","refactor, include, directory","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"45a4296b6e55ef2fbbe5946582822daf8f0f2e71","45a4296b6e55ef2fbbe5946582822daf8f0f2e71","Gustavo A. R. Silva","gustavo@embeddedor.com","1581969671","David S. Miller","davem@davemloft.net","1581995105","dc7844286facbf4b8eb78270c8afe7140fb782af","9814428a44d63bf77831afdbb37b5f0aab7394c9","bpf, sockmap: Replace zero-length array with flexible-array member The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: ""Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero.""[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f (""cxgb3/l2t: Fix undefined behaviour"") Signed-off-by: Gustavo A. R. Silva Signed-off-by: David S. Miller ","net/core/sock_map.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","The commit refactors code by replacing a zero-length array with a flexible-array member in the sockmap structure.","flexible-array,sockmap,refactoring","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"e20d3a055a457a10a4c748ce5b7c2ed3173a1324","e20d3a055a457a10a4c748ce5b7c2ed3173a1324","Johannes Krude","johannes@krude.de","1581535947","Daniel Borkmann","daniel@iogearbox.net","1581954829","8b7f7817b287bdc7c722cc0a075b516d347dd307","eecd618b45166fdddea3b6366b18479c2be0e11c","bpf, offload: Replace bitwise AND by logical AND in bpf_prog_offload_info_fill This if guards whether user-space wants a copy of the offload-jited bytecode and whether this bytecode exists. By erroneously doing a bitwise AND instead of a logical AND on user- and kernel-space buffer-size can lead to no data being copied to user-space especially when user-space size is a power of two and bigger then the kernel-space buffer. Fixes: fcfb126defda (""bpf: add new jited info fields in bpf_dev_offload and bpf_prog_info"") Signed-off-by: Johannes Krude Signed-off-by: Daniel Borkmann Acked-by: Jakub Kicinski Link: https://lore.kernel.org/bpf/20200212193227.GA3769@phlox.h.transitiv.net","kernel/bpf/offload.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","The commit corrects a logical error by replacing a bitwise AND with a logical AND in bpf_prog_offload_info_fill to ensure user-space data copying.","bpf, offload, fix","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"66256e0b15bd72e1e1c24c4cef4281a95636781c","66256e0b15bd72e1e1c24c4cef4281a95636781c","Randy Dunlap","rdunlap@infradead.org","1581795757","David S. Miller","davem@davemloft.net","1581910986","5e79f9ce2eac8f8ca832ec25e2072db1a7db61e3","58292104832fef6cb4a89f736012c0e0724c3442","net/sock.h: fix all kernel-doc warnings Fix all kernel-doc warnings for . Fixes these warnings: ../include/net/sock.h:232: warning: Function parameter or member 'skc_addrpair' not described in 'sock_common' ../include/net/sock.h:232: warning: Function parameter or member 'skc_portpair' not described in 'sock_common' ../include/net/sock.h:232: warning: Function parameter or member 'skc_ipv6only' not described in 'sock_common' ../include/net/sock.h:232: warning: Function parameter or member 'skc_net_refcnt' not described in 'sock_common' ../include/net/sock.h:232: warning: Function parameter or member 'skc_v6_daddr' not described in 'sock_common' ../include/net/sock.h:232: warning: Function parameter or member 'skc_v6_rcv_saddr' not described in 'sock_common' ../include/net/sock.h:232: warning: Function parameter or member 'skc_cookie' not described in 'sock_common' ../include/net/sock.h:232: warning: Function parameter or member 'skc_listener' not described in 'sock_common' ../include/net/sock.h:232: warning: Function parameter or member 'skc_tw_dr' not described in 'sock_common' ../include/net/sock.h:232: warning: Function parameter or member 'skc_rcv_wnd' not described in 'sock_common' ../include/net/sock.h:232: warning: Function parameter or member 'skc_tw_rcv_nxt' not described in 'sock_common' ../include/net/sock.h:498: warning: Function parameter or member 'sk_rx_skb_cache' not described in 'sock' ../include/net/sock.h:498: warning: Function parameter or member 'sk_wq_raw' not described in 'sock' ../include/net/sock.h:498: warning: Function parameter or member 'tcp_rtx_queue' not described in 'sock' ../include/net/sock.h:498: warning: Function parameter or member 'sk_tx_skb_cache' not described in 'sock' ../include/net/sock.h:498: warning: Function parameter or member 'sk_route_forced_caps' not described in 'sock' ../include/net/sock.h:498: warning: Function parameter or member 'sk_txtime_report_errors' not described in 'sock' ../include/net/sock.h:498: warning: Function parameter or member 'sk_validate_xmit_skb' not described in 'sock' ../include/net/sock.h:498: warning: Function parameter or member 'sk_bpf_storage' not described in 'sock' ../include/net/sock.h:2024: warning: No description found for return value of 'sk_wmem_alloc_get' ../include/net/sock.h:2035: warning: No description found for return value of 'sk_rmem_alloc_get' ../include/net/sock.h:2046: warning: No description found for return value of 'sk_has_allocations' ../include/net/sock.h:2082: warning: No description found for return value of 'skwq_has_sleeper' ../include/net/sock.h:2244: warning: No description found for return value of 'sk_page_frag' ../include/net/sock.h:2444: warning: Function parameter or member 'tcp_rx_skb_cache_key' not described in 'DECLARE_STATIC_KEY_FALSE' ../include/net/sock.h:2444: warning: Excess function parameter 'sk' description in 'DECLARE_STATIC_KEY_FALSE' ../include/net/sock.h:2444: warning: Excess function parameter 'skb' description in 'DECLARE_STATIC_KEY_FALSE' Signed-off-by: Randy Dunlap Signed-off-by: David S. Miller ","include/net/sock.h | 38 +++++++++++++++++++++++++++++++++-----; 1 file changed, 33 insertions(+), 5 deletions(-)","Fixed documentation warnings in net/sock.h by adding missing param descriptions.","documentation,warnings,net/sock.h","A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.","It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.","[""It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.""]" +"eecd618b45166fdddea3b6366b18479c2be0e11c","eecd618b45166fdddea3b6366b18479c2be0e11c","Jakub Sitnicki","jakub@cloudflare.com","1581503528","Daniel Borkmann","daniel@iogearbox.net","1581525884","0febc3b628c60262e56a2e352d8442e71f876e87","2fe77100553f3ac6b2105db8ae14b5ea4b43c108","selftests/bpf: Mark SYN cookie test skipped for UDP sockets SYN cookie test with reuseport BPF doesn't make sense for UDP sockets. We don't run it but the test_progs test runner doesn't know about it. Mark the test as skipped so the test_progs can report correctly how many tests were skipped. Fixes: 7ee0d4e97b88 (""selftests/bpf: Switch reuseport tests for test_progs framework"") Reported-by: Lorenz Bauer Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200212103208.438419-1-jakub@cloudflare.com","tools/testing/selftests/bpf/prog_tests/select_reuseport.c | 4 +++-; 1 file changed, 3 insertions(+), 1 deletion(-)","The commit marks SYN cookie test as skipped for UDP sockets in BPF selftests for better reporting.","SYN,cookie,UDP","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"2fe77100553f3ac6b2105db8ae14b5ea4b43c108","2fe77100553f3ac6b2105db8ae14b5ea4b43c108","Martin KaFai Lau","kafai@fb.com","1581443950","Daniel Borkmann","daniel@iogearbox.net","1581525877","7ea21429a96895c05e3f8ecdd8c018a2641feacf","30744a68626db6a0029aca9c646831c869c16d83","selftests/bpf: Fix error checking on reading the tcp_fastopen sysctl There is a typo in checking the ""saved_tcp_fo"" and instead ""saved_tcp_syncookie"" is checked again. This patch fixes it and also breaks them into separate if statements such that the test will abort asap. Reported-by: David Binderman Signed-off-by: Martin KaFai Lau Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200211175910.3235321-1-kafai@fb.com","tools/testing/selftests/bpf/prog_tests/select_reuseport.c | 4 +++-; 1 file changed, 3 insertions(+), 1 deletion(-)","This commit fixes a typo in error checking within BPF self-tests related to TCP fast open sysctl configuration.","typo,error checking,sysctl","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"4ca54d3d3022ce27170b50e4bdecc3a42f05dbdc","4ca54d3d3022ce27170b50e4bdecc3a42f05dbdc","Connor O'Brien","connoro@google.com","1581098509","Paul Moore","paul@paul-moore.com","1581476574","26460de2a33da6426901e6a38bbacaac8fd43d81","89d4d7c88d2b4f252adb434a28ea9b84d629aeb1","security: selinux: allow per-file labeling for bpffs Add support for genfscon per-file labeling of bpffs files. This allows for separate permissions for different pinned bpf objects, which may be completely unrelated to each other. Signed-off-by: Connor O'Brien Signed-off-by: Steven Moreland Acked-by: Stephen Smalley Signed-off-by: Paul Moore ","security/selinux/hooks.c | 1 +; 1 file changed, 1 insertion(+)","Add per-file labeling support for bpffs in SELinux to manage permissions for distinct pinned BPF objects.","SELinux,bpffs,labeling","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['LSM type related programs. It relates to eBPF programs used with Linux Security Modules (LSMs) for security enhancements.']" +"457fed775c97ac2c0cd1672aaf2ff2c8a6235e87","457fed775c97ac2c0cd1672aaf2ff2c8a6235e87","Eric Dumazet","edumazet@google.com","1581363373","David S. Miller","davem@davemloft.net","1581469482","9407821c45777558f1973f21f2d05a291e7f8fe0","f27f37a04a69890ac85d9155f03ee2d23b678d8f","net/smc: fix leak of kernel memory to user space As nlmsg_put() does not clear the memory that is reserved, it this the caller responsability to make sure all of this memory will be written, in order to not reveal prior content. While we are at it, we can provide the socket cookie even if clsock is not set. syzbot reported : BUG: KMSAN: uninit-value in __arch_swab32 arch/x86/include/uapi/asm/swab.h:10 [inline] BUG: KMSAN: uninit-value in __fswab32 include/uapi/linux/swab.h:59 [inline] BUG: KMSAN: uninit-value in __swab32p include/uapi/linux/swab.h:179 [inline] BUG: KMSAN: uninit-value in __be32_to_cpup include/uapi/linux/byteorder/little_endian.h:82 [inline] BUG: KMSAN: uninit-value in get_unaligned_be32 include/linux/unaligned/access_ok.h:30 [inline] BUG: KMSAN: uninit-value in ____bpf_skb_load_helper_32 net/core/filter.c:240 [inline] BUG: KMSAN: uninit-value in ____bpf_skb_load_helper_32_no_cache net/core/filter.c:255 [inline] BUG: KMSAN: uninit-value in bpf_skb_load_helper_32_no_cache+0x14a/0x390 net/core/filter.c:252 CPU: 1 PID: 5262 Comm: syz-executor.5 Not tainted 5.5.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x220 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215 __arch_swab32 arch/x86/include/uapi/asm/swab.h:10 [inline] __fswab32 include/uapi/linux/swab.h:59 [inline] __swab32p include/uapi/linux/swab.h:179 [inline] __be32_to_cpup include/uapi/linux/byteorder/little_endian.h:82 [inline] get_unaligned_be32 include/linux/unaligned/access_ok.h:30 [inline] ____bpf_skb_load_helper_32 net/core/filter.c:240 [inline] ____bpf_skb_load_helper_32_no_cache net/core/filter.c:255 [inline] bpf_skb_load_helper_32_no_cache+0x14a/0x390 net/core/filter.c:252 Uninit was created at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:144 [inline] kmsan_internal_poison_shadow+0x66/0xd0 mm/kmsan/kmsan.c:127 kmsan_kmalloc_large+0x73/0xc0 mm/kmsan/kmsan_hooks.c:128 kmalloc_large_node_hook mm/slub.c:1406 [inline] kmalloc_large_node+0x282/0x2c0 mm/slub.c:3841 __kmalloc_node_track_caller+0x44b/0x1200 mm/slub.c:4368 __kmalloc_reserve net/core/skbuff.c:141 [inline] __alloc_skb+0x2fd/0xac0 net/core/skbuff.c:209 alloc_skb include/linux/skbuff.h:1049 [inline] netlink_dump+0x44b/0x1ab0 net/netlink/af_netlink.c:2224 __netlink_dump_start+0xbb2/0xcf0 net/netlink/af_netlink.c:2352 netlink_dump_start include/linux/netlink.h:233 [inline] smc_diag_handler_dump+0x2ba/0x300 net/smc/smc_diag.c:242 sock_diag_rcv_msg+0x211/0x610 net/core/sock_diag.c:256 netlink_rcv_skb+0x451/0x650 net/netlink/af_netlink.c:2477 sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:275 netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline] netlink_unicast+0xf9e/0x1100 net/netlink/af_netlink.c:1328 netlink_sendmsg+0x1248/0x14d0 net/netlink/af_netlink.c:1917 sock_sendmsg_nosec net/socket.c:639 [inline] sock_sendmsg net/socket.c:659 [inline] kernel_sendmsg+0x433/0x440 net/socket.c:679 sock_no_sendpage+0x235/0x300 net/core/sock.c:2740 kernel_sendpage net/socket.c:3776 [inline] sock_sendpage+0x1e1/0x2c0 net/socket.c:937 pipe_to_sendpage+0x38c/0x4c0 fs/splice.c:458 splice_from_pipe_feed fs/splice.c:512 [inline] __splice_from_pipe+0x539/0xed0 fs/splice.c:636 splice_from_pipe fs/splice.c:671 [inline] generic_splice_sendpage+0x1d5/0x2d0 fs/splice.c:844 do_splice_from fs/splice.c:863 [inline] do_splice fs/splice.c:1170 [inline] __do_sys_splice fs/splice.c:1447 [inline] __se_sys_splice+0x2380/0x3350 fs/splice.c:1427 __x64_sys_splice+0x6e/0x90 fs/splice.c:1427 do_syscall_64+0xb8/0x160 arch/x86/entry/common.c:296 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: f16a7dd5cf27 (""smc: netlink interface for SMC sockets"") Signed-off-by: Eric Dumazet Cc: Ursula Braun Signed-off-by: David S. Miller ","net/smc/smc_diag.c | 5 ++---; 1 file changed, 2 insertions(+), 3 deletions(-)","This commit addresses a memory leak to user space in the net/smc by ensuring proper memory handling.","memory,leak,user","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.","It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.","[""It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.""]" +"30744a68626db6a0029aca9c646831c869c16d83","30744a68626db6a0029aca9c646831c869c16d83","Magnus Karlsson","magnus.karlsson@intel.com","1581348432","Daniel Borkmann","daniel@iogearbox.net","1581432671","25971a1b9cdf51047e40baae29dee252a40c49af","2bf0eb9b3b0d099b20b2c4736436b666d78b94d5","xsk: Publish global consumer pointers when NAPI is finished The commit 4b638f13bab4 (""xsk: Eliminate the RX batch size"") introduced a much more lazy way of updating the global consumer pointers from the kernel side, by only doing so when running out of entries in the fill or Tx rings (the rings consumed by the kernel). This can result in a deadlock with the user application if the kernel requires more than one entry to proceed and the application cannot put these entries in the fill ring because the kernel has not updated the global consumer pointer since the ring is not empty. Fix this by publishing the local kernel side consumer pointer whenever we have completed Rx or Tx processing in the kernel. This way, user space will have an up-to-date view of the consumer pointers whenever it gets to execute in the one core case (application and driver on the same core), or after a certain number of packets have been processed in the two core case (application and driver on different cores). A side effect of this patch is that the one core case gets better performance, but the two core case gets worse. The reason that the one core case improves is that updating the global consumer pointer is relatively cheap since the application by definition is not running when the kernel is (they are on the same core) and it is beneficial for the application, once it gets to run, to have pointers that are as up to date as possible since it then can operate on more packets and buffers. In the two core case, the most important performance aspect is to minimize the number of accesses to the global pointers since they are shared between two cores and bounces between the caches of those cores. This patch results in more updates to global state, which means lower performance in the two core case. Fixes: 4b638f13bab4 (""xsk: Eliminate the RX batch size"") Reported-by: Ryan Goodfellow Reported-by: Maxim Mikityanskiy Signed-off-by: Magnus Karlsson Signed-off-by: Daniel Borkmann Acked-by: Jonathan Lemon Acked-by: Maxim Mikityanskiy Link: https://lore.kernel.org/bpf/1581348432-6747-1-git-send-email-magnus.karlsson@intel.com","net/xdp/xsk.c | 2 ++; net/xdp/xsk_queue.h | 3 ++-; 2 files changed, 4 insertions(+), 1 deletion(-)","This commit resolves a deadlock issue in XSK by updating global consumer pointers after kernel processing.","xsk,deadlock,performance","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.', 'Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"c363eb48ada5cf732b3f489fab799fc881097842","c363eb48ada5cf732b3f489fab799fc881097842","Jiri Benc","jbenc@redhat.com","1580978452","Shuah Khan","skhan@linuxfoundation.org","1581382915","fdc7d79777d25b7649a7ffd556b0bb2b97d367ca","9d235a558c689b0ecdd23bbd8beb2e0584f619ed","selftests: fix too long argument With some shells, the command construed for install of bpf selftests becomes too large due to long list of files: make[1]: execvp: /bin/sh: Argument list too long make[1]: *** [../lib.mk:73: install] Error 127 Currently, each of the file lists is replicated three times in the command: in the shell 'if' condition, in the 'echo' and in the 'rsync'. Reduce that by one instance by using make conditionals and separate the echo and rsync into two shell commands. (One would be inclined to just remove the '@' at the beginning of the rsync command and let 'make' echo it by itself; unfortunately, it appears that the '@' in the front of mkdir silences output also for the following commands.) Also, separate handling of each of the lists to its own shell command. The semantics of the makefile is unchanged before and after the patch. The ability of individual test directories to override INSTALL_RULE is retained. Reported-by: Yauheni Kaliuta Tested-by: Yauheni Kaliuta Signed-off-by: Jiri Benc Signed-off-by: Shuah Khan ","tools/testing/selftests/lib.mk | 23 +++++++++++++----------; 1 file changed, 13 insertions(+), 10 deletions(-)","Refactor selftests makefile to fix argument list too long error by optimizing command structure.","selftests, makefile, refactor","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"2bf0eb9b3b0d099b20b2c4736436b666d78b94d5","2bf0eb9b3b0d099b20b2c4736436b666d78b94d5","Hongbo Yao","yaohongbo@huawei.com","1581297281","Daniel Borkmann","daniel@iogearbox.net","1581376967","ed31b7f79bc6bb14daf78addbba25fc2ca39fbba","f2e97dc126b712c0d21219ed0c42710006c1cf52","bpf: Make btf_check_func_type_match() static Fix the following sparse warning: kernel/bpf/btf.c:4131:5: warning: symbol 'btf_check_func_type_match' was not declared. Should it be static? Reported-by: Hulk Robot Signed-off-by: Hongbo Yao Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200210011441.147102-1-yaohongbo@huawei.com","kernel/bpf/btf.c | 6 +++---; 1 file changed, 3 insertions(+), 3 deletions(-)","This commit fixes a sparse warning by making the btf_check_func_type_match function static in the BPF subsystem.","static,function,sparse","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.","BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"f2e97dc126b712c0d21219ed0c42710006c1cf52","f2e97dc126b712c0d21219ed0c42710006c1cf52","John Fastabend","john.fastabend@gmail.com","1581313477","Alexei Starovoitov","ast@kernel.org","1581373894","39099947299f0470ebd3956272876fcf0db022c2","00516d13d4cfa56ce39da144db2dbf08b09b9357","bpf: Selftests build error in sockmap_basic.c Fix following build error. We could push a tcp.h header into one of the include paths, but I think its easy enough to simply pull in the three defines we need here. If we end up using more of tcp.h at some point we can pull it in later. /home/john/git/bpf/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c: In function ‘connected_socket_v4’: /home/john/git/bpf/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c:20:11: error: ‘TCP_REPAIR_ON’ undeclared (first use in this function) repair = TCP_REPAIR_ON; ^ /home/john/git/bpf/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c:20:11: note: each undeclared identifier is reported only once for each function it appears in /home/john/git/bpf/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c:29:11: error: ‘TCP_REPAIR_OFF_NO_WP’ undeclared (first use in this function) repair = TCP_REPAIR_OFF_NO_WP; Then with fix, $ ./test_progs -n 44 #44/1 sockmap create_update_free:OK #44/2 sockhash create_update_free:OK #44 sockmap_basic:OK Fixes: 5d3919a953c3c (""selftests/bpf: Test freeing sockmap/sockhash with a socket in it"") Signed-off-by: John Fastabend Signed-off-by: Alexei Starovoitov Reviewed-by: Jakub Sitnicki Link: https://lore.kernel.org/bpf/158131347731.21414.12120493483848386652.stgit@john-Precision-5820-Tower","tools/testing/selftests/bpf/prog_tests/sockmap_basic.c | 5 +++++; 1 file changed, 5 insertions(+)","Fixes build error in sockmap_basic.c by adding missing TCP_REPAIR definitions.","selftests,sockmap,TCP_REPAIR","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"291abfea4746897b821830e0189dc225abd401eb","291abfea4746897b821830e0189dc225abd401eb","Linus Torvalds","torvalds@linux-foundation.org","1581210908","Linus Torvalds","torvalds@linux-foundation.org","1581210908","cbdf93a2ade8842c80a2272fae2088f33c09b336","d4f309ca411887cd61ea389c7abfb70c2eb1e532 29ca3b31756fb7cfbfc85f2d82a0475bf38cc1ed","Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from David Miller: 1) Unbalanced locking in mwifiex_process_country_ie, from Brian Norris. 2) Fix thermal zone registration in iwlwifi, from Andrei Otcheretianski. 3) Fix double free_irq in sgi ioc3 eth, from Thomas Bogendoerfer. 4) Use after free in mptcp, from Florian Westphal. 5) Use after free in wireguard's root_remove_peer_lists, from Eric Dumazet. 6) Properly access packets heads in bonding alb code, from Eric Dumazet. 7) Fix data race in skb_queue_len(), from Qian Cai. 8) Fix regression in r8169 on some chips, from Heiner Kallweit. 9) Fix XDP program ref counting in hv_netvsc, from Haiyang Zhang. 10) Certain kinds of set link netlink operations can cause a NULL deref in the ipv6 addrconf code. Fix from Eric Dumazet. 11) Don't cancel uninitialized work queue in drop monitor, from Ido Schimmel. * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (84 commits) net: thunderx: use proper interface type for RGMII mt76: mt7615: fix max_nss in mt7615_eeprom_parse_hw_cap bpf: Improve bucket_log calculation logic selftests/bpf: Test freeing sockmap/sockhash with a socket in it bpf, sockhash: Synchronize_rcu before free'ing map bpf, sockmap: Don't sleep while holding RCU lock on tear-down bpftool: Don't crash on missing xlated program instructions bpf, sockmap: Check update requirements after locking drop_monitor: Do not cancel uninitialized work item mlxsw: spectrum_dpipe: Add missing error path mlxsw: core: Add validation of hardware device types for MGPIR register mlxsw: spectrum_router: Clear offload indication from IPv6 nexthops on abort selftests: mlxsw: Add test cases for local table route replacement mlxsw: spectrum_router: Prevent incorrect replacement of local table routes net: dsa: microchip: enable module autoprobe ipv6/addrconf: fix potential NULL deref in inet6_set_link_af() dpaa_eth: support all modes with rate adapting PHYs net: stmmac: update pci platform data to use phy_interface net: stmmac: xgmac: fix missing IFF_MULTICAST checki in dwxgmac2_set_filter net: stmmac: fix missing IFF_MULTICAST check in dwmac4_set_filter ...","","Merge commit incorporating networking fixes including unbalanced locking and race condition resolutions.","networking,merge,fixes","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"2696e1146d3490f1af4b0080955bf1628bd8ab85","2696e1146d3490f1af4b0080955bf1628bd8ab85","David S. Miller","davem@davemloft.net","1581170463","David S. Miller","davem@davemloft.net","1581170463","54f7e295c3cff749a399f37d55b54022e5a48194","dfa7f709596be5ca46c070d4f8acbb344322056a 88d6f130e5632bbf419a2e184ec7adcbe241260b","Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf Daniel Borkmann says: ==================== pull-request: bpf 2020-02-07 The following pull-request contains BPF updates for your *net* tree. We've added 15 non-merge commits during the last 10 day(s) which contain a total of 12 files changed, 114 insertions(+), 31 deletions(-). The main changes are: 1) Various BPF sockmap fixes related to RCU handling in the map's tear- down code, from Jakub Sitnicki. 2) Fix macro state explosion in BPF sk_storage map when calculating its bucket_log on allocation, from Martin KaFai Lau. 3) Fix potential BPF sockmap update race by rechecking socket's established state under lock, from Lorenz Bauer. 4) Fix crash in bpftool on missing xlated instructions when kptr_restrict sysctl is set, from Toke Høiland-Jørgensen. 5) Fix i40e's XSK wakeup code to return proper error in busy state and various misc fixes in xdpsock BPF sample code, from Maciej Fijalkowski. 6) Fix the way modifiers are skipped in BTF in the verifier while walking pointers to avoid program rejection, from Alexei Starovoitov. 7) Fix Makefile for runqslower BPF tool to i) rebuild on libbpf changes and ii) to fix undefined reference linker errors for older gcc version due to order of passed gcc parameters, from Yulia Kartseva and Song Liu. 8) Fix a trampoline_count BPF kselftest warning about missing braces around initializer, from Andrii Nakryiko. 9) Fix up redundant ""HAVE"" prefix from large INSN limit kernel probe in bpftool, from Michal Rostecki. ==================== Signed-off-by: David S. Miller ","","The commit merges BPF updates addressing issues in sockmap, sk_storage, and various other components.","BPF,sockmap,fixes","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"88d6f130e5632bbf419a2e184ec7adcbe241260b","88d6f130e5632bbf419a2e184ec7adcbe241260b","Martin KaFai Lau","kafai@fb.com","1581063490","Daniel Borkmann","daniel@iogearbox.net","1581112901","f5eef5513c35757cf56d82496e670a3e4033ac55","5d3919a953c3c96c02fc7a337f8376cde43ae31f","bpf: Improve bucket_log calculation logic It was reported that the max_t, ilog2, and roundup_pow_of_two macros have exponential effects on the number of states in the sparse checker. This patch breaks them up by calculating the ""nbuckets"" first so that the ""bucket_log"" only needs to take ilog2(). In addition, Linus mentioned: Patch looks good, but I'd like to point out that it's not just sparse. You can see it with a simple make net/core/bpf_sk_storage.i grep 'smap->bucket_log = ' net/core/bpf_sk_storage.i | wc and see the end result: 1 365071 2686974 That's one line (the assignment line) that is 2,686,974 characters in length. Now, sparse does happen to react particularly badly to that (I didn't look to why, but I suspect it's just that evaluating all the types that don't actually ever end up getting used ends up being much more expensive than it should be), but I bet it's not good for gcc either. Fixes: 6ac99e8f23d4 (""bpf: Introduce bpf sk local storage"") Reported-by: Randy Dunlap Reported-by: Luc Van Oostenryck Suggested-by: Linus Torvalds Signed-off-by: Martin KaFai Lau Signed-off-by: Daniel Borkmann Reviewed-by: Luc Van Oostenryck Link: https://lore.kernel.org/bpf/20200207081810.3918919-1-kafai@fb.com","net/core/bpf_sk_storage.c | 5 +++--; 1 file changed, 3 insertions(+), 2 deletions(-)","This commit refactors the bucket_log calculation to improve compiler efficiency and reduce sparse checker complexity.","bucket_log, refactor, efficiency","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"5d3919a953c3c96c02fc7a337f8376cde43ae31f","5d3919a953c3c96c02fc7a337f8376cde43ae31f","Jakub Sitnicki","jakub@cloudflare.com","1580987812","Daniel Borkmann","daniel@iogearbox.net","1581111386","9bd584a0bf1c7a7ea0ccd05c4f644f622b1670bd","0b2dc83906cf1e694e48003eae5df8fa63f76fd9","selftests/bpf: Test freeing sockmap/sockhash with a socket in it Commit 7e81a3530206 (""bpf: Sockmap, ensure sock lock held during tear down"") introduced sleeping issues inside RCU critical sections and while holding a spinlock on sockmap/sockhash tear-down. There has to be at least one socket in the map for the problem to surface. This adds a test that triggers the warnings for broken locking rules. Not a fix per se, but rather tooling to verify the accompanying fixes. Run on a VM with 1 vCPU to reproduce the warnings. Fixes: 7e81a3530206 (""bpf: Sockmap, ensure sock lock held during tear down"") Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200206111652.694507-4-jakub@cloudflare.com",".../selftests/bpf/prog_tests/sockmap_basic.c | 74 ++++++++++++++++++++++; 1 file changed, 74 insertions(+)","This commit adds a test to identify broken locking rules in sockmap/sockhash teardown.","sockmap,sockhash,test","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"0b2dc83906cf1e694e48003eae5df8fa63f76fd9","0b2dc83906cf1e694e48003eae5df8fa63f76fd9","Jakub Sitnicki","jakub@cloudflare.com","1580987811","Daniel Borkmann","daniel@iogearbox.net","1581111386","2cb216e87bfd171ea95e8af962f20ed0fa2a3e96","db6a5018b6e008c1d69c6628cdaa9541b8e70940","bpf, sockhash: Synchronize_rcu before free'ing map We need to have a synchronize_rcu before free'ing the sockhash because any outstanding psock references will have a pointer to the map and when they use it, this could trigger a use after free. This is a sister fix for sockhash, following commit 2bb90e5cc90e (""bpf: sockmap, synchronize_rcu before free'ing map"") which addressed sockmap, which comes from a manual audit. Fixes: 604326b41a6fb (""bpf, sockmap: convert to generic sk_msg interface"") Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200206111652.694507-3-jakub@cloudflare.com","net/core/sock_map.c | 4 ++++; 1 file changed, 4 insertions(+)","Adds synchronize_rcu to sockhash to prevent use-after-free issues when freeing the map.","synchronize_rcu,sockhash,use-after-free","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"db6a5018b6e008c1d69c6628cdaa9541b8e70940","db6a5018b6e008c1d69c6628cdaa9541b8e70940","Jakub Sitnicki","jakub@cloudflare.com","1580987810","Daniel Borkmann","daniel@iogearbox.net","1581111386","1d8f8868db5f10ce8a7ccb2e7980270604c62f6b","d95f1e8b462c4372ac409886070bb8719d8a4d3a","bpf, sockmap: Don't sleep while holding RCU lock on tear-down rcu_read_lock is needed to protect access to psock inside sock_map_unref when tearing down the map. However, we can't afford to sleep in lock_sock while in RCU read-side critical section. Grab the RCU lock only after we have locked the socket. This fixes RCU warnings triggerable on a VM with 1 vCPU when free'ing a sockmap/sockhash that contains at least one socket: | ============================= | WARNING: suspicious RCU usage | 5.5.0-04005-g8fc91b972b73 #450 Not tainted | ----------------------------- | include/linux/rcupdate.h:272 Illegal context switch in RCU read-side critical section! | | other info that might help us debug this: | | | rcu_scheduler_active = 2, debug_locks = 1 | 4 locks held by kworker/0:1/62: | #0: ffff88813b019748 ((wq_completion)events){+.+.}, at: process_one_work+0x1d7/0x5e0 | #1: ffffc900000abe50 ((work_completion)(&map->work)){+.+.}, at: process_one_work+0x1d7/0x5e0 | #2: ffffffff82065d20 (rcu_read_lock){....}, at: sock_map_free+0x5/0x170 | #3: ffff8881368c5df8 (&stab->lock){+...}, at: sock_map_free+0x64/0x170 | | stack backtrace: | CPU: 0 PID: 62 Comm: kworker/0:1 Not tainted 5.5.0-04005-g8fc91b972b73 #450 | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 | Workqueue: events bpf_map_free_deferred | Call Trace: | dump_stack+0x71/0xa0 | ___might_sleep+0x105/0x190 | lock_sock_nested+0x28/0x90 | sock_map_free+0x95/0x170 | bpf_map_free_deferred+0x58/0x80 | process_one_work+0x260/0x5e0 | worker_thread+0x4d/0x3e0 | kthread+0x108/0x140 | ? process_one_work+0x5e0/0x5e0 | ? kthread_park+0x90/0x90 | ret_from_fork+0x3a/0x50 | ============================= | WARNING: suspicious RCU usage | 5.5.0-04005-g8fc91b972b73-dirty #452 Not tainted | ----------------------------- | include/linux/rcupdate.h:272 Illegal context switch in RCU read-side critical section! | | other info that might help us debug this: | | | rcu_scheduler_active = 2, debug_locks = 1 | 4 locks held by kworker/0:1/62: | #0: ffff88813b019748 ((wq_completion)events){+.+.}, at: process_one_work+0x1d7/0x5e0 | #1: ffffc900000abe50 ((work_completion)(&map->work)){+.+.}, at: process_one_work+0x1d7/0x5e0 | #2: ffffffff82065d20 (rcu_read_lock){....}, at: sock_hash_free+0x5/0x1d0 | #3: ffff888139966e00 (&htab->buckets[i].lock){+...}, at: sock_hash_free+0x92/0x1d0 | | stack backtrace: | CPU: 0 PID: 62 Comm: kworker/0:1 Not tainted 5.5.0-04005-g8fc91b972b73-dirty #452 | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 | Workqueue: events bpf_map_free_deferred | Call Trace: | dump_stack+0x71/0xa0 | ___might_sleep+0x105/0x190 | lock_sock_nested+0x28/0x90 | sock_hash_free+0xec/0x1d0 | bpf_map_free_deferred+0x58/0x80 | process_one_work+0x260/0x5e0 | worker_thread+0x4d/0x3e0 | kthread+0x108/0x140 | ? process_one_work+0x5e0/0x5e0 | ? kthread_park+0x90/0x90 | ret_from_fork+0x3a/0x50 Fixes: 7e81a3530206 (""bpf: Sockmap, ensure sock lock held during tear down"") Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200206111652.694507-2-jakub@cloudflare.com","net/core/sock_map.c | 8 ++++----; 1 file changed, 4 insertions(+), 4 deletions(-)","Fix RCU warning in sockmap teardown by adjusting lock sequence to avoid sleeping while holding RCU lock.","RCU,sockmap,teardown","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"d95f1e8b462c4372ac409886070bb8719d8a4d3a","d95f1e8b462c4372ac409886070bb8719d8a4d3a","Toke Høiland-Jørgensen","toke@redhat.com","1580984946","Daniel Borkmann","daniel@iogearbox.net","1581110985","51b5933cf72754517120706d152f3205285512f3","85b8ac01a421791d66c3a458a7f83cfd173fe3fa","bpftool: Don't crash on missing xlated program instructions Turns out the xlated program instructions can also be missing if kptr_restrict sysctl is set. This means that the previous fix to check the jited_prog_insns pointer was insufficient; add another check of the xlated_prog_insns pointer as well. Fixes: 5b79bcdf0362 (""bpftool: Don't crash on missing jited insns or ksyms"") Fixes: cae73f233923 (""bpftool: use bpf_program__get_prog_info_linear() in prog.c:do_dump()"") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200206102906.112551-1-toke@redhat.com","tools/bpf/bpftool/prog.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","The commit updates bpftool to prevent crashes when xlated program instructions are missing due to kptr_restrict sysctl settings.","bpftool,missing,instructions","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"85b8ac01a421791d66c3a458a7f83cfd173fe3fa","85b8ac01a421791d66c3a458a7f83cfd173fe3fa","Lorenz Bauer","lmb@cloudflare.com","1581071832","Daniel Borkmann","daniel@iogearbox.net","1581110884","b50e4a5dd262197e651fefbab87fa13317a4e4d1","b9e42724888527352604260abc6717cba21421de","bpf, sockmap: Check update requirements after locking It's currently possible to insert sockets in unexpected states into a sockmap, due to a TOCTTOU when updating the map from a syscall. sock_map_update_elem checks that sk->sk_state == TCP_ESTABLISHED, locks the socket and then calls sock_map_update_common. At this point, the socket may have transitioned into another state, and the earlier assumptions don't hold anymore. Crucially, it's conceivable (though very unlikely) that a socket has become unhashed. This breaks the sockmap's assumption that it will get a callback via sk->sk_prot->unhash. Fix this by checking the (fixed) sk_type and sk_protocol without the lock, followed by a locked check of sk_state. Unfortunately it's not possible to push the check down into sock_(map|hash)_update_common, since BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB run before the socket has transitioned from TCP_SYN_RECV into TCP_ESTABLISHED. Fixes: 604326b41a6f (""bpf, sockmap: convert to generic sk_msg interface"") Signed-off-by: Lorenz Bauer Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Sitnicki Link: https://lore.kernel.org/bpf/20200207103713.28175-1-lmb@cloudflare.com","net/core/sock_map.c | 16 ++++++++++------; 1 file changed, 10 insertions(+), 6 deletions(-)","Fixes TOCTTOU bug in sockmap by adding state checks to prevent sockets in unintended states.","sockmap, TOCTTOU, state","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"184367dce4f744bde54377203305ccc8889aa79f","184367dce4f744bde54377203305ccc8889aa79f","Haiyang Zhang","haiyangz@microsoft.com","1581026465","David S. Miller","davem@davemloft.net","1581071581","c2d9b5c2ef577f04482af7065944b71f5ddc0fe0","6910fe95c61880e75b1c3a20eb13a6fd01ca501a","hv_netvsc: Fix XDP refcnt for synthetic and VF NICs The caller of XDP_SETUP_PROG has already incremented refcnt in __bpf_prog_get(), so drivers should only increment refcnt by num_queues - 1. To fix the issue, update netvsc_xdp_set() to add the correct number to refcnt. Hold a refcnt in netvsc_xdp_set()’s other caller, netvsc_attach(). And, do the same in netvsc_vf_setxdp(). Otherwise, every time when VF is removed and added from the host side, the refcnt will be decreased by one, which may cause page fault when unloading xdp program. Fixes: 351e1581395f (""hv_netvsc: Add XDP support"") Signed-off-by: Haiyang Zhang Signed-off-by: David S. Miller ","drivers/net/hyperv/netvsc_bpf.c | 13 +++++++++++--; drivers/net/hyperv/netvsc_drv.c | 5 ++++-; 2 files changed, 15 insertions(+), 3 deletions(-)","Fixes refcnt handling in hv_netvsc XDP implementation to avoid page faults on synthetic and VF NICs.","hv_netvsc,XDP,refcnt","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime."", ""I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear.""]" +"f1ed10264ed6b66b9cd5e8461cffce69be482356","f1ed10264ed6b66b9cd5e8461cffce69be482356","Nicolas Dichtel","nicolas.dichtel@6wind.com","1580832027","Steffen Klassert","steffen.klassert@secunet.com","1580992050","ecfa75eb27f6234e38ab89c5d757b860bb2a189c","03891f820c2117b19e80b370281eb924a09cf79f","vti[6]: fix packet tx through bpf_redirect() in XinY cases I forgot the 4in6/6in4 cases in my previous patch. Let's fix them. Fixes: 95224166a903 (""vti[6]: fix packet tx through bpf_redirect()"") Signed-off-by: Nicolas Dichtel Signed-off-by: Steffen Klassert ","net/ipv4/Kconfig | 1 +; net/ipv4/ip_vti.c | 38 ++++++++++++++++++++++++++++++--------; net/ipv6/ip6_vti.c | 32 +++++++++++++++++++++++++-------; 3 files changed, 56 insertions(+), 15 deletions(-)","Fix packet transmission through bpf_redirect() for 4in6 and 6in4 cases in vti interfaces.","bpf_redirect vti fix","A bug fix. It primarily resolves a bug or issue in the code.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.","It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.","[""It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here.""]" +"b9e42724888527352604260abc6717cba21421de","b9e42724888527352604260abc6717cba21421de","Daniel Borkmann","daniel@iogearbox.net","1580936769","Daniel Borkmann","daniel@iogearbox.net","1580936772","d664c62878db152984cb9317a94e5d858515542b","fc9e34f8de001c92e6cfc6481bb30a34dbda4f5c 8ed47e140867a6e7d56170f325c8d4fdee6d6b66","Merge branch 'bpf-xsk-fixes' Maciej Fijalkowski says: ==================== Cameron reported [0] that on fresh bpf-next he could not run multiple xdpsock instances in Tx-only mode on single network interface with i40e driver. Turns out that Maxim's series [1] which was adding RCU protection around ndo_xsk_wakeup added check against the __I40E_CONFIG_BUSY being set on pf->state within i40e_xsk_wakeup() - if it's set, return -ENETDOWN. Since this bit is set per PF when UMEM is being enabled/disabled, the situation Cameron stumbled upon was that when he launched second xdpsock instance, second UMEM was being registered, hence set __I40E_CONFIG_BUSY which is now observed by first xdpsock and therefore xdpsock's kick_tx() gets -ENETDOWN as errno. -ENETDOWN currently is not allowed in kick_tx(), so we were exiting the first application. Such exit means also XDP program being unloaded and its dedicated resources, which caused an -ENXIO being return in the second xdpsock instance. Let's fix the issue from both sides - protect ourselves from future xdpsock crashes by allowing for -ENETDOWN errno being set in kick_tx() (patch 3) and from driver side, return -EAGAIN for the case where PF is busy (patch 1). Remove also doubled variable from xdpsock_user.c (patch 2). Note that ixgbe seems not to be affected since UMEM registration sets the busy/disable bit per ring, not per PF. [0]: https://www.spinics.net/lists/xdp-newbies/msg01558.html [1]: https://lore.kernel.org/netdev/20191217162023.16011-1-maximmi@mellanox.com/ ==================== Signed-off-by: Daniel Borkmann ","","Fixes issues with xdpsock instances in Tx-only mode on i40e driver by handling -ENETDOWN and -EAGAIN errors.","xdpsock,ENETDOWN,UMEM","A bug fix. It primarily resolves a bug or issue in the code.","I'm not sure about the complexity of the commit. It is difficult to estimate the complexity based on the provided commit details.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.']" +"8ed47e140867a6e7d56170f325c8d4fdee6d6b66","8ed47e140867a6e7d56170f325c8d4fdee6d6b66","Maciej Fijalkowski","maciej.fijalkowski@intel.com","1580878714","Daniel Borkmann","daniel@iogearbox.net","1580936769","d664c62878db152984cb9317a94e5d858515542b","32c92c15ad3dca6f7cca8643766ad79fa3ab3d17","samples: bpf: Allow for -ENETDOWN in xdpsock ndo_xsk_wakeup() can return -ENETDOWN and there's no particular reason to bail the whole application out on that case. Let's check in kick_tx() whether errno was set to mentioned value and basically allow application to further process frames. Fixes: 248c7f9c0e21 (""samples/bpf: convert xdpsock to use libbpf for AF_XDP access"") Reported-by: Cameron Elliott Signed-off-by: Maciej Fijalkowski Signed-off-by: Daniel Borkmann Acked-by: Björn Töpel Link: https://lore.kernel.org/bpf/20200205045834.56795-4-maciej.fijalkowski@intel.com","samples/bpf/xdpsock_user.c | 3 ++-; 1 file changed, 2 insertions(+), 1 deletion(-)","This commit modifies the xdpsock sample application to handle the -ENETDOWN error without terminating.","xdpsock,errno,ENETDOWN","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.']" +"32c92c15ad3dca6f7cca8643766ad79fa3ab3d17","32c92c15ad3dca6f7cca8643766ad79fa3ab3d17","Maciej Fijalkowski","maciej.fijalkowski@intel.com","1580878713","Daniel Borkmann","daniel@iogearbox.net","1580936769","5764c11370772c61c755b754279b83bdbc663728","c77e9f09143822623dd71a0fdc84331129e97c3a","samples: bpf: Drop doubled variable declaration in xdpsock Seems that by accident there is a doubled declaration of global variable opt_xdp_bind_flags in xdpsock_user.c. The second one is uninitialized so compiler was simply ignoring it. To keep things clean, drop the doubled variable. Fixes: c543f5469822 (""samples/bpf: add unaligned chunks mode support to xdpsock"") Signed-off-by: Maciej Fijalkowski Signed-off-by: Daniel Borkmann Acked-by: Björn Töpel Link: https://lore.kernel.org/bpf/20200205045834.56795-3-maciej.fijalkowski@intel.com","samples/bpf/xdpsock_user.c | 1 -; 1 file changed, 1 deletion(-)","The commit removes a duplicated global variable declaration in the eBPF sample code for xdpsock.","xdpsock variable declaration","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"c77e9f09143822623dd71a0fdc84331129e97c3a","c77e9f09143822623dd71a0fdc84331129e97c3a","Maciej Fijalkowski","maciej.fijalkowski@intel.com","1580878712","Daniel Borkmann","daniel@iogearbox.net","1580936768","ad17a26e849fee488d9014f9a7e7f9ba2ce1cc1e","fc9e34f8de001c92e6cfc6481bb30a34dbda4f5c","i40e: Relax i40e_xsk_wakeup's return value when PF is busy Return -EAGAIN instead of -ENETDOWN to provide a slightly milder information to user space so that an application will know to retry the syscall when __I40E_CONFIG_BUSY bit is set on pf->state. Fixes: b3873a5be757 (""net/i40e: Fix concurrency issues between config flow and XSK"") Signed-off-by: Maciej Fijalkowski Signed-off-by: Daniel Borkmann Acked-by: Björn Töpel Link: https://lore.kernel.org/bpf/20200205045834.56795-2-maciej.fijalkowski@intel.com","drivers/net/ethernet/intel/i40e/i40e_xsk.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","The commit changes the return value of i40e_xsk_wakeup to -EAGAIN when the PF is busy, for signaling application to retry.","i40e,return value,EAGAIN","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.","It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.","[""It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.""]" +"fc9e34f8de001c92e6cfc6481bb30a34dbda4f5c","fc9e34f8de001c92e6cfc6481bb30a34dbda4f5c","Song Liu","songliubraving@fb.com","1580853037","Daniel Borkmann","daniel@iogearbox.net","1580936728","80db69f1565d7607dd903a838cfc7099786e1004","8fc91b972b734a62a3f3ef45db06d06617f739ea","tools/bpf/runqslower: Rebuild libbpf.a on libbpf source change Add missing dependency of $(BPFOBJ) to $(LIBBPF_SRC), so that running make in runqslower/ will rebuild libbpf.a when there is change in libbpf/. Fixes: 9c01546d26d2 (""tools/bpf: Add runqslower tool to tools/bpf"") Signed-off-by: Song Liu Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200204215037.2258698-1-songliubraving@fb.com","tools/bpf/runqslower/Makefile | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","Fix the Makefile in runqslower to trigger rebuild of libbpf.a when there are source changes in libbpf.","runqslower libbpf Makefile","A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"9afe2322cb90a8fbc27e32bfc691100c653cab2a","9afe2322cb90a8fbc27e32bfc691100c653cab2a","David S. Miller","davem@davemloft.net","1580805000","David S. Miller","davem@davemloft.net","1580805000","1570511dab2b0b93e1db7024053ca2c0e1468f7b","2b5b8251bc9fe2f9118411f037862ee17cf81e97 e9ed4fa7b4400d7b2cf03108842a30e6c9bd0eb2","Merge branch 'unbreak-basic-and-bpf-tdc-testcases' Davide Caratti says: ==================== unbreak 'basic' and 'bpf' tdc testcases - patch 1/2 fixes tdc failures with 'bpf' action on fresch clones of the kernel tree - patch 2/2 allow running tdc for the 'basic' classifier without tweaking tdc_config.py ==================== Signed-off-by: David S. Miller ","","This commit merges updates to fix issues with 'basic' and 'bpf' TDC test cases.","merge,fix,testcases","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"7145fcfffef1fad4266aaf5ca96727696916edb7","7145fcfffef1fad4266aaf5ca96727696916edb7","Davide Caratti","dcaratti@redhat.com","1580743769","David S. Miller","davem@davemloft.net","1580805000","f765e10d9e8efc18a13cc4ee4146ef7685448b16","2b5b8251bc9fe2f9118411f037862ee17cf81e97","tc-testing: fix eBPF tests failure on linux fresh clones when the following command is done on a fresh clone of the kernel tree, [root@f31 tc-testing]# ./tdc.py -c bpf test cases that need to build the eBPF sample program fail systematically, because 'buildebpfPlugin' is unable to install the kernel headers (i.e, the 'khdr' target fails). Pass the correct environment to 'make', in place of ENVIR, to allow running these tests. Fixes: 4c2d39bd40c1 (""tc-testing: use a plugin to build eBPF program"") Signed-off-by: Davide Caratti Signed-off-by: David S. Miller ","tools/testing/selftests/tc-testing/plugin-lib/buildebpfPlugin.py | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","The commit fixes failure in eBPF tests on fresh kernel clones by correcting environment variable usage during build.","eBPF, tests, failure","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"8fc91b972b734a62a3f3ef45db06d06617f739ea","8fc91b972b734a62a3f3ef45db06d06617f739ea","Andrii Nakryiko","andriin@fb.com","1580626312","Daniel Borkmann","daniel@iogearbox.net","1580771329","3af408c796e2171a4793374f107be5f3166b1727","257af63d7f84f0672aa6a24b5511871f00741f19","selftests/bpf: Fix trampoline_count.c selftest compilation warning Fix missing braces compilation warning in trampoline_count test: .../prog_tests/trampoline_count.c: In function ‘test_trampoline_count’: .../prog_tests/trampoline_count.c:49:9: warning: missing braces around initializer [-Wmissing-braces] struct inst inst[MAX_TRAMP_PROGS] = { 0 }; ^ .../prog_tests/trampoline_count.c:49:9: warning: (near initialization for ‘inst[0]’) [-Wmissing-braces] Fixes: d633d57902a5 (""selftest/bpf: Add test for allowed trampolines count"") Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200202065152.2718142-1-andriin@fb.com","tools/testing/selftests/bpf/prog_tests/trampoline_count.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","Fixes a compilation warning in the BPF selftest trampoline_count.c by adding missing braces.","compilation,warning,braces","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"257af63d7f84f0672aa6a24b5511871f00741f19","257af63d7f84f0672aa6a24b5511871f00741f19","Alexei Starovoitov","ast@kernel.org","1580515394","Daniel Borkmann","daniel@iogearbox.net","1580771167","2f7453642cf117d0550a4af58b15a1ae312d1139","a525b0881de7742617343f02df4073ddc1571237","bpf: Fix modifier skipping logic Fix the way modifiers are skipped while walking pointers. Otherwise second level dereferences of 'const struct foo *' will be rejected by the verifier. Fixes: 9e15db66136a (""bpf: Implement accurate raw_tp context access via BTF"") Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200201000314.261392-1-ast@kernel.org","kernel/bpf/btf.c | 8 +++-----; 1 file changed, 3 insertions(+), 5 deletions(-)","Fixes the modifier skipping logic in eBPF verifier to prevent rejection of second level dereferences.","modifier, verifier, dereferences","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"a525b0881de7742617343f02df4073ddc1571237","a525b0881de7742617343f02df4073ddc1571237","Michal Rostecki","mrostecki@opensuse.org","1580641320","Daniel Borkmann","daniel@iogearbox.net","1580771046","933f5d0d214013e3225f81a54e940d919b002ff2","2577e373bbc07f18680287b3958d3b2fdebe4b20","bpftool: Remove redundant ""HAVE"" prefix from the large INSN limit check ""HAVE"" prefix is already applied by default to feature macros and before this change, the large INSN limit macro had the incorrect name with double ""HAVE"". Fixes: 2faef64aa6b3 (""bpftool: Add misc section and probe for large INSN limit"") Signed-off-by: Michal Rostecki Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200202110200.31024-1-mrostecki@opensuse.org","tools/bpf/bpftool/feature.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","Removed redundant ""HAVE"" prefix from the bpftool's large INSN limit macro to correct naming.","bpftool,macro,INSN","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear.""]" +"43e76cd368fbb67e767da5363ffeaa3989993c8c","43e76cd368fbb67e767da5363ffeaa3989993c8c","Alexandre Ghiti","alex@ghiti.fr","1579367015","Michael Ellerman","mpe@ellerman.id.au","1580462242","b85c1f6ceae4d13b95a36f061cf725b67f70dbd3","41196224883a64e56e0ef237c19eb837058df071","powerpc: Do not consider weak unresolved symbol relocations as bad Commit 8580ac9404f6 (""bpf: Process in-kernel BTF"") introduced two weak symbols that may be unresolved at link time which result in an absolute relocation to 0. relocs_check.sh emits the following warning: ""WARNING: 2 bad relocations c000000001a41478 R_PPC64_ADDR64 _binary__btf_vmlinux_bin_start c000000001a41480 R_PPC64_ADDR64 _binary__btf_vmlinux_bin_end"" whereas those relocations are legitimate even for a relocatable kernel compiled with -pie option. relocs_check.sh already excluded some weak unresolved symbols explicitly: remove those hardcoded symbols and add some logic that parses the symbols using nm, retrieves all the weak unresolved symbols and excludes those from the list of the potential bad relocations. Reported-by: Stephen Rothwell Signed-off-by: Alexandre Ghiti Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200118170335.21440-1-alex@ghiti.fr","arch/powerpc/Makefile.postlink | 4 ++--; arch/powerpc/tools/relocs_check.sh | 20 ++++++++++++--------; 2 files changed, 14 insertions(+), 10 deletions(-)","The commit fixes handling of weak unresolved symbol relocations for PowerPC architecture during build.","weak symbols, relocations, PowerPC","A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.","It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.","[""It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.""]" +"2577e373bbc07f18680287b3958d3b2fdebe4b20","2577e373bbc07f18680287b3958d3b2fdebe4b20","Yulia Kartseva","hex@fb.com","1580425990","Alexei Starovoitov","ast@kernel.org","1580429987","48a10d37021cb4641f66e7e8af8e90a99c39a3e3","d3e42bb0a329fadff98fcb927714d0a486840e3b","runqslower: Fix Makefile Fix undefined reference linker errors when building runqslower with gcc 7.4.0 on Ubuntu 18.04. The issue is with misplaced -lelf, -lz options in Makefile: $(Q)$(CC) $(CFLAGS) -lelf -lz $^ -o $@ -lelf, -lz options should follow the list of target dependencies: $(Q)$(CC) $(CFLAGS) $^ -lelf -lz -o $@ or after substitution cc -g -Wall runqslower.o libbpf.a -lelf -lz -o runqslower The current order of gcc params causes failure in libelf symbols resolution, e.g. undefined reference to `elf_memory' Fixes: 9c01546d26d2 (""tools/bpf: Add runqslower tool to tools/bpf"") Signed-off-by: Julia Kartseva Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/908498f794661c44dca54da9e09dc0c382df6fcb.1580425879.git.hex@fb.com","tools/bpf/runqslower/Makefile | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","This commit fixes linker errors in the runqslower tool's Makefile by correcting the library linking order.","Makefile,linker,runqslower","A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"d3e42bb0a329fadff98fcb927714d0a486840e3b","d3e42bb0a329fadff98fcb927714d0a486840e3b","Martin KaFai Lau","kafai@fb.com","1580147505","Daniel Borkmann","daniel@iogearbox.net","1580312454","4d98a7235279da2956f340bcdb08d78cb6bdb76f","44efc78d0e464ce70b45b165c005f8bedc17952e","bpf: Reuse log from btf_prase_vmlinux() in btf_struct_ops_init() Instead of using a locally defined ""struct bpf_verifier_log log = {}"", btf_struct_ops_init() should reuse the ""log"" from its calling function ""btf_parse_vmlinux()"". It should also resolve the frame-size too large compiler warning in some ARCH. Fixes: 27ae7997a661 (""bpf: Introduce BPF_PROG_TYPE_STRUCT_OPS"") Signed-off-by: Martin KaFai Lau Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Acked-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200127175145.1154438-1-kafai@fb.com","include/linux/bpf.h | 7 +++++--; kernel/bpf/bpf_struct_ops.c | 5 ++---; kernel/bpf/btf.c | 2 +-; 3 files changed, 8 insertions(+), 6 deletions(-)","Refactor btf_struct_ops_init() to reuse log from btf_parse_vmlinux() and resolve frame-size warning.","btf,log,refactor","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"9e0703a2650def6fffe91235a880bb6f37d9ad74","9e0703a2650def6fffe91235a880bb6f37d9ad74","David S. Miller","davem@davemloft.net","1580131900","David S. Miller","davem@davemloft.net","1580131900","0fdbc8cd4ce67c569c5ab55b19bab509eaa474ea","c312840cd79061af37158cb42590931cfa364c1b 82650dab9a5a2928c8d982cce5e3c687f14f8716","Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next Daniel Borkmann says: ==================== pull-request: bpf-next 2020-01-27 The following pull-request contains BPF updates for your *net-next* tree. We've added 20 non-merge commits during the last 5 day(s) which contain a total of 24 files changed, 433 insertions(+), 104 deletions(-). The main changes are: 1) Make BPF trampolines and dispatcher aware for the stack unwinder, from Jiri Olsa. 2) Improve handling of failed CO-RE relocations in libbpf, from Andrii Nakryiko. 3) Several fixes to BPF sockmap and reuseport selftests, from Lorenz Bauer. 4) Various cleanups in BPF devmap's XDP flush code, from John Fastabend. 5) Fix BPF flow dissector when used with port ranges, from Yoshiki Komachi. 6) Fix bpffs' map_seq_next callback to always inc position index, from Vasily Averin. 7) Allow overriding LLVM tooling for runqslower utility, from Andrey Ignatov. 8) Silence false-positive lockdep splats in devmap hash lookup, from Amol Grover. 9) Fix fentry/fexit selftests to initialize a variable before use, from John Sperbeck. ==================== Signed-off-by: David S. Miller ","","This commit merges multiple updates to the BPF subsystem, including improvements and fixes in trampolines, libbpf, sockmap, and other components.","merge,exports,bpf","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"82650dab9a5a2928c8d982cce5e3c687f14f8716","82650dab9a5a2928c8d982cce5e3c687f14f8716","Daniel Borkmann","daniel@iogearbox.net","1580120707","Daniel Borkmann","daniel@iogearbox.net","1580120712","d8a90788a7a29307fd509bbf2761f024b4a902f8","b23bfa5633b19bf1db87b36a76b2225c734f794c 265bb359061db6ef825dec3912f341a604966371","Merge branch 'bpf-flow-dissector-fix-port-ranges' Yoshiki Komachi says: ==================== When I tried a test based on the selftest program for BPF flow dissector (test_flow_dissector.sh), I observed unexpected result as below: $ tc filter add dev lo parent ffff: protocol ip pref 1337 flower ip_proto \ udp src_port 8-10 action drop $ tools/testing/selftests/bpf/test_flow_dissector -i 4 -f 9 -F inner.dest4: 127.0.0.1 inner.source4: 127.0.0.3 pkts: tx=10 rx=10 The last rx means the number of received packets. I expected rx=0 in this test (i.e., all received packets should have been dropped), but it resulted in acceptance. Although the previous commit 8ffb055beae5 (""cls_flower: Fix the behavior using port ranges with hw-offload"") added new flag and field toward filtering based on port ranges with hw-offload, it missed applying for BPF flow dissector then. As a result, BPF flow dissector currently stores data extracted from packets in incorrect field used for exact match whenever packets are classified by filters based on port ranges. Thus, they never match rules in such cases because flow dissector gives rise to generating incorrect flow keys. This series fixes the issue by replacing incorrect flag and field with new ones in BPF flow dissector, and adds a test for filtering based on specified port ranges to the existing selftest program. Changes in v2: - set key_ports to NULL at the top of __skb_flow_bpf_to_target() ==================== Signed-off-by: Daniel Borkmann ","","This commit fixes port range handling in the BPF flow dissector for accurate packet filtering and includes a self-test update.","flow dissector,port ranges,filtering","A bug fix. It primarily resolves a bug or issue in the code.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.']" +"265bb359061db6ef825dec3912f341a604966371","265bb359061db6ef825dec3912f341a604966371","Yoshiki Komachi","komachi.yoshiki@gmail.com","1579244733","Daniel Borkmann","daniel@iogearbox.net","1580120707","d8a90788a7a29307fd509bbf2761f024b4a902f8","59fb9b62fb6c929a756563152a89f39b07cf8893","selftests/bpf: Add test based on port range for BPF flow dissector Add a simple test to make sure that a filter based on specified port range classifies packets correctly. Signed-off-by: Yoshiki Komachi Signed-off-by: Daniel Borkmann Acked-by: Petar Penkov Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200117070533.402240-3-komachi.yoshiki@gmail.com","tools/testing/selftests/bpf/test_flow_dissector.sh | 14 ++++++++++++++; 1 file changed, 14 insertions(+)","Added a test for port range filtering in BPF flow dissector to ensure correct packet classification.","test,port,dissector","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"59fb9b62fb6c929a756563152a89f39b07cf8893","59fb9b62fb6c929a756563152a89f39b07cf8893","Yoshiki Komachi","komachi.yoshiki@gmail.com","1579244732","Daniel Borkmann","daniel@iogearbox.net","1580120707","9cf1d681e251da74f979b40423f6403d1c77211a","b23bfa5633b19bf1db87b36a76b2225c734f794c","flow_dissector: Fix to use new variables for port ranges in bpf hook This patch applies new flag (FLOW_DISSECTOR_KEY_PORTS_RANGE) and field (tp_range) to BPF flow dissector to generate appropriate flow keys when classified by specified port ranges. Fixes: 8ffb055beae5 (""cls_flower: Fix the behavior using port ranges with hw-offload"") Signed-off-by: Yoshiki Komachi Signed-off-by: Daniel Borkmann Acked-by: Petar Penkov Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200117070533.402240-2-komachi.yoshiki@gmail.com","net/core/flow_dissector.c | 11 +++++++++--; 1 file changed, 9 insertions(+), 2 deletions(-)","Fixes port range usage in BPF flow dissector with new flag and field.","flow,port,bpf","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Netfilter related type programs. It impacts programs interacting with the Netfilter framework used in packet filtering and NAT.', ""It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here."", ""I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear.""]" +"b23bfa5633b19bf1db87b36a76b2225c734f794c","b23bfa5633b19bf1db87b36a76b2225c734f794c","John Fastabend","john.fastabend@gmail.com","1580084042","Daniel Borkmann","daniel@iogearbox.net","1580120185","c742eddb17a226837c0e042c5b31540526893260","9719c6b98db42462bfb9aa172f017bdfd6d66c6f","bpf, xdp: Remove no longer required rcu_read_{un}lock() Now that we depend on rcu_call() and synchronize_rcu() to also wait for preempt_disabled region to complete the rcu read critical section in __dev_map_flush() is no longer required. Except in a few special cases in drivers that need it for other reasons. These originally ensured the map reference was safe while a map was also being free'd. And additionally that bpf program updates via ndo_bpf did not happen while flush updates were in flight. But flush by new rules can only be called from preempt-disabled NAPI context. The synchronize_rcu from the map free path and the rcu_call from the delete path will ensure the reference there is safe. So lets remove the rcu_read_lock and rcu_read_unlock pair to avoid any confusion around how this is being protected. If the rcu_read_lock was required it would mean errors in the above logic and the original patch would also be wrong. Now that we have done above we put the rcu_read_lock in the driver code where it is needed in a driver dependent way. I think this helps readability of the code so we know where and why we are taking read locks. Most drivers will not need rcu_read_locks here and further XDP drivers already have rcu_read_locks in their code paths for reading xdp programs on RX side so this makes it symmetric where we don't have half of rcu critical sections define in driver and the other half in devmap. Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Acked-by: Jesper Dangaard Brouer Link: https://lore.kernel.org/bpf/1580084042-11598-4-git-send-email-john.fastabend@gmail.com","drivers/net/veth.c | 6 +++++-; kernel/bpf/devmap.c | 5 +++--; 2 files changed, 8 insertions(+), 3 deletions(-)","This commit removes unnecessary rcu_read lock calls from devmap and veth driver to optimize logic and enhance code clarity for XDP operations.","rcu_read, devmap, xdp","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.']" +"9719c6b98db42462bfb9aa172f017bdfd6d66c6f","9719c6b98db42462bfb9aa172f017bdfd6d66c6f","John Fastabend","john.fastabend@gmail.com","1580084041","Daniel Borkmann","daniel@iogearbox.net","1580120185","a6f7a4cd60fb300d1261a7d00599a9de4b3ea64b","42a84a8cd0ff0cbff5a4595e1304c4567a30267d","bpf, xdp: virtio_net use access ptr macro for xdp enable check virtio_net currently relies on rcu critical section to access the xdp program in its xdp_xmit handler. However, the pointer to the xdp program is only used to do a NULL pointer comparison to determine if xdp is enabled or not. Use rcu_access_pointer() instead of rcu_dereference() to reflect this. Then later when we drop rcu_read critical section virtio_net will not need in special handling. Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Acked-by: Jesper Dangaard Brouer Link: https://lore.kernel.org/bpf/1580084042-11598-3-git-send-email-john.fastabend@gmail.com","drivers/net/virtio_net.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","The commit refactors the virtio_net driver to use rcu_access_pointer for checking XDP enablement to simplify RCU handling.","virtio_net,XDP,rcu_access_pointer","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.']" +"42a84a8cd0ff0cbff5a4595e1304c4567a30267d","42a84a8cd0ff0cbff5a4595e1304c4567a30267d","John Fastabend","john.fastabend@gmail.com","1580084040","Daniel Borkmann","daniel@iogearbox.net","1580120180","0cabe8753a6f84619ddce2340490ddd72120f3f8","90435a7891a2259b0f74c5a1bc5600d0d64cba8f","bpf, xdp: Update devmap comments to reflect napi/rcu usage Now that we rely on synchronize_rcu and call_rcu waiting to exit perempt-disable regions (NAPI) lets update the comments to reflect this. Fixes: 0536b85239b84 (""xdp: Simplify devmap cleanup"") Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Acked-by: Björn Töpel Acked-by: Song Liu Link: https://lore.kernel.org/bpf/1580084042-11598-2-git-send-email-john.fastabend@gmail.com","kernel/bpf/devmap.c | 21 +++++++++++----------; 1 file changed, 11 insertions(+), 10 deletions(-)","Update devmap comments to reflect RCU usage in NAPI context in eBPF XDP programs.","devmap,NAPI,RCU","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.']" +"0e6223ea903a892ba6962bdf823572e595dc8236","0e6223ea903a892ba6962bdf823572e595dc8236","David S. Miller","davem@davemloft.net","1580119542","David S. Miller","davem@davemloft.net","1580119542","30aa053fff7bd25d7d7c42ca91a2909e90013093","09917a126d5babd9d0d9bee8ee2c5fc8517851e6 02758cb6dac31a2b4bd9e535cffbe718acd46404","Merge branch 'XDP-fixes-for-socionext-driver' Lorenzo Bianconi says: ==================== XDP fixes for socionext driver Fix possible user-after-in XDP rx path Fix rx statistics accounting if no bpf program is attached ==================== Signed-off-by: David S. Miller ","","This commit merges XDP fixes for the Socionext driver addressing use-after-free and RX stats issues.","XDP,socionext,fixes","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.']" +"02758cb6dac31a2b4bd9e535cffbe718acd46404","02758cb6dac31a2b4bd9e535cffbe718acd46404","Lorenzo Bianconi","lorenzo@kernel.org","1579952931","David S. Miller","davem@davemloft.net","1580119542","30aa053fff7bd25d7d7c42ca91a2909e90013093","b5e82e3c89c78ee0407ea8e8087af5519b6c7bae","net: socionext: fix xdp_result initialization in netsec_process_rx Fix xdp_result initialization in netsec_process_rx in order to not increase rx counters if there is no bpf program attached to the xdp hook and napi_gro_receive returns GRO_DROP Fixes: ba2b232108d3c (""net: netsec: add XDP support"") Signed-off-by: Lorenzo Bianconi Acked-by: Jesper Dangaard Brouer Acked-by: Ilias Apalodimas Signed-off-by: David S. Miller ","drivers/net/ethernet/socionext/netsec.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","Fix xdp_result initialization in netsec_process_rx to prevent incrementing rx counters unnecessarily.","xdp_result, initialization, netsec_process_rx","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.']" +"b5e82e3c89c78ee0407ea8e8087af5519b6c7bae","b5e82e3c89c78ee0407ea8e8087af5519b6c7bae","Lorenzo Bianconi","lorenzo@kernel.org","1579952930","David S. Miller","davem@davemloft.net","1580119542","fbcfaedd310ff8e968efbe410492f7b6df0e18e6","09917a126d5babd9d0d9bee8ee2c5fc8517851e6","net: socionext: fix possible user-after-free in netsec_process_rx Fix possible use-after-free in in netsec_process_rx that can occurs if the first packet is sent to the normal networking stack and the following one is dropped by the bpf program attached to the xdp hook. Fix the issue defining the skb pointer in the 'budget' loop Fixes: ba2b232108d3c (""net: netsec: add XDP support"") Signed-off-by: Lorenzo Bianconi Acked-by: Jesper Dangaard Brouer Acked-by: Ilias Apalodimas Signed-off-by: David S. Miller ","drivers/net/ethernet/socionext/netsec.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","The commit fixes a use-after-free bug in the netsec driver when dropped packets in XDP code path affect skb handling.","use-after-free,XDP,netsec","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.']" +"90435a7891a2259b0f74c5a1bc5600d0d64cba8f","90435a7891a2259b0f74c5a1bc5600d0d64cba8f","Vasily Averin","vvs@virtuozzo.com","1579943402","Daniel Borkmann","daniel@iogearbox.net","1580118872","dcaf37c1d2dd0a92827364fd29a3c1f783fe7ba0","07fdbee134b3530ef30c709aa4251ca04ea9e3f8","bpf: map_seq_next should always increase position index If seq_file .next fuction does not change position index, read after some lseek can generate an unexpected output. See also: https://bugzilla.kernel.org/show_bug.cgi?id=206283 v1 -> v2: removed missed increment in end of function Signed-off-by: Vasily Averin Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/eca84fdd-c374-a154-d874-6c7b55fc3bc4@virtuozzo.com","kernel/bpf/inode.c | 3 +--; 1 file changed, 1 insertion(+), 2 deletions(-)","The commit fixes position index update in the map_seq_next function to ensure correct output after seeking in eBPF maps.","position,index,seq_file","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"07fdbee134b3530ef30c709aa4251ca04ea9e3f8","07fdbee134b3530ef30c709aa4251ca04ea9e3f8","Andrey Ignatov","rdna@fb.com","1579905702","Daniel Borkmann","daniel@iogearbox.net","1580118777","916a0f355e2cf848348e76e8dc118c92e3139c28","e9f02a8027675e3957d463d7f8422d79fa90f2ba","tools/bpf: Allow overriding llvm tools for runqslower tools/testing/selftests/bpf/Makefile supports overriding clang, llc and other tools so that custom ones can be used instead of those from PATH. It's convinient and heavily used by some users. Apply same rules to runqslower/Makefile. Signed-off-by: Andrey Ignatov Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200124224142.1833678-1-rdna@fb.com","tools/bpf/runqslower/Makefile | 6 +++---; 1 file changed, 3 insertions(+), 3 deletions(-)","The commit allows llvm tools to be overridden in the runqslower Makefile for flexibility, aligning with the selftests/bpf Makefile.","llvm, overriding, Makefile","A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"e9f02a8027675e3957d463d7f8422d79fa90f2ba","e9f02a8027675e3957d463d7f8422d79fa90f2ba","Alexei Starovoitov","ast@kernel.org","1579965161","Alexei Starovoitov","ast@kernel.org","1579965166","79f53b2c1eeaef4807494ba3de30fb2192ff3edc","35b9211c0a2427e8f39e534f442f43804fc8d5ca d633d57902a510debd4ec5b7a374a009c8c2d620","Merge branch 'trampoline-fixes' Jiri Olsa says: ==================== hi, sending 2 fixes to fix kernel support for loading trampoline programs in bcc/bpftrace and allow to unwind through trampoline/dispatcher. Original rfc post [1]. Speedup output of perf bench while running klockstat.py on kprobes vs trampolines: Without: $ perf bench sched messaging -l 50000 ... Total time: 18.571 [sec] With current kprobe tracing: $ perf bench sched messaging -l 50000 ... Total time: 183.395 [sec] With kfunc tracing: $ perf bench sched messaging -l 50000 ... Total time: 39.773 [sec] v4 changes: - rebased on latest bpf-next/master - removed image tree mutex and use trampoline_mutex instead - checking directly for string pointer in patch 1 [Alexei] - skipped helpers patches, as they are no longer needed [Alexei] v3 changes: - added ack from John Fastabend for patch 1 - move out is_bpf_image_address from is_bpf_text_address call [David] v2 changes: - make the unwind work for dispatcher as well - added test for allowed trampolines count - used raw tp pt_regs nest-arrays for trampoline helpers thanks, jirka [1] https://lore.kernel.org/netdev/20191229143740.29143-1-jolsa@kernel.org/ ==================== Signed-off-by: Alexei Starovoitov ","","The commit merges 'trampoline-fixes' branch to improve kernel support for loading trampoline programs and allow unwinding through trampoline and dispatcher.","trampoline, fixes, kernel","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","['kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.', ""It's likely a merge commit. It involves changes across multiple use cases or events."", ""I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear.""]" +"d633d57902a510debd4ec5b7a374a009c8c2d620","d633d57902a510debd4ec5b7a374a009c8c2d620","Jiri Olsa","jolsa@kernel.org","1579796108","Alexei Starovoitov","ast@kernel.org","1579965160","79f53b2c1eeaef4807494ba3de30fb2192ff3edc","e9b4e606c2289d6610113253922bb8c9ac7f68b0","selftest/bpf: Add test for allowed trampolines count There's limit of 40 programs tht can be attached to trampoline for one function. Adding test that tries to attach that many plus one extra that needs to fail. Signed-off-by: Jiri Olsa Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200123161508.915203-4-jolsa@kernel.org",".../selftests/bpf/prog_tests/trampoline_count.c | 112 +++++++++++++++++++++; .../selftests/bpf/progs/test_trampoline_count.c | 21 ++++; 2 files changed, 133 insertions(+)","This commit adds a self-test for the limit on trampoline counts in eBPF programs.","selftest, trampolines, limit","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"e9b4e606c2289d6610113253922bb8c9ac7f68b0","e9b4e606c2289d6610113253922bb8c9ac7f68b0","Jiri Olsa","jolsa@kernel.org","1579796107","Alexei Starovoitov","ast@kernel.org","1579965160","93b15ceadb74925c45742b98e876fe573f5bd74a","84ad7a7ab69f112c0c4b878c9be91b950a1fb1f8","bpf: Allow to resolve bpf trampoline and dispatcher in unwind When unwinding the stack we need to identify each address to successfully continue. Adding latch tree to keep trampolines for quick lookup during the unwind. The patch uses first 48 bytes for latch tree node, leaving 4048 bytes from the rest of the page for trampoline or dispatcher generated code. It's still enough not to affect trampoline and dispatcher progs maximum counts. Signed-off-by: Jiri Olsa Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200123161508.915203-3-jolsa@kernel.org","include/linux/bpf.h | 12 +++++++-; kernel/bpf/dispatcher.c | 4 +--; kernel/bpf/trampoline.c | 80 ++++++++++++++++++++++++++++++++++++++++++++-----; kernel/extable.c | 7 +++--; 4 files changed, 90 insertions(+), 13 deletions(-)","Adds latch tree for quick lookup of bpf trampoline during stack unwinding.","trampoline,dispatcher,unwind","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"84ad7a7ab69f112c0c4b878c9be91b950a1fb1f8","84ad7a7ab69f112c0c4b878c9be91b950a1fb1f8","Jiri Olsa","jolsa@kernel.org","1579796106","Alexei Starovoitov","ast@kernel.org","1579965160","eb5de4f71b8c7f558e487755fe753f99cbe2f205","35b9211c0a2427e8f39e534f442f43804fc8d5ca","bpf: Allow BTF ctx access for string pointers When accessing the context we allow access to arguments with scalar type and pointer to struct. But we deny access for pointer to scalar type, which is the case for many functions. Alexei suggested to take conservative approach and allow currently only string pointer access, which is the case for most functions now: Adding check if the pointer is to string type and allow access to it. Suggested-by: Alexei Starovoitov Signed-off-by: Jiri Olsa Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200123161508.915203-2-jolsa@kernel.org","kernel/bpf/btf.c | 16 ++++++++++++++++; 1 file changed, 16 insertions(+)","The commit allows BTF context access for string pointers in eBPF programs by implementing a type check.","BTF,string,pointers","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.","BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"35b9211c0a2427e8f39e534f442f43804fc8d5ca","35b9211c0a2427e8f39e534f442f43804fc8d5ca","Andrii Nakryiko","andriin@fb.com","1579897126","Daniel Borkmann","daniel@iogearbox.net","1579901677","447a49a6541913091f7183f618de47e83c0c20f2","d7a252708dbc950ca2064310217e8b9f85846e2f","libbpf: Fix realloc usage in bpf_core_find_cands Fix bug requesting invalid size of reallocated array when constructing CO-RE relocation candidate list. This can cause problems if there are many potential candidates and a very fine-grained memory allocator bucket sizes are used. Fixes: ddc7c3042614 (""libbpf: implement BPF CO-RE offset relocation algorithm"") Reported-by: William Smith Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200124201847.212528-1-andriin@fb.com","tools/lib/bpf/libbpf.c | 4 +++-; 1 file changed, 3 insertions(+), 1 deletion(-)","The commit fixes a bug in libbpf related to reallocating array sizes for CO-RE relocation candidates.","libbpf,bug,CO-RE","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"d7a252708dbc950ca2064310217e8b9f85846e2f","d7a252708dbc950ca2064310217e8b9f85846e2f","Andrii Nakryiko","andriin@fb.com","1579844317","Daniel Borkmann","daniel@iogearbox.net","1579900586","22fc01fa40da05e5cb32a633298e6eef1bfac0ef","51bad0f05616c43d6d34b0a19bcc9bdab8e8fb39","libbpf: Improve handling of failed CO-RE relocations Previously, if libbpf failed to resolve CO-RE relocation for some instructions, it would either return error immediately, or, if .relaxed_core_relocs option was set, would replace relocatable offset/imm part of an instruction with a bogus value (-1). Neither approach is good, because there are many possible scenarios where relocation is expected to fail (e.g., when some field knowingly can be missing on specific kernel versions). On the other hand, replacing offset with invalid one can hide programmer errors, if this relocation failue wasn't anticipated. This patch deprecates .relaxed_core_relocs option and changes the approach to always replacing instruction, for which relocation failed, with invalid BPF helper call instruction. For cases where this is expected, BPF program should already ensure that that instruction is unreachable, in which case this invalid instruction is going to be silently ignored. But if instruction wasn't guarded, BPF program will be rejected at verification step with verifier log pointing precisely to the place in assembly where the problem is. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200124053837.2434679-1-andriin@fb.com","tools/lib/bpf/libbpf.c | 95 +++++++++++++++++++++++++++++---------------------; tools/lib/bpf/libbpf.h | 6 +++-; 2 files changed, 61 insertions(+), 40 deletions(-)","The commit enhances libbpf by improving the error handling of failed CO-RE relocations using invalid BPF helper call instructions.","libbpf, CO-RE, relocations","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"51bad0f05616c43d6d34b0a19bcc9bdab8e8fb39","51bad0f05616c43d6d34b0a19bcc9bdab8e8fb39","Lorenz Bauer","lmb@cloudflare.com","1579865274","Daniel Borkmann","daniel@iogearbox.net","1579900333","842e3282420e8bdcb46247af55e02259c9fc7f02","603fba9dfd0b2e2a844ece9ed98ce874c38aa98e","selftests: bpf: Reset global state between reuseport test runs Currently, there is a lot of false positives if a single reuseport test fails. This is because expected_results and the result map are not cleared. Zero both after individual test runs, which fixes the mentioned false positives. Fixes: 91134d849a0e (""bpf: Test BPF_PROG_TYPE_SK_REUSEPORT"") Signed-off-by: Lorenz Bauer Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Sitnicki Acked-by: Martin KaFai Lau Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200124112754.19664-5-lmb@cloudflare.com",".../testing/selftests/bpf/prog_tests/select_reuseport.c | 16 ++++++++++++++--; 1 file changed, 14 insertions(+), 2 deletions(-)","Reset global state between reuseport test runs to prevent false positives in BPF selftests.","selftests,bpf,reuseport","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"603fba9dfd0b2e2a844ece9ed98ce874c38aa98e","603fba9dfd0b2e2a844ece9ed98ce874c38aa98e","Lorenz Bauer","lmb@cloudflare.com","1579865273","Daniel Borkmann","daniel@iogearbox.net","1579900333","c229d70bfa87159a5e75b95e3530215ff643a4a8","8bec4f665e0baecb5f1b683379fc10b3745eb612","selftests: bpf: Make reuseport test output more legible Include the name of the mismatching result in human readable format when reporting an error. The new output looks like the following: unexpected result result: [1, 0, 0, 0, 0, 0] expected: [0, 0, 0, 0, 0, 0] mismatch on DROP_ERR_INNER_MAP (bpf_prog_linum:153) check_results:FAIL:382 Signed-off-by: Lorenz Bauer Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Sitnicki Acked-by: Martin KaFai Lau Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200124112754.19664-4-lmb@cloudflare.com",".../selftests/bpf/prog_tests/select_reuseport.c | 28 ++++++++++++++++++----; 1 file changed, 24 insertions(+), 4 deletions(-)","This commit enhances the readability of error messages in the reuseport bpf selftest output.","selftests bpf reuseport","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"8bec4f665e0baecb5f1b683379fc10b3745eb612","8bec4f665e0baecb5f1b683379fc10b3745eb612","Lorenz Bauer","lmb@cloudflare.com","1579865272","Daniel Borkmann","daniel@iogearbox.net","1579900333","57325f0764a0775c16adcce31fc4a375842a2a8d","c31dbb1e41d1857b403f9bf58c87f5898519a0bc","selftests: bpf: Ignore FIN packets for reuseport tests The reuseport tests currently suffer from a race condition: FIN packets count towards DROP_ERR_SKB_DATA, since they don't contain a valid struct cmd. Tests will spuriously fail depending on whether check_results is called before or after the FIN is processed. Exit the BPF program early if FIN is set. Fixes: 91134d849a0e (""bpf: Test BPF_PROG_TYPE_SK_REUSEPORT"") Signed-off-by: Lorenz Bauer Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Sitnicki Acked-by: Martin KaFai Lau Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200124112754.19664-3-lmb@cloudflare.com","tools/testing/selftests/bpf/progs/test_select_reuseport_kern.c | 6 ++++++; 1 file changed, 6 insertions(+)","The commit fixes a race condition in reuseport tests by ignoring FIN packets.","selftests, bpf, reuseport","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"c31dbb1e41d1857b403f9bf58c87f5898519a0bc","c31dbb1e41d1857b403f9bf58c87f5898519a0bc","Lorenz Bauer","lmb@cloudflare.com","1579865271","Daniel Borkmann","daniel@iogearbox.net","1579900333","3f909bf3b6b0b4e7e649eb8306d6c50cad9125e0","41258289a8e9e3e110bab316e0aeded25fa8beb6","selftests: bpf: Use a temporary file in test_sockmap Use a proper temporary file for sendpage tests. This means that running the tests doesn't clutter the working directory, and allows running the test on read-only filesystems. Fixes: 16962b2404ac (""bpf: sockmap, add selftests"") Signed-off-by: Lorenz Bauer Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Sitnicki Acked-by: Martin KaFai Lau Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200124112754.19664-2-lmb@cloudflare.com","tools/testing/selftests/bpf/test_sockmap.c | 15 +++++----------; 1 file changed, 5 insertions(+), 10 deletions(-)","This commit modifies BPF test_sockmap to use a temporary file for sendpage tests, enhancing filesystem compatibility.","selftests,temporary,sockmap","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"41258289a8e9e3e110bab316e0aeded25fa8beb6","41258289a8e9e3e110bab316e0aeded25fa8beb6","Andrii Nakryiko","andriin@fb.com","1579844597","Daniel Borkmann","daniel@iogearbox.net","1579860596","aaadf366d97d3784f1f3db76f0f20a3b5c6bcce2","03506297d205e5fa25b5ead0f6338b5a4a996a93","bpftool: Print function linkage in BTF dump Add printing out BTF_KIND_FUNC's linkage. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/20200124054317.2459436-1-andriin@fb.com","tools/bpf/bpftool/btf.c | 27 +++++++++++++++++++++++----; 1 file changed, 23 insertions(+), 4 deletions(-)","The commit enhances bpftool by adding the capability to print function linkage in BTF dumps.","bpftool,BTF,function","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"03506297d205e5fa25b5ead0f6338b5a4a996a93","03506297d205e5fa25b5ead0f6338b5a4a996a93","Andrii Nakryiko","andriin@fb.com","1579844508","Daniel Borkmann","daniel@iogearbox.net","1579860561","6e046594cf57e776c68bd63173b0e790bc2bb9dc","1a6fa10640d97e16d4184fa1c24aa8c3337d4653","selftests/bpf: Improve bpftool changes detection Detect when bpftool source code changes and trigger rebuild within selftests/bpf Makefile. Also fix few small formatting problems. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/20200124054148.2455060-1-andriin@fb.com","tools/testing/selftests/bpf/Makefile | 11 ++++++-----; 1 file changed, 6 insertions(+), 5 deletions(-)","The commit improves change detection in bpftool and fixes formatting issues within the selftest Makefile.","bpftool,Makefile,selftests","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"1a6fa10640d97e16d4184fa1c24aa8c3337d4653","1a6fa10640d97e16d4184fa1c24aa8c3337d4653","John Sperbeck","jsperbeck@google.com","1579823504","Daniel Borkmann","daniel@iogearbox.net","1579860345","9a6a529318593609da6c1269a58f983fd513d915","485ec2ea9cf556e9c120e07961b7b459d776a115","selftests/bpf: Initialize duration variable before using The 'duration' variable is referenced in the CHECK() macro, and there are some uses of the macro before 'duration' is set. The clang compiler (validly) complains about this. Sample error: .../selftests/bpf/prog_tests/fexit_test.c:23:6: warning: variable 'duration' is uninitialized when used here [-Wuninitialized] if (CHECK(err, ""prog_load sched cls"", ""err %d errno %d\n"", err, errno)) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .../selftests/bpf/test_progs.h:134:25: note: expanded from macro 'CHECK' if (CHECK(err, ""prog_load sched cls"", ""err %d errno %d\n"", err, errno)) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _CHECK(condition, tag, duration, format) ^~~~~~~~ Signed-off-by: John Sperbeck Signed-off-by: Stanislav Fomichev Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200123235144.93610-1-sdf@google.com","tools/testing/selftests/bpf/prog_tests/fentry_test.c | 2 +-; tools/testing/selftests/bpf/prog_tests/fexit_bpf2bpf.c | 2 +-; tools/testing/selftests/bpf/prog_tests/fexit_test.c | 2 +-; 3 files changed, 3 insertions(+), 3 deletions(-)","The commit initializes the 'duration' variable to address compiler warnings in eBPF selftest files.","selftests,initialize,duration","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"485ec2ea9cf556e9c120e07961b7b459d776a115","485ec2ea9cf556e9c120e07961b7b459d776a115","Amol Grover","frextrite@gmail.com","1579781078","Daniel Borkmann","daniel@iogearbox.net","1579816876","7170cfb46a0798200b85e08e1116b368f82820ba","fd786fb1d2cad70b9aaba8c73872cbf63262bd58","bpf, devmap: Pass lockdep expression to RCU lists head is traversed using hlist_for_each_entry_rcu outside an RCU read-side critical section but under the protection of dtab->index_lock. Hence, add corresponding lockdep expression to silence false-positive lockdep warnings, and harden RCU lists. Fixes: 6f9d451ab1a3 (""xdp: Add devmap_hash map type for looking up devices by hashed index"") Signed-off-by: Amol Grover Signed-off-by: Daniel Borkmann Acked-by: Jesper Dangaard Brouer Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/20200123120437.26506-1-frextrite@gmail.com","kernel/bpf/devmap.c | 3 ++-; 1 file changed, 2 insertions(+), 1 deletion(-)","The commit silences false-positive lockdep warnings by adding lockdep expressions to RCU lists in devmap.","RCU,lockdep,devmap","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.']" +"954b3c4397792c8614aa4aaf25030ae87ece8307","954b3c4397792c8614aa4aaf25030ae87ece8307","David S. Miller","davem@davemloft.net","1579763416","David S. Miller","davem@davemloft.net","1579763416","b2648c3d97fe2332863d7baac069c23cab0addc4","c5d19a6ecfce72d0352191d75f03eea4748a8c45 85cc12f85138f2ce3edf24833edd2179690306db","Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next Alexei Starovoitov says: ==================== pull-request: bpf-next 2020-01-22 The following pull-request contains BPF updates for your *net-next* tree. We've added 92 non-merge commits during the last 16 day(s) which contain a total of 320 files changed, 7532 insertions(+), 1448 deletions(-). The main changes are: 1) function by function verification and program extensions from Alexei. 2) massive cleanup of selftests/bpf from Toke and Andrii. 3) batched bpf map operations from Brian and Yonghong. 4) tcp congestion control in bpf from Martin. 5) bulking for non-map xdp_redirect form Toke. 6) bpf_send_signal_thread helper from Yonghong. ==================== Signed-off-by: David S. Miller ","","This commit merges 92 changes improving verification map operations and TCP congestion control in the eBPF subsystem.","verification,cleanup,merges","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"85cc12f85138f2ce3edf24833edd2179690306db","85cc12f85138f2ce3edf24833edd2179690306db","Alexei Starovoitov","ast@kernel.org","1579739411","Alexei Starovoitov","ast@kernel.org","1579739415","0632f77c714898a1ae96619361d986f706979535","1b2fd38de9fcc73d6994f8f6c7c23ee3435b6a12 6de4a9c430b57c6ebbccd2a1725f42e9be75f592","Merge branch 'bpf_cubic' Martin KaFai Lau says: ==================== This set adds bpf_cubic.c example. It was separated from the earlier BPF STRUCT_OPS series. Some highlights since the last post: 1. It is based on EricD recent fixes to the kernel tcp_cubic. [1] 2. The bpf jiffies reading helper is inlined by the verifier. Different from the earlier version, it only reads jiffies alone and does not do usecs/jiffies conversion. 3. The bpf .kconfig map is used to read CONFIG_HZ. [1]: https://patchwork.ozlabs.org/cover/1215066/ v3: - Remove __weak from CONFIG_HZ in patch 3. (Andrii) v2: - Move inlining to fixup_bpf_calls() in patch 1. (Daniel) - It is inlined for 64 BITS_PER_LONG and jit_requested as the map_gen_lookup(). Other cases could be considered together with map_gen_lookup() if needed. - Use usec resolution in bictcp_update() calculation in patch 3. usecs_to_jiffies() is then removed(). (Eric) ==================== Signed-off-by: Alexei Starovoitov ","","The commit merges the bpf_cubic example from a separate development branch, incorporating kernel tcp cubic improvements and inlining jiffies reading.","bpf_cubic,merge,jiffies","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","['Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime."", ""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"6de4a9c430b57c6ebbccd2a1725f42e9be75f592","6de4a9c430b57c6ebbccd2a1725f42e9be75f592","Martin KaFai Lau","kafai@fb.com","1579736218","Alexei Starovoitov","ast@kernel.org","1579739410","0632f77c714898a1ae96619361d986f706979535","0a49c1a8e26266ad505704f54f9fdaf2ae14cbdb","bpf: tcp: Add bpf_cubic example This patch adds a bpf_cubic example. Some highlights: 1. CONFIG_HZ .kconfig map is used. 2. In bictcp_update(), calculation is changed to use usec resolution (i.e. USEC_PER_JIFFY) instead of using jiffies. Thus, usecs_to_jiffies() is not used in the bpf_cubic.c. 3. In bitctcp_update() [under tcp_friendliness], the original ""while (ca->ack_cnt > delta)"" loop is changed to the equivalent ""ca->ack_cnt / delta"" operation. Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200122233658.903774-1-kafai@fb.com","tools/testing/selftests/bpf/bpf_tcp_helpers.h | 16 +; .../testing/selftests/bpf/prog_tests/bpf_tcp_ca.c | 25 +; tools/testing/selftests/bpf/progs/bpf_cubic.c | 544 +++++++++++++++++++++; 3 files changed, 585 insertions(+)","The commit adds a bpf_cubic example for TCP congestion control with improved time resolution calculations.","bpf_cubic,tcp,example","A new feature. It adds a new capability or feature that was not previously present.","Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['tc related type programs. It affects programs managing traffic control (tc) for queuing or prioritizing network traffic.']" +"0a49c1a8e26266ad505704f54f9fdaf2ae14cbdb","0a49c1a8e26266ad505704f54f9fdaf2ae14cbdb","Martin KaFai Lau","kafai@fb.com","1579736212","Alexei Starovoitov","ast@kernel.org","1579739410","d151c371bd68e4caac2dc4ab21a04492b58b6856","5576b991e9c1a11d2cc21c4b94fc75ec27603896","bpf: Sync uapi bpf.h to tools/ This patch sync uapi bpf.h to tools/. Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200122233652.903348-1-kafai@fb.com","tools/include/uapi/linux/bpf.h | 9 ++++++++-; 1 file changed, 8 insertions(+), 1 deletion(-)","The commit synchronizes the uapi bpf.h file to the tools directory with minor changes.","sync,uapi,bpf.h","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.","It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"5576b991e9c1a11d2cc21c4b94fc75ec27603896","5576b991e9c1a11d2cc21c4b94fc75ec27603896","Martin KaFai Lau","kafai@fb.com","1579736206","Alexei Starovoitov","ast@kernel.org","1579739410","6254c1eec41a9c3e2108eb955920573d61f8c19b","1b2fd38de9fcc73d6994f8f6c7c23ee3435b6a12","bpf: Add BPF_FUNC_jiffies64 This patch adds a helper to read the 64bit jiffies. It will be used in a later patch to implement the bpf_cubic.c. The helper is inlined for jit_requested and 64 BITS_PER_LONG as the map_gen_lookup(). Other cases could be considered together with map_gen_lookup() if needed. Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200122233646.903260-1-kafai@fb.com","include/linux/bpf.h | 1 +; include/uapi/linux/bpf.h | 9 ++++++++-; kernel/bpf/core.c | 1 +; kernel/bpf/helpers.c | 12 ++++++++++++; kernel/bpf/verifier.c | 24 ++++++++++++++++++++++++; net/core/filter.c | 2 ++; 6 files changed, 48 insertions(+), 1 deletion(-)","This commit introduces a helper function to read 64-bit jiffies in eBPF for future use in bpf_cubic.c.","helper,jiffies64,eBPF","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"1b2fd38de9fcc73d6994f8f6c7c23ee3435b6a12","1b2fd38de9fcc73d6994f8f6c7c23ee3435b6a12","Daniel Borkmann","daniel@iogearbox.net","1579730693","Daniel Borkmann","daniel@iogearbox.net","1579730708","99bc088a4cd4e27b6c5befcbae2ade0ea72a7f1d","2a67a6ccb01f21b854715d86ff6432a18b97adb3 7805fe843964f81f98592bf580b9cd736ac4ad4c","Merge branch 'bpf-dynamic-relinking' Alexei Starovoitov says: ==================== The last few month BPF community has been discussing an approach to call chaining, since exiting bpt_tail_call() mechanism used in production XDP programs has plenty of downsides. The outcome of these discussion was a conclusion to implement dynamic re-linking of BPF programs. Where rootlet XDP program attached to a netdevice can programmatically define a policy of execution of other XDP programs. Such rootlet would be compiled as normal XDP program and provide a number of placeholder global functions which later can be replaced with future XDP programs. BPF trampoline, function by function verification were building blocks towards that goal. The patch 1 is a final building block. It introduces dynamic program extensions. A number of improvements like more flexible function by function verification and better libbpf api will be implemented in future patches. v1->v2: - addressed Andrii's comments - rebase ==================== Signed-off-by: Daniel Borkmann ","","This commit merges the 'bpf-dynamic-relinking' branch, introducing dynamic program extensions for call chaining in XDP programs.","dynamic,re-linking,XDP","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.']" +"7805fe843964f81f98592bf580b9cd736ac4ad4c","7805fe843964f81f98592bf580b9cd736ac4ad4c","Alexei Starovoitov","ast@kernel.org","1579568028","Daniel Borkmann","daniel@iogearbox.net","1579730693","99bc088a4cd4e27b6c5befcbae2ade0ea72a7f1d","2db6eab18b9778d55f48c804f8efebd7097e7958","selftests/bpf: Add tests for program extensions Add program extension tests that build on top of fexit_bpf2bpf tests. Replace three global functions in previously loaded test_pkt_access.c program with three new implementations: int get_skb_len(struct __sk_buff *skb); int get_constant(long val); int get_skb_ifindex(int val, struct __sk_buff *skb, int var); New function return the same results as original only if arguments match. new_get_skb_ifindex() demonstrates that 'skb' argument doesn't have to be first and only argument of BPF program. All normal skb based accesses are available. Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Acked-by: Andrii Nakryiko Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/20200121005348.2769920-4-ast@kernel.org",".../selftests/bpf/prog_tests/fexit_bpf2bpf.c | 20 +++++++-; tools/testing/selftests/bpf/progs/fexit_bpf2bpf.c | 57 ++++++++++++++++++++++; .../testing/selftests/bpf/progs/test_pkt_access.c | 8 ++-; 3 files changed, 83 insertions(+), 2 deletions(-)","The commit adds new program extension tests to the eBPF selftests to evaluate function argument compatibility in BPF programs.","selftests,program,extension","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"2db6eab18b9778d55f48c804f8efebd7097e7958","2db6eab18b9778d55f48c804f8efebd7097e7958","Alexei Starovoitov","ast@kernel.org","1579568027","Daniel Borkmann","daniel@iogearbox.net","1579730693","ad350f22004bb7f7ba18e81277e58bb64d2480f0","be8704ff07d2374bcc5c675526f95e70c6459683","libbpf: Add support for program extensions Add minimal support for program extensions. bpf_object_open_opts() needs to be called with attach_prog_fd = target_prog_fd and BPF program extension needs to have in .c file section definition like SEC(""freplace/func_to_be_replaced""). libbpf will search for ""func_to_be_replaced"" in the target_prog_fd's BTF and will pass it in attach_btf_id to the kernel. This approach works for tests, but more compex use case may need to request function name (and attach_btf_id that kernel sees) to be more dynamic. Such API will be added in future patches. Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Acked-by: Andrii Nakryiko Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/20200121005348.2769920-3-ast@kernel.org","tools/include/uapi/linux/bpf.h | 1 +; tools/lib/bpf/bpf.c | 3 ++-; tools/lib/bpf/libbpf.c | 13 ++++++++++---; tools/lib/bpf/libbpf.h | 2 ++; tools/lib/bpf/libbpf.map | 2 ++; tools/lib/bpf/libbpf_probes.c | 1 +; 6 files changed, 18 insertions(+), 4 deletions(-)","This commit introduces initial support for BPF program extensions in the libbpf library.","libbpf,extensions,support","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"be8704ff07d2374bcc5c675526f95e70c6459683","be8704ff07d2374bcc5c675526f95e70c6459683","Alexei Starovoitov","ast@kernel.org","1579568026","Daniel Borkmann","daniel@iogearbox.net","1579730692","ba8111a7a61e4efa99f86febd3668c67d0692551","2a67a6ccb01f21b854715d86ff6432a18b97adb3","bpf: Introduce dynamic program extensions Introduce dynamic program extensions. The users can load additional BPF functions and replace global functions in previously loaded BPF programs while these programs are executing. Global functions are verified individually by the verifier based on their types only. Hence the global function in the new program which types match older function can safely replace that corresponding function. This new function/program is called 'an extension' of old program. At load time the verifier uses (attach_prog_fd, attach_btf_id) pair to identify the function to be replaced. The BPF program type is derived from the target program into extension program. Technically bpf_verifier_ops is copied from target program. The BPF_PROG_TYPE_EXT program type is a placeholder. It has empty verifier_ops. The extension program can call the same bpf helper functions as target program. Single BPF_PROG_TYPE_EXT type is used to extend XDP, SKB and all other program types. The verifier allows only one level of replacement. Meaning that the extension program cannot recursively extend an extension. That also means that the maximum stack size is increasing from 512 to 1024 bytes and maximum function nesting level from 8 to 16. The programs don't always consume that much. The stack usage is determined by the number of on-stack variables used by the program. The verifier could have enforced 512 limit for combined original plus extension program, but it makes for difficult user experience. The main use case for extensions is to provide generic mechanism to plug external programs into policy program or function call chaining. BPF trampoline is used to track both fentry/fexit and program extensions because both are using the same nop slot at the beginning of every BPF function. Attaching fentry/fexit to a function that was replaced is not allowed. The opposite is true as well. Replacing a function that currently being analyzed with fentry/fexit is not allowed. The executable page allocated by BPF trampoline is not used by program extensions. This inefficiency will be optimized in future patches. Function by function verification of global function supports scalars and pointer to context only. Hence program extensions are supported for such class of global functions only. In the future the verifier will be extended with support to pointers to structures, arrays with sizes, etc. Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Acked-by: Andrii Nakryiko Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/20200121005348.2769920-2-ast@kernel.org","include/linux/bpf.h | 10 ++-; include/linux/bpf_types.h | 2 +; include/linux/btf.h | 5 ++; include/uapi/linux/bpf.h | 1 +; kernel/bpf/btf.c | 152 +++++++++++++++++++++++++++++++++++++++++++++-; kernel/bpf/syscall.c | 15 ++++-; kernel/bpf/trampoline.c | 41 ++++++++++++-; kernel/bpf/verifier.c | 85 ++++++++++++++++++++------; 8 files changed, 283 insertions(+), 28 deletions(-)","Introduce dynamic extensions allowing BPF programs to load new functions and replace global functions in existing BPF programs while executing.","dynamic, extensions, BPF","A new feature. It adds a new capability or feature that was not previously present.","Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.","The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"58c8db929db1c1d785a6f5d8f8692e5dbcc35e84","58c8db929db1c1d785a6f5d8f8692e5dbcc35e84","Jakub Sitnicki","jakub@cloudflare.com","1579609907","David S. Miller","davem@davemloft.net","1579721420","555b6341eafcee8b16cb7d6a8f59701582085f50","d0f418516022c32ecceaf4275423e5bd3f8743a9","net, sk_msg: Don't check if sock is locked when tearing down psock As John Fastabend reports [0], psock state tear-down can happen on receive path *after* unlocking the socket, if the only other psock user, that is sockmap or sockhash, releases its psock reference before tcp_bpf_recvmsg does so: tcp_bpf_recvmsg() psock = sk_psock_get(sk) <- refcnt 2 lock_sock(sk); ... sock_map_free() <- refcnt 1 release_sock(sk) sk_psock_put() <- refcnt 0 Remove the lockdep check for socket lock in psock tear-down that got introduced in 7e81a3530206 (""bpf: Sockmap, ensure sock lock held during tear down""). [0] https://lore.kernel.org/netdev/5e25dc995d7d_74082aaee6e465b441@john-XPS-13-9370.notmuch/ Fixes: 7e81a3530206 (""bpf: Sockmap, ensure sock lock held during tear down"") Reported-by: syzbot+d73682fcf7fee6982fe3@syzkaller.appspotmail.com Suggested-by: John Fastabend Signed-off-by: Jakub Sitnicki Acked-by: John Fastabend Acked-by: Daniel Borkmann Signed-off-by: David S. Miller ","net/core/skmsg.c | 2 --; 1 file changed, 2 deletions(-)","Remove unnecessary socket lock check during psock teardown in sk_msg.","psock,lock,tcp_bpf_recvmsg","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"2a67a6ccb01f21b854715d86ff6432a18b97adb3","2a67a6ccb01f21b854715d86ff6432a18b97adb3","Chris Down","chris@chrisdown.name","1579651270","Daniel Borkmann","daniel@iogearbox.net","1579711948","a973e74380a9631256c6cc0e6a15af350856f56e","1222653cc0489fa9304a36f7d9593ecaeb51efe1","bpf, btf: Always output invariant hit in pahole DWARF to BTF transform When trying to compile with CONFIG_DEBUG_INFO_BTF enabled, I got this error: % make -s Failed to generate BTF for vmlinux Try to disable CONFIG_DEBUG_INFO_BTF make[3]: *** [vmlinux] Error 1 Compiling again without -s shows the true error (that pahole is missing), but since this is fatal, we should show the error unconditionally on stderr as well, not silence it using the `info` function. With this patch: % make -s BTF: .tmp_vmlinux.btf: pahole (pahole) is not available Failed to generate BTF for vmlinux Try to disable CONFIG_DEBUG_INFO_BTF make[3]: *** [vmlinux] Error 1 Signed-off-by: Chris Down Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200122000110.GA310073@chrisdown.name","scripts/link-vmlinux.sh | 4 ++--; 1 file changed, 2 insertions(+), 2 deletions(-)","This commit ensures the display of pahole errors during BTF generation for better debugging.","BTF, pahole, debugging","A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"1222653cc0489fa9304a36f7d9593ecaeb51efe1","1222653cc0489fa9304a36f7d9593ecaeb51efe1","Daniel Díaz","daniel.diaz@linaro.org","1579711464","Daniel Borkmann","daniel@iogearbox.net","1579711529","9638f0320392eed40c2588f4bd92846ef0816e8b","f59bbfc2f6099e8655f9e8f585e10ffde17176d0","selftests/bpf: Build urandom_read with LDFLAGS and LDLIBS During cross-compilation, it was discovered that LDFLAGS and LDLIBS were not being used while building binaries, leading to defaults which were not necessarily correct. OpenEmbedded reported this kind of problem: ERROR: QA Issue: No GNU_HASH in the ELF binary [...], didn't pass LDFLAGS? Signed-off-by: Daniel Díaz Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Acked-by: John Fastabend ","tools/testing/selftests/bpf/Makefile | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","The commit modifies the Makefile in eBPF selftests to use LDFLAGS and LDLIBS for building binaries, addressing cross-compilation issues.","selftests Makefile LDFLAGS","A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"f59bbfc2f6099e8655f9e8f585e10ffde17176d0","f59bbfc2f6099e8655f9e8f585e10ffde17176d0","Alexei Starovoitov","ast@kernel.org","1579660898","Daniel Borkmann","daniel@iogearbox.net","1579691342","0e3289384ee6ad1a13499afe74509574be73f27c","05d57f1793fb250c85028c9952c3720010baa853","bpf: Fix error path under memory pressure Restore the 'if (env->cur_state)' check that was incorrectly removed during code move. Under memory pressure env->cur_state can be freed and zeroed inside do_check(). Hence the check is necessary. Fixes: 51c39bb1d5d1 (""bpf: Introduce function-by-function verification"") Reported-by: syzbot+b296579ba5015704d9fa@syzkaller.appspotmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200122024138.3385590-1-ast@kernel.org","kernel/bpf/verifier.c | 9 +++++++--; 1 file changed, 7 insertions(+), 2 deletions(-)","The commit fixes a missing check for memory pressure conditions in the BPF verifier component.","fix, verifier, memory","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"05d57f1793fb250c85028c9952c3720010baa853","05d57f1793fb250c85028c9952c3720010baa853","Alexei Starovoitov","ast@kernel.org","1579576951","Daniel Borkmann","daniel@iogearbox.net","1579689081","746224e9acb03427aba28b7bb61e160379115f52","43a825afc91e2b06af1e8e7422198e759c2c5e20","bpf: Fix trampoline usage in preempt Though the second half of trampoline page is unused a task could be preempted in the middle of the first half of trampoline and two updates to trampoline would change the code from underneath the preempted task. Hence wait for tasks to voluntarily schedule or go to userspace. Add similar wait before freeing the trampoline. Fixes: fec56f5890d9 (""bpf: Introduce BPF trampoline"") Reported-by: Jann Horn Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: Paul E. McKenney Link: https://lore.kernel.org/bpf/20200121032231.3292185-1-ast@kernel.org","kernel/bpf/trampoline.c | 10 ++++++++++; 1 file changed, 10 insertions(+)","Fixes a preemption issue in BPF trampoline by adding waiters before freeing or updating trampoline code.","trampoline,preempt,fix","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.']" +"43a825afc91e2b06af1e8e7422198e759c2c5e20","43a825afc91e2b06af1e8e7422198e759c2c5e20","Björn Töpel","bjorn.topel@intel.com","1579512557","Daniel Borkmann","daniel@iogearbox.net","1579648132","2d3ea0e73f127ff6e3eb06dc5beb8fad7e44e798","b87121dd3fa0a4d2636c0ad02a3b3fc5161fa26b","xsk, net: Make sock_def_readable() have external linkage XDP sockets use the default implementation of struct sock's sk_data_ready callback, which is sock_def_readable(). This function is called in the XDP socket fast-path, and involves a retpoline. By letting sock_def_readable() have external linkage, and being called directly, the retpoline can be avoided. Signed-off-by: Björn Töpel Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200120092917.13949-1-bjorn.topel@gmail.com","include/net/sock.h | 2 ++; net/core/sock.c | 2 +-; net/xdp/xsk.c | 2 +-; 3 files changed, 4 insertions(+), 2 deletions(-)","The commit enhances XDP socket performance by avoiding retpoline via direct call to sock_def_readable with external linkage.","XDP,sock_def_readable,retpoline","A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.']" +"b87121dd3fa0a4d2636c0ad02a3b3fc5161fa26b","b87121dd3fa0a4d2636c0ad02a3b3fc5161fa26b","Al Viro","viro@zeniv.linux.org.uk","1579562938","Daniel Borkmann","daniel@iogearbox.net","1579646781","415cc073ffe6ea21ca3d25fc3c541115af8e6888","d49d0661b92478ec9362e379e7ba82450ec88048","bpf: don't bother with getname/kern_path - use user_path_at kernel/bpf/inode.c misuses kern_path...() - it's much simpler (and more efficient, on top of that) to use user_path...() counterparts rather than bothering with doing getname() manually. Signed-off-by: Al Viro Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200120232858.GF8904@ZenIV.linux.org.uk","kernel/bpf/inode.c | 43 +++++++++++++------------------------------; 1 file changed, 13 insertions(+), 30 deletions(-)","The commit improves efficiency by refactoring kernel/bpf/inode.c to use user_path_at instead of kern_path.","refactor, efficiency, user_path_at","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The syscall interface. It changes the system calls through which user-space programs interact with eBPF.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"9c5ed2f831c603439c699f8cd69e9998de472526","9c5ed2f831c603439c699f8cd69e9998de472526","David S. Miller","davem@davemloft.net","1579595158","David S. Miller","davem@davemloft.net","1579595158","6865c59045ca2c0ce71277b615d102251de15677","80892772c4edac88c538165d26a0105f19b61c1c 4e4362d2bf2a49ff44dbbc9585207977ca3d71d0","Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec Steffen Klassert says: ==================== pull request (net): ipsec 2020-01-21 1) Fix packet tx through bpf_redirect() for xfrm and vti interfaces. From Nicolas Dichtel. 2) Do not confirm neighbor when do pmtu update on a virtual xfrm interface. From Xu Wang. 3) Support output_mark for offload ESP packets, this was forgotten when the output_mark was added initially. From Ulrich Weber. Please pull or let me know if there are problems. ==================== Signed-off-by: David S. Miller ","","The commit merges a branch adding ipsec-related improvements and bpf_redirect packet transmission fixes.","merge, ipsec, bpf_redirect","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"d49d0661b92478ec9362e379e7ba82450ec88048","d49d0661b92478ec9362e379e7ba82450ec88048","Alexei Starovoitov","ast@kernel.org","1579567066","Alexei Starovoitov","ast@kernel.org","1579567274","5e6605d9c61cda6988756b21cbe59e0972c64bbc","f1c3656c6d9c147d07d16614455aceb34932bdeb a2c9652f751e3ab39738e2b30bc45293d53604fd","Merge branch 'libbpf-include-path' Toke Høiland-Jørgensen says: ==================== We are currently being somewhat inconsistent with the libbpf include paths, which makes it difficult to move files from the kernel into an external libbpf-using project without adjusting include paths. Having the bpf/ subdir of $INCLUDEDIR in the include path has never been a requirement for building against libbpf before, and indeed the libbpf pkg-config file doesn't include it. So let's make all libbpf includes across the kernel tree use the bpf/ prefix in their includes. Since bpftool skeleton generation emits code with a libbpf include, this also ensures that those can be used in existing external projects using the regular pkg-config include path. This turns out to be a somewhat invasive change in the number of files touched; however, the actual changes to files are fairly trivial (most of them are simply made with 'sed'). The series is split to make the change for one tool subdir at a time, while trying not to break the build along the way. It is structured like this: - Patch 1-3: Trivial fixes to Makefiles for issues I discovered while changing the include paths. - Patch 4-8: Change the include directives to use the bpf/ prefix, and updates Makefiles to make sure tools/lib/ is part of the include path, but without removing tools/lib/bpf - Patch 9-11: Remove tools/lib/bpf from include paths to make sure we don't inadvertently re-introduce includes without the bpf/ prefix. Changelog: v5: - Combine the libbpf build rules in selftests Makefile (using Andrii's suggestion for a make rule). - Re-use self-tests libbpf build for runqslower (new patch 10) - Formatting fixes v4: - Move runqslower error on missing BTF into make rule - Make sure we don't always force a rebuild selftests - Rebase on latest bpf-next (dropping patch 11) v3: - Don't add the kernel build dir to the runqslower Makefile, pass it in from selftests instead. - Use libbpf's 'make install_headers' in selftests instead of trying to generate bpf_helper_defs.h in-place (to also work on read-only filesystems). - Use a scratch builddir for both libbpf and bpftool when building in selftests. - Revert bpf_helpers.h to quoted include instead of angled include with a bpf/ prefix. - Fix a few style nits from Andrii v2: - Do a full cleanup of libbpf includes instead of just changing the bpf_helper_defs.h include. ==================== Acked-by: Andrii Nakryiko Tested-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov ","","The commit merges changes to standardize libbpf include paths across the kernel tree.","libbpf,inclusive paths,merge","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"a2c9652f751e3ab39738e2b30bc45293d53604fd","a2c9652f751e3ab39738e2b30bc45293d53604fd","Toke Høiland-Jørgensen","toke@redhat.com","1579525612","Alexei Starovoitov","ast@kernel.org","1579567066","5e6605d9c61cda6988756b21cbe59e0972c64bbc","b6580cd8999d4f6846db9f6daa0b759c75aff33e","selftests: Refactor build to remove tools/lib/bpf from include path To make sure no new files are introduced that doesn't include the bpf/ prefix in its #include, remove tools/lib/bpf from the include path entirely. Instead, we introduce a new header files directory under the scratch tools/ dir, and add a rule to run the 'install_headers' rule from libbpf to have a full set of consistent libbpf headers in $(OUTPUT)/tools/include/bpf, and then use $(OUTPUT)/tools/include as the include path for selftests. For consistency we also make sure we put all the scratch build files from other bpftool and libbpf into tools/build/, so everything stays within selftests/. Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/157952561246.1683545.2762245552022369203.stgit@toke.dk","tools/testing/selftests/bpf/.gitignore | 4 +--; tools/testing/selftests/bpf/Makefile | 59 +++++++++++++++++-----------------; 2 files changed, 30 insertions(+), 33 deletions(-)","The commit refactors selftest build setup to isolate libbpf headers and ensure a consistent include path.","refactor, selftests, include","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"b6580cd8999d4f6846db9f6daa0b759c75aff33e","b6580cd8999d4f6846db9f6daa0b759c75aff33e","Toke Høiland-Jørgensen","toke@redhat.com","1579525611","Alexei Starovoitov","ast@kernel.org","1579567065","9071517823c7671831978220cc802da07752ffee","a9ed34c0b7a537e38564d92eb4ff9eee91c84544","runsqslower: Support user-specified libbpf include and object paths This adds support for specifying the libbpf include and object paths as arguments to the runqslower Makefile, to support reusing the libbpf version built as part of the selftests. Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/157952561135.1683545.5660339645093141381.stgit@toke.dk","tools/bpf/runqslower/Makefile | 12 +++++++-----; 1 file changed, 7 insertions(+), 5 deletions(-)","This commit adds support for specifying libbpf include and object paths in the runqslower Makefile.","libbpf,runqslower,Makefile","A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"a9ed34c0b7a537e38564d92eb4ff9eee91c84544","a9ed34c0b7a537e38564d92eb4ff9eee91c84544","Toke Høiland-Jørgensen","toke@redhat.com","1579525610","Alexei Starovoitov","ast@kernel.org","1579567065","34585c620782abe4dabbbf3c86ccc942b2ea670c","7cf245a37ef013b2c1c5ca7ae25061de2ba7ad01","tools/runqslower: Remove tools/lib/bpf from include path Since we are now consistently using the bpf/ prefix on #include directives, we don't need to include tools/lib/bpf in the include path. Remove it to make sure we don't inadvertently introduce new includes without the prefix. Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/157952561027.1683545.1976265477926794138.stgit@toke.dk","tools/bpf/runqslower/Makefile | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","The commit removes an unnecessary include path in the runqslower Makefile to prevent incorrect include directives.","include,path,runqslower","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"7cf245a37ef013b2c1c5ca7ae25061de2ba7ad01","7cf245a37ef013b2c1c5ca7ae25061de2ba7ad01","Toke Høiland-Jørgensen","toke@redhat.com","1579525609","Alexei Starovoitov","ast@kernel.org","1579567065","b49b220dcc5f32ab9c39852ff8a73a0e3bda4c5a","521fe8bb5874963d5f6fd58d5c5ad80fbc9c6b1c","samples/bpf: Use consistent include paths for libbpf Fix all files in samples/bpf to include libbpf header files with the bpf/ prefix, to be consistent with external users of the library. Also ensure that all includes of exported libbpf header files (those that are exported on 'make install' of the library) use bracketed includes instead of quoted. To make sure no new files are introduced that doesn't include the bpf/ prefix in its include, remove tools/lib/bpf from the include path entirely, and use tools/lib instead. Fixes: 6910d7d3867a (""selftests/bpf: Ensure bpf_helper_defs.h are taken from selftests dir"") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Acked-by: Jesper Dangaard Brouer Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/157952560911.1683545.8795966751309534150.stgit@toke.dk","samples/bpf/Makefile | 3 +--; samples/bpf/cpustat_kern.c | 2 +-; samples/bpf/fds_example.c | 2 +-; samples/bpf/hbm.c | 4 ++--; samples/bpf/hbm_kern.h | 4 ++--; samples/bpf/ibumad_kern.c | 2 +-; samples/bpf/ibumad_user.c | 2 +-; samples/bpf/lathist_kern.c | 2 +-; samples/bpf/lwt_len_hist_kern.c | 2 +-; samples/bpf/map_perf_test_kern.c | 4 ++--; samples/bpf/offwaketime_kern.c | 4 ++--; samples/bpf/offwaketime_user.c | 2 +-; samples/bpf/parse_ldabs.c | 2 +-; samples/bpf/parse_simple.c | 2 +-; samples/bpf/parse_varlen.c | 2 +-; samples/bpf/sampleip_kern.c | 4 ++--; samples/bpf/sampleip_user.c | 2 +-; samples/bpf/sock_flags_kern.c | 2 +-; samples/bpf/sockex1_kern.c | 2 +-; samples/bpf/sockex1_user.c | 2 +-; samples/bpf/sockex2_kern.c | 2 +-; samples/bpf/sockex2_user.c | 2 +-; samples/bpf/sockex3_kern.c | 2 +-; samples/bpf/spintest_kern.c | 4 ++--; samples/bpf/spintest_user.c | 2 +-; samples/bpf/syscall_tp_kern.c | 2 +-; samples/bpf/task_fd_query_kern.c | 2 +-; samples/bpf/task_fd_query_user.c | 2 +-; samples/bpf/tc_l2_redirect_kern.c | 2 +-; samples/bpf/tcbpf1_kern.c | 2 +-; samples/bpf/tcp_basertt_kern.c | 4 ++--; samples/bpf/tcp_bufs_kern.c | 4 ++--; samples/bpf/tcp_clamp_kern.c | 4 ++--; samples/bpf/tcp_cong_kern.c | 4 ++--; samples/bpf/tcp_dumpstats_kern.c | 4 ++--; samples/bpf/tcp_iw_kern.c | 4 ++--; samples/bpf/tcp_rwnd_kern.c | 4 ++--; samples/bpf/tcp_synrto_kern.c | 4 ++--; samples/bpf/tcp_tos_reflect_kern.c | 4 ++--; samples/bpf/test_cgrp2_tc_kern.c | 2 +-; samples/bpf/test_current_task_under_cgroup_kern.c | 2 +-; samples/bpf/test_lwt_bpf.c | 2 +-; samples/bpf/test_map_in_map_kern.c | 4 ++--; samples/bpf/test_overhead_kprobe_kern.c | 4 ++--; samples/bpf/test_overhead_raw_tp_kern.c | 2 +-; samples/bpf/test_overhead_tp_kern.c | 2 +-; samples/bpf/test_probe_write_user_kern.c | 4 ++--; samples/bpf/trace_event_kern.c | 4 ++--; samples/bpf/trace_event_user.c | 2 +-; samples/bpf/trace_output_kern.c | 2 +-; samples/bpf/trace_output_user.c | 2 +-; samples/bpf/tracex1_kern.c | 4 ++--; samples/bpf/tracex2_kern.c | 4 ++--; samples/bpf/tracex3_kern.c | 4 ++--; samples/bpf/tracex4_kern.c | 4 ++--; samples/bpf/tracex5_kern.c | 4 ++--; samples/bpf/tracex6_kern.c | 2 +-; samples/bpf/tracex7_kern.c | 2 +-; samples/bpf/xdp1_kern.c | 2 +-; samples/bpf/xdp1_user.c | 4 ++--; samples/bpf/xdp2_kern.c | 2 +-; samples/bpf/xdp2skb_meta_kern.c | 2 +-; samples/bpf/xdp_adjust_tail_kern.c | 2 +-; samples/bpf/xdp_adjust_tail_user.c | 4 ++--; samples/bpf/xdp_fwd_kern.c | 2 +-; samples/bpf/xdp_fwd_user.c | 2 +-; samples/bpf/xdp_monitor_kern.c | 2 +-; samples/bpf/xdp_redirect_cpu_kern.c | 2 +-; samples/bpf/xdp_redirect_cpu_user.c | 2 +-; samples/bpf/xdp_redirect_kern.c | 2 +-; samples/bpf/xdp_redirect_map_kern.c | 2 +-; samples/bpf/xdp_redirect_map_user.c | 2 +-; samples/bpf/xdp_redirect_user.c | 2 +-; samples/bpf/xdp_router_ipv4_kern.c | 2 +-; samples/bpf/xdp_router_ipv4_user.c | 2 +-; samples/bpf/xdp_rxq_info_kern.c | 2 +-; samples/bpf/xdp_rxq_info_user.c | 4 ++--; samples/bpf/xdp_sample_pkts_kern.c | 2 +-; samples/bpf/xdp_sample_pkts_user.c | 2 +-; samples/bpf/xdp_tx_iptunnel_kern.c | 2 +-; samples/bpf/xdp_tx_iptunnel_user.c | 2 +-; samples/bpf/xdpsock_kern.c | 2 +-; samples/bpf/xdpsock_user.c | 6 +++---; 83 files changed, 112 insertions(+), 113 deletions(-)","The commit standardizes include paths for libbpf headers in samples/bpf to align with external usage conventions.","libbpf, include, refactoring","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"521fe8bb5874963d5f6fd58d5c5ad80fbc9c6b1c","521fe8bb5874963d5f6fd58d5c5ad80fbc9c6b1c","Toke Høiland-Jørgensen","toke@redhat.com","1579525608","Alexei Starovoitov","ast@kernel.org","1579567065","6a3374f202a597b0d18594cdb7d4ec39addebec0","229c3b47b794e7257744224b21a95d3d9938d00a","perf: Use consistent include paths for libbpf Fix perf to include libbpf header files with the bpf/ prefix, to be consistent with external users of the library. Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/157952560797.1683545.7685921032671386301.stgit@toke.dk","tools/perf/examples/bpf/5sec.c | 2 +-; tools/perf/examples/bpf/empty.c | 2 +-; tools/perf/examples/bpf/sys_enter_openat.c | 2 +-; tools/perf/include/bpf/pid_filter.h | 2 +-; tools/perf/include/bpf/stdio.h | 2 +-; tools/perf/include/bpf/unistd.h | 2 +-; 6 files changed, 6 insertions(+), 6 deletions(-)","The commit modifies include paths in the perf tool to use the bpf/ prefix for libbpf headers consistently.","perf,libbpf,headers","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"229c3b47b794e7257744224b21a95d3d9938d00a","229c3b47b794e7257744224b21a95d3d9938d00a","Toke Høiland-Jørgensen","toke@redhat.com","1579525606","Alexei Starovoitov","ast@kernel.org","1579567065","f691957c071585c8ccccdb9af6a7102223e9ee20","3e689141e64df91b009a289c0559adedfe62f511","bpftool: Use consistent include paths for libbpf Fix bpftool to include libbpf header files with the bpf/ prefix, to be consistent with external users of the library. Also ensure that all includes of exported libbpf header files (those that are exported on 'make install' of the library) use bracketed includes instead of quoted. To make sure no new files are introduced that doesn't include the bpf/ prefix in its include, remove tools/lib/bpf from the include path entirely, and use tools/lib instead. Fixes: 6910d7d3867a (""selftests/bpf: Ensure bpf_helper_defs.h are taken from selftests dir"") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/157952560684.1683545.4765181397974997027.stgit@toke.dk","tools/bpf/bpftool/Documentation/bpftool-gen.rst | 2 +-; tools/bpf/bpftool/Makefile | 2 +-; tools/bpf/bpftool/btf.c | 8 ++++----; tools/bpf/bpftool/btf_dumper.c | 2 +-; tools/bpf/bpftool/cgroup.c | 2 +-; tools/bpf/bpftool/common.c | 4 ++--; tools/bpf/bpftool/feature.c | 4 ++--; tools/bpf/bpftool/gen.c | 10 +++++-----; tools/bpf/bpftool/jit_disasm.c | 2 +-; tools/bpf/bpftool/main.c | 4 ++--; tools/bpf/bpftool/map.c | 4 ++--; tools/bpf/bpftool/map_perf_ring.c | 4 ++--; tools/bpf/bpftool/net.c | 8 ++++----; tools/bpf/bpftool/netlink_dumper.c | 4 ++--; tools/bpf/bpftool/perf.c | 2 +-; tools/bpf/bpftool/prog.c | 6 +++---; tools/bpf/bpftool/xlated_dumper.c | 2 +-; 17 files changed, 35 insertions(+), 35 deletions(-)","Standardize include paths in bpftool for consistency with libbpf usage.","bpftool,libbpf,include","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"3e689141e64df91b009a289c0559adedfe62f511","3e689141e64df91b009a289c0559adedfe62f511","Toke Høiland-Jørgensen","toke@redhat.com","1579525605","Alexei Starovoitov","ast@kernel.org","1579567065","2361f2b035c3ca738917880c3c595dc32cdbe694","5b554ce518afee47d4ba4330ad8fbfd6e29e1c13","selftests: Use consistent include paths for libbpf Fix all selftests to include libbpf header files with the bpf/ prefix, to be consistent with external users of the library. Also ensure that all includes of exported libbpf header files (those that are exported on 'make install' of the library) use bracketed includes instead of quoted. To not break the build, keep the old include path until everything has been changed to the new one; a subsequent patch will remove that. Fixes: 6910d7d3867a (""selftests/bpf: Ensure bpf_helper_defs.h are taken from selftests dir"") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/157952560568.1683545.9649335788846513446.stgit@toke.dk","tools/testing/selftests/bpf/Makefile | 2 +-; tools/testing/selftests/bpf/bpf_tcp_helpers.h | 4 ++--; tools/testing/selftests/bpf/bpf_trace_helpers.h | 2 +-; tools/testing/selftests/bpf/bpf_util.h | 2 +-; tools/testing/selftests/bpf/prog_tests/cpu_mask.c | 2 +-; tools/testing/selftests/bpf/prog_tests/perf_buffer.c | 2 +-; tools/testing/selftests/bpf/progs/bpf_dctcp.c | 4 ++--; tools/testing/selftests/bpf/progs/bpf_flow.c | 4 ++--; tools/testing/selftests/bpf/progs/connect4_prog.c | 4 ++--; tools/testing/selftests/bpf/progs/connect6_prog.c | 4 ++--; tools/testing/selftests/bpf/progs/dev_cgroup.c | 2 +-; tools/testing/selftests/bpf/progs/fentry_test.c | 2 +-; tools/testing/selftests/bpf/progs/fexit_bpf2bpf.c | 2 +-; tools/testing/selftests/bpf/progs/fexit_bpf2bpf_simple.c | 2 +-; tools/testing/selftests/bpf/progs/fexit_test.c | 2 +-; tools/testing/selftests/bpf/progs/get_cgroup_id_kern.c | 2 +-; tools/testing/selftests/bpf/progs/kfree_skb.c | 4 ++--; tools/testing/selftests/bpf/progs/loop1.c | 4 ++--; tools/testing/selftests/bpf/progs/loop2.c | 4 ++--; tools/testing/selftests/bpf/progs/loop3.c | 4 ++--; tools/testing/selftests/bpf/progs/loop4.c | 2 +-; tools/testing/selftests/bpf/progs/loop5.c | 2 +-; tools/testing/selftests/bpf/progs/netcnt_prog.c | 2 +-; tools/testing/selftests/bpf/progs/pyperf.h | 2 +-; tools/testing/selftests/bpf/progs/sample_map_ret0.c | 2 +-; tools/testing/selftests/bpf/progs/sendmsg4_prog.c | 4 ++--; tools/testing/selftests/bpf/progs/sendmsg6_prog.c | 4 ++--; tools/testing/selftests/bpf/progs/socket_cookie_prog.c | 4 ++--; tools/testing/selftests/bpf/progs/sockmap_parse_prog.c | 4 ++--; tools/testing/selftests/bpf/progs/sockmap_tcp_msg_prog.c | 4 ++--; tools/testing/selftests/bpf/progs/sockmap_verdict_prog.c | 4 ++--; tools/testing/selftests/bpf/progs/sockopt_inherit.c | 2 +-; tools/testing/selftests/bpf/progs/sockopt_multi.c | 2 +-; tools/testing/selftests/bpf/progs/sockopt_sk.c | 2 +-; tools/testing/selftests/bpf/progs/strobemeta.h | 2 +-; tools/testing/selftests/bpf/progs/tailcall1.c | 2 +-; tools/testing/selftests/bpf/progs/tailcall2.c | 2 +-; tools/testing/selftests/bpf/progs/tailcall3.c | 2 +-; tools/testing/selftests/bpf/progs/tailcall4.c | 2 +-; tools/testing/selftests/bpf/progs/tailcall5.c | 2 +-; tools/testing/selftests/bpf/progs/tcp_rtt.c | 2 +-; tools/testing/selftests/bpf/progs/test_adjust_tail.c | 2 +-; tools/testing/selftests/bpf/progs/test_attach_probe.c | 2 +-; tools/testing/selftests/bpf/progs/test_btf_haskv.c | 2 +-; tools/testing/selftests/bpf/progs/test_btf_newkv.c | 2 +-; tools/testing/selftests/bpf/progs/test_btf_nokv.c | 2 +-; tools/testing/selftests/bpf/progs/test_core_extern.c | 2 +-; tools/testing/selftests/bpf/progs/test_core_reloc_arrays.c | 4 ++--; .../testing/selftests/bpf/progs/test_core_reloc_bitfields_direct.c | 4 ++--; .../testing/selftests/bpf/progs/test_core_reloc_bitfields_probed.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_existence.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_flavors.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_ints.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_kernel.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_misc.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_mods.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_nesting.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_primitives.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_ptr_as_arr.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_size.c | 4 ++--; tools/testing/selftests/bpf/progs/test_get_stack_rawtp.c | 2 +-; tools/testing/selftests/bpf/progs/test_global_data.c | 2 +-; tools/testing/selftests/bpf/progs/test_global_func1.c | 2 +-; tools/testing/selftests/bpf/progs/test_global_func3.c | 2 +-; tools/testing/selftests/bpf/progs/test_global_func5.c | 2 +-; tools/testing/selftests/bpf/progs/test_global_func6.c | 2 +-; tools/testing/selftests/bpf/progs/test_global_func7.c | 2 +-; tools/testing/selftests/bpf/progs/test_l4lb.c | 4 ++--; tools/testing/selftests/bpf/progs/test_l4lb_noinline.c | 4 ++--; tools/testing/selftests/bpf/progs/test_lirc_mode2_kern.c | 2 +-; tools/testing/selftests/bpf/progs/test_lwt_ip_encap.c | 4 ++--; tools/testing/selftests/bpf/progs/test_lwt_seg6local.c | 4 ++--; tools/testing/selftests/bpf/progs/test_map_in_map.c | 2 +-; tools/testing/selftests/bpf/progs/test_map_lock.c | 2 +-; tools/testing/selftests/bpf/progs/test_mmap.c | 2 +-; tools/testing/selftests/bpf/progs/test_obj_id.c | 2 +-; tools/testing/selftests/bpf/progs/test_overhead.c | 4 ++--; tools/testing/selftests/bpf/progs/test_perf_buffer.c | 2 +-; tools/testing/selftests/bpf/progs/test_pinning.c | 2 +-; tools/testing/selftests/bpf/progs/test_pinning_invalid.c | 2 +-; tools/testing/selftests/bpf/progs/test_pkt_access.c | 4 ++--; tools/testing/selftests/bpf/progs/test_pkt_md_access.c | 2 +-; tools/testing/selftests/bpf/progs/test_probe_user.c | 4 ++--; tools/testing/selftests/bpf/progs/test_queue_stack_map.h | 2 +-; tools/testing/selftests/bpf/progs/test_rdonly_maps.c | 2 +-; tools/testing/selftests/bpf/progs/test_seg6_loop.c | 4 ++--; tools/testing/selftests/bpf/progs/test_select_reuseport_kern.c | 4 ++--; tools/testing/selftests/bpf/progs/test_send_signal_kern.c | 2 +-; tools/testing/selftests/bpf/progs/test_sk_lookup_kern.c | 4 ++--; tools/testing/selftests/bpf/progs/test_skb_cgroup_id_kern.c | 2 +-; tools/testing/selftests/bpf/progs/test_skb_ctx.c | 2 +-; tools/testing/selftests/bpf/progs/test_skeleton.c | 2 +-; tools/testing/selftests/bpf/progs/test_sock_fields_kern.c | 4 ++--; tools/testing/selftests/bpf/progs/test_spin_lock.c | 2 +-; tools/testing/selftests/bpf/progs/test_stacktrace_build_id.c | 2 +-; tools/testing/selftests/bpf/progs/test_stacktrace_map.c | 2 +-; tools/testing/selftests/bpf/progs/test_sysctl_loop1.c | 2 +-; tools/testing/selftests/bpf/progs/test_sysctl_loop2.c | 2 +-; tools/testing/selftests/bpf/progs/test_sysctl_prog.c | 2 +-; tools/testing/selftests/bpf/progs/test_tc_edt.c | 4 ++--; tools/testing/selftests/bpf/progs/test_tc_tunnel.c | 4 ++--; tools/testing/selftests/bpf/progs/test_tcp_check_syncookie_kern.c | 4 ++--; tools/testing/selftests/bpf/progs/test_tcp_estats.c | 2 +-; tools/testing/selftests/bpf/progs/test_tcpbpf_kern.c | 4 ++--; tools/testing/selftests/bpf/progs/test_tcpnotify_kern.c | 4 ++--; tools/testing/selftests/bpf/progs/test_tracepoint.c | 2 +-; tools/testing/selftests/bpf/progs/test_tunnel_kern.c | 4 ++--; tools/testing/selftests/bpf/progs/test_verif_scale1.c | 2 +-; tools/testing/selftests/bpf/progs/test_verif_scale2.c | 2 +-; tools/testing/selftests/bpf/progs/test_verif_scale3.c | 2 +-; tools/testing/selftests/bpf/progs/test_xdp.c | 4 ++--; tools/testing/selftests/bpf/progs/test_xdp_bpf2bpf.c | 2 +-; tools/testing/selftests/bpf/progs/test_xdp_loop.c | 4 ++--; tools/testing/selftests/bpf/progs/test_xdp_meta.c | 2 +-; tools/testing/selftests/bpf/progs/test_xdp_noinline.c | 4 ++--; tools/testing/selftests/bpf/progs/test_xdp_redirect.c | 2 +-; tools/testing/selftests/bpf/progs/test_xdp_vlan.c | 4 ++--; tools/testing/selftests/bpf/progs/xdp_dummy.c | 2 +-; tools/testing/selftests/bpf/progs/xdp_redirect_map.c | 2 +-; tools/testing/selftests/bpf/progs/xdp_tx.c | 2 +-; tools/testing/selftests/bpf/progs/xdping_kern.c | 4 ++--; tools/testing/selftests/bpf/test_cpp.cpp | 6 +++---; tools/testing/selftests/bpf/test_hashmap.c | 2 +-; tools/testing/selftests/bpf/test_progs.h | 2 +-; tools/testing/selftests/bpf/test_sock.c | 2 +-; tools/testing/selftests/bpf/test_sockmap_kern.h | 4 ++--; tools/testing/selftests/bpf/test_sysctl.c | 2 +-; tools/testing/selftests/bpf/trace_helpers.h | 2 +-; 128 files changed, 181 insertions(+), 181 deletions(-)","This commit updates selftests to use consistent include paths and formats for libbpf headers without breaking the build.","selftests,libbpf,include","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"5b554ce518afee47d4ba4330ad8fbfd6e29e1c13","5b554ce518afee47d4ba4330ad8fbfd6e29e1c13","Toke Høiland-Jørgensen","toke@redhat.com","1579525604","Alexei Starovoitov","ast@kernel.org","1579567065","de56fe284d857ef662d98a70c0de0b8da77b2abb","bfe42797bc7e962f01028436e106769ca9338b65","tools/runqslower: Use consistent include paths for libbpf Fix the runqslower tool to include libbpf header files with the bpf/ prefix, to be consistent with external users of the library. Also ensure that all includes of exported libbpf header files (those that are exported on 'make install' of the library) use bracketed includes instead of quoted. To not break the build, keep the old include path until everything has been changed to the new one; a subsequent patch will remove that. Fixes: 6910d7d3867a (""selftests/bpf: Ensure bpf_helper_defs.h are taken from selftests dir"") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/157952560457.1683545.9913736511685743625.stgit@toke.dk","tools/bpf/runqslower/Makefile | 5 +++--; tools/bpf/runqslower/runqslower.bpf.c | 2 +-; tools/bpf/runqslower/runqslower.c | 4 ++--; 3 files changed, 6 insertions(+), 5 deletions(-)","Fixes include paths in runqslower tool for consistent usage of libbpf headers with external users.","include paths, libbpf, runqslower","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"bfe42797bc7e962f01028436e106769ca9338b65","bfe42797bc7e962f01028436e106769ca9338b65","Toke Høiland-Jørgensen","toke@redhat.com","1579525603","Alexei Starovoitov","ast@kernel.org","1579567065","e6764d26561351b699ee0fa2ce043f4ae9176fd3","a835d38d41ca4f8eab5f97512446212f42f094a1","selftests: Pass VMLINUX_BTF to runqslower Makefile Add a VMLINUX_BTF variable with the locally-built path when calling the runqslower Makefile from selftests. This makes sure a simple 'make' invocation in the selftests dir works even when there is no BTF information for the running kernel. Do a wildcard expansion and include the same paths for BTF for the running kernel as in the runqslower Makefile, to make it possible to build selftests without having a vmlinux in the local tree. Also fix the make invocation to use $(OUTPUT)/tools as the destination directory instead of $(CURDIR)/tools. Fixes: 3a0d3092a4ed (""selftests/bpf: Build runqslower from selftests"") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/157952560344.1683545.2723631988771664417.stgit@toke.dk","tools/testing/selftests/bpf/Makefile | 8 ++++++--; 1 file changed, 6 insertions(+), 2 deletions(-)","This commit modifies the selftests Makefile to ensure proper BTF path handling and output directory configuration for the runqslower tool.","selftests, Makefile, runqslower","A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"a835d38d41ca4f8eab5f97512446212f42f094a1","a835d38d41ca4f8eab5f97512446212f42f094a1","Toke Høiland-Jørgensen","toke@redhat.com","1579525602","Alexei Starovoitov","ast@kernel.org","1579567065","a496cdc61b86d0f35995799dc75c6a69084f974a","b2e5e93ae8af6a34bca536cdc4b453ab1e707b8b","tools/bpf/runqslower: Fix override option for VMLINUX_BTF The runqslower tool refuses to build without a file to read vmlinux BTF from. The build fails with an error message to override the location by setting the VMLINUX_BTF variable if autodetection fails. However, the Makefile doesn't actually work with that override - the error message is still emitted. Fix this by including the value of VMLINUX_BTF in the expansion, and only emitting the error message if the *result* is empty. Also permit running 'make clean' even though no VMLINUX_BTF is set. Fixes: 9c01546d26d2 (""tools/bpf: Add runqslower tool to tools/bpf"") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/157952560237.1683545.17771785178857224877.stgit@toke.dk","tools/bpf/runqslower/Makefile | 19 ++++++++++---------; 1 file changed, 10 insertions(+), 9 deletions(-)","This commit fixes the Makefile to correctly handle the VMLINUX_BTF variable override in the runqslower tool.","runqslower,VMLINUX_BTF,Makefile","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"b2e5e93ae8af6a34bca536cdc4b453ab1e707b8b","b2e5e93ae8af6a34bca536cdc4b453ab1e707b8b","Toke Høiland-Jørgensen","toke@redhat.com","1579525601","Alexei Starovoitov","ast@kernel.org","1579567065","16c28b8b1cd34c52fce69fa4de8574e224fcbc7b","f1c3656c6d9c147d07d16614455aceb34932bdeb","samples/bpf: Don't try to remove user's homedir on clean The 'clean' rule in the samples/bpf Makefile tries to remove backup files (ending in ~). However, if no such files exist, it will instead try to remove the user's home directory. While the attempt is mostly harmless, it does lead to a somewhat scary warning like this: rm: cannot remove '~': Is a directory Fix this by using find instead of shell expansion to locate any actual backup files that need to be removed. Fixes: b62a796c109c (""samples/bpf: allow make to be run from samples/bpf/ directory"") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Acked-by: Jesper Dangaard Brouer Link: https://lore.kernel.org/bpf/157952560126.1683545.7273054725976032511.stgit@toke.dk","samples/bpf/Makefile | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","Fixes the Makefile in samples/bpf to only remove backup files and avoid unintended deletion attempts.","Makefile, clean, backup","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"4f29ad200f7b40fbcf73cd65f95087535ba78380","4f29ad200f7b40fbcf73cd65f95087535ba78380","Alexander Lobakin","alobakin@dlink.ru","1579269729","Paul Burton","paulburton@kernel.org","1579563574","c4bd9d259e552442f31147e7d35ac2e481ec7218","16202c09577f3d0c533274c0410b7de05fb0d458","MIPS: syscalls: fix indentation of the 'SYSNR' message It also lacks a whitespace (copy'n'paste error?) and also messes up the output: SYSHDR arch/mips/include/generated/uapi/asm/unistd_n32.h SYSHDR arch/mips/include/generated/uapi/asm/unistd_n64.h SYSHDR arch/mips/include/generated/uapi/asm/unistd_o32.h SYSNR arch/mips/include/generated/uapi/asm/unistd_nr_n32.h SYSNR arch/mips/include/generated/uapi/asm/unistd_nr_n64.h SYSNR arch/mips/include/generated/uapi/asm/unistd_nr_o32.h WRAP arch/mips/include/generated/uapi/asm/bpf_perf_event.h WRAP arch/mips/include/generated/uapi/asm/ipcbuf.h After: SYSHDR arch/mips/include/generated/uapi/asm/unistd_n32.h SYSHDR arch/mips/include/generated/uapi/asm/unistd_n64.h SYSHDR arch/mips/include/generated/uapi/asm/unistd_o32.h SYSNR arch/mips/include/generated/uapi/asm/unistd_nr_n32.h SYSNR arch/mips/include/generated/uapi/asm/unistd_nr_n64.h SYSNR arch/mips/include/generated/uapi/asm/unistd_nr_o32.h WRAP arch/mips/include/generated/uapi/asm/bpf_perf_event.h WRAP arch/mips/include/generated/uapi/asm/ipcbuf.h Present since day 0 of syscall table generation introduction for MIPS. Fixes: 9bcbf97c6293 (""mips: add system call table generation support"") Cc: # v5.0+ Signed-off-by: Alexander Lobakin Signed-off-by: Paul Burton Cc: Ralf Baechle Cc: James Hogan Cc: Masahiro Yamada Cc: Rob Herring Cc: linux-mips@vger.kernel.org Cc: linux-kernel@vger.kernel.org","arch/mips/kernel/syscalls/Makefile | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","This commit fixes indentation and formatting issues in the MIPS syscall header message.","MIPS, syscalls, indentation","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.","It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.","[""It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.""]" +"f1c3656c6d9c147d07d16614455aceb34932bdeb","f1c3656c6d9c147d07d16614455aceb34932bdeb","Hangbin Liu","liuhangbin@gmail.com","1579255616","Daniel Borkmann","daniel@iogearbox.net","1579559218","7473c25bcdbf6fa287f7fc459ce35e0a535c7fff","396b83fa75a3deb9aa68296c090f4eb540917d9d","selftests/bpf: Skip perf hw events test if the setup disabled it The same with commit 4e59afbbed96 (""selftests/bpf: skip nmi test when perf hw events are disabled""), it would make more sense to skip the test_stacktrace_build_id_nmi test if the setup (e.g. virtual machines) has disabled hardware perf events. Fixes: 13790d1cc72c (""bpf: add selftest for stackmap with build_id in NMI context"") Signed-off-by: Hangbin Liu Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200117100656.10359-1-liuhangbin@gmail.com","tools/testing/selftests/bpf/prog_tests/stacktrace_build_id_nmi.c | 8 ++++++--; 1 file changed, 6 insertions(+), 2 deletions(-)","The commit modifies a BPF self-test to skip when hardware perf events are disabled on the setup.","selftests,bpf,skip","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.']" +"396b83fa75a3deb9aa68296c090f4eb540917d9d","396b83fa75a3deb9aa68296c090f4eb540917d9d","Stanislav Fomichev","sdf@google.com","1579309546","Daniel Borkmann","daniel@iogearbox.net","1579556943","c43258d93d015f3b1f40b35ad42babad6bebdb2e","2e3a94aa2bfc6de95a0700f0a868c6f5db3a9592","selftests/bpf: Don't check for btf fd in test_btf After commit 0d13bfce023a (""libbpf: Don't require root for bpf_object__open()"") we no longer load BTF during bpf_object__open(), so let's remove the expectation from test_btf that the fd is not -1. The test currently fails. Before: BTF libbpf test[1] (test_btf_haskv.o): do_test_file:4152:FAIL bpf_object__btf_fd: -1 BTF libbpf test[2] (test_btf_newkv.o): do_test_file:4152:FAIL bpf_object__btf_fd: -1 BTF libbpf test[3] (test_btf_nokv.o): do_test_file:4152:FAIL bpf_object__btf_fd: -1 After: BTF libbpf test[1] (test_btf_haskv.o): OK BTF libbpf test[2] (test_btf_newkv.o): OK BTF libbpf test[3] (test_btf_nokv.o): OK Fixes: 0d13bfce023a (""libbpf: Don't require root for bpf_object__open()"") Signed-off-by: Stanislav Fomichev Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200118010546.74279-1-sdf@google.com","tools/testing/selftests/bpf/test_btf.c | 4 ----; 1 file changed, 4 deletions(-)","The commit modifies libbpf selftests to remove BTF file descriptor checks after changes in bpf_object__open().","selftests,BTF,libbpf","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"2e3a94aa2bfc6de95a0700f0a868c6f5db3a9592","2e3a94aa2bfc6de95a0700f0a868c6f5db3a9592","Brian Vazquez","brianvv@google.com","1579462840","Daniel Borkmann","daniel@iogearbox.net","1579555671","18ee2f84509602f1383c1dcf8a55d49130bb342e","a6ed02cac690b635dbb938690e795812ce1e14ca","bpf: Fix memory leaks in generic update/delete batch ops Generic update/delete batch ops functions were using __bpf_copy_key without properly freeing the memory. Handle the memory allocation and copy_from_user separately. Fixes: aa2e93b8e58e (""bpf: Add generic support for update and delete batch ops"") Reported-by: Dan Carpenter Signed-off-by: Brian Vazquez Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200119194040.128369-1-brianvv@google.com","kernel/bpf/syscall.c | 30 +++++++++++++++++++-----------; 1 file changed, 19 insertions(+), 11 deletions(-)","This commit addresses memory leaks in bpf's generic update and delete batch operations by separating memory allocation and copying.","memory, update, leaks","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The syscall interface. It changes the system calls through which user-space programs interact with eBPF.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"11a827294755ce3d07e14cfe257b3ec16ab56f34","11a827294755ce3d07e14cfe257b3ec16ab56f34","Linus Torvalds","torvalds@linux-foundation.org","1579464233","Linus Torvalds","torvalds@linux-foundation.org","1579464233","aec0c252be85a7a53594132451ccf84eb9e3c7d2","5f43644394a96a8bcd8fc29a8bbd9c40b4465b54 b2383ad987a61bdd3a0a4ec3f343fbf0e3d9067b","Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from David Miller: 1) Fix non-blocking connect() in x25, from Martin Schiller. 2) Fix spurious decryption errors in kTLS, from Jakub Kicinski. 3) Netfilter use-after-free in mtype_destroy(), from Cong Wang. 4) Limit size of TSO packets properly in lan78xx driver, from Eric Dumazet. 5) r8152 probe needs an endpoint sanity check, from Johan Hovold. 6) Prevent looping in tcp_bpf_unhash() during sockmap/tls free, from John Fastabend. 7) hns3 needs short frames padded on transmit, from Yunsheng Lin. 8) Fix netfilter ICMP header corruption, from Eyal Birger. 9) Fix soft lockup when low on memory in hns3, from Yonglong Liu. 10) Fix NTUPLE firmware command failures in bnxt_en, from Michael Chan. 11) Fix memory leak in act_ctinfo, from Eric Dumazet. * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (91 commits) cxgb4: reject overlapped queues in TC-MQPRIO offload cxgb4: fix Tx multi channel port rate limit net: sched: act_ctinfo: fix memory leak bnxt_en: Do not treat DSN (Digital Serial Number) read failure as fatal. bnxt_en: Fix ipv6 RFS filter matching logic. bnxt_en: Fix NTUPLE firmware command failures. net: systemport: Fixed queue mapping in internal ring map net: dsa: bcm_sf2: Configure IMP port for 2Gb/sec net: dsa: sja1105: Don't error out on disabled ports with no phy-mode net: phy: dp83867: Set FORCE_LINK_GOOD to default after reset net: hns: fix soft lockup when there is not enough memory net: avoid updating qdisc_xmit_lock_key in netdev_update_lockdep_key() net/sched: act_ife: initalize ife->metalist earlier netfilter: nat: fix ICMP header corruption on ICMP errors net: wan: lapbether.c: Use built-in RCU list checking netfilter: nf_tables: fix flowtable list del corruption netfilter: nf_tables: fix memory leak in nf_tables_parse_netdev_hooks() netfilter: nf_tables: remove WARN and add NLA_STRING upper limits netfilter: nft_tunnel: ERSPAN_VERSION must not be null netfilter: nft_tunnel: fix null-attribute check ...","","The commit merges networking fixes including memory leak resolutions and driver improvements from multiple contributors.","networking, fixes, merge","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"a6ed02cac690b635dbb938690e795812ce1e14ca","a6ed02cac690b635dbb938690e795812ce1e14ca","KP Singh","kpsingh@google.com","1579296505","Alexei Starovoitov","ast@kernel.org","1579298374","ba5d20de0b6fc00988964ae2ab917a90651a08a1","c701917e647c6aaee5e7bbb7a2c1ca99e8552c58","libbpf: Load btf_vmlinux only once per object. As more programs (TRACING, STRUCT_OPS, and upcoming LSM) use vmlinux BTF information, loading the BTF vmlinux information for every program in an object is sub-optimal. The fix was originally proposed in: https://lore.kernel.org/bpf/CAEf4BzZodr3LKJuM7QwD38BiEH02Cc1UbtnGpVkCJ00Mf+V_Qg@mail.gmail.com/ The btf_vmlinux is populated in the object if any of the programs in the object requires it just before the programs are loaded and freed after the programs finish loading. Reported-by: Andrii Nakryiko Signed-off-by: KP Singh Signed-off-by: Alexei Starovoitov Reviewed-by: Brendan Jackman Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200117212825.11755-1-kpsingh@chromium.org","tools/lib/bpf/libbpf.c | 153 ++++++++++++++++++++++++++++++++-----------------; 1 file changed, 101 insertions(+), 52 deletions(-)","Optimize libbpf to load vmlinux BTF information only once per object, improving efficiency for tracing, struct_ops, and LSM programs.","libbpf BTF vmlinux","A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.', 'LSM type related programs. It relates to eBPF programs used with Linux Security Modules (LSMs) for security enhancements.', 'Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems.']" +"c701917e647c6aaee5e7bbb7a2c1ca99e8552c58","c701917e647c6aaee5e7bbb7a2c1ca99e8552c58","Andrii Nakryiko","andriin@fb.com","1579241280","Alexei Starovoitov","ast@kernel.org","1579278798","ed0c7062d3151b9b6cfcb9707830726159069f84","b7d7f3e185b6e643dcd49d1486b11cade8519008","libbpf: Fix potential multiplication overflow in mmap() size calculation Prevent potential overflow performed in 32-bit integers, before assigning result to size_t. Reported by LGTM static analysis. Fixes: eba9c5f498a1 (""libbpf: Refactor global data map initialization"") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200117060801.1311525-4-andriin@fb.com","tools/lib/bpf/libbpf.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","The commit fixes a potential integer overflow issue in libbpf's mmap size calculation.","libbpf, overflow, mmap","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"b7d7f3e185b6e643dcd49d1486b11cade8519008","b7d7f3e185b6e643dcd49d1486b11cade8519008","Andrii Nakryiko","andriin@fb.com","1579241279","Alexei Starovoitov","ast@kernel.org","1579278798","2eeca14116e1f2fdf5df051c0945109f6ced3e05","bc0eb9a333918d2cc4f42f7f4cf09eaf029ac9de","libbpf: Simplify BTF initialization logic Current implementation of bpf_object's BTF initialization is very convoluted and thus prone to errors. It doesn't have to be like that. This patch simplifies it significantly. This code also triggered static analysis issues over logically dead code due to redundant error checks. This simplification should fix that as well. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200117060801.1311525-3-andriin@fb.com","tools/lib/bpf/libbpf.c | 19 ++++++-------------; 1 file changed, 6 insertions(+), 13 deletions(-)","The commit simplifies the BTF initialization logic in libbpf to reduce errors and eliminate redundant code.","BTF,libbpf,simplification","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"bc0eb9a333918d2cc4f42f7f4cf09eaf029ac9de","bc0eb9a333918d2cc4f42f7f4cf09eaf029ac9de","Andrii Nakryiko","andriin@fb.com","1579241278","Alexei Starovoitov","ast@kernel.org","1579278797","38d803f76d5523637b4cb1736c124c6f3e0a4da9","81f2b572cf4fd5c4178fe0e2b5bb1ab096385fd8","libbpf: Fix error handling bug in btf_dump__new Fix missing jump to error handling in btf_dump__new, found by Coverity static code analysis. Fixes: 9f81654eebe8 (""libbpf: Expose BTF-to-C type declaration emitting API"") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200117060801.1311525-2-andriin@fb.com","tools/lib/bpf/btf_dump.c | 1 +; 1 file changed, 1 insertion(+)","Fixed an error handling bug in btf_dump__new function detected by Coverity static code analysis.","error, handling, bug","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"81f2b572cf4fd5c4178fe0e2b5bb1ab096385fd8","81f2b572cf4fd5c4178fe0e2b5bb1ab096385fd8","YueHaibing","yuehaibing@huawei.com","1579186380","Alexei Starovoitov","ast@kernel.org","1579234524","a2c3e4e52fd06dc0be4eafed681aad06fbc27f81","ba92660362ec42db3baee5af2b47b85d70c1c4be","bpf: Remove set but not used variable 'first_key' kernel/bpf/syscall.c: In function generic_map_lookup_batch: kernel/bpf/syscall.c:1339:7: warning: variable first_key set but not used [-Wunused-but-set-variable] It is never used, so remove it. Reported-by: Hulk Robot Signed-off-by: YueHaibing Signed-off-by: Alexei Starovoitov Acked-by: Brian Vazquez Link: https://lore.kernel.org/bpf/20200116145300.59056-1-yuehaibing@huawei.com","kernel/bpf/syscall.c | 2 --; 1 file changed, 2 deletions(-)","This commit removes an unused variable 'first_key' from the bpf syscall code.","remove, unused, variable","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The syscall interface. It changes the system calls through which user-space programs interact with eBPF.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"ba92660362ec42db3baee5af2b47b85d70c1c4be","ba92660362ec42db3baee5af2b47b85d70c1c4be","Alexei Starovoitov","ast@kernel.org","1579233815","Alexei Starovoitov","ast@kernel.org","1579233821","7de417a5b4a09f9982d8d29e5f3da95299b501bb","20f21d98cf12b8ecd69e8defc93fae9e3b353b13 58aa94f922c1b44e0919d1814d2eab5b9e8bf945","Merge branch 'xdp_redirect-bulking' Toke Høiland-Jørgensen says: ==================== Since commit 96360004b862 (""xdp: Make devmap flush_list common for all map instances""), devmap flushing is a global operation instead of tied to a particular map. This means that with a bit of refactoring, we can finally fix the performance delta between the bpf_redirect_map() and bpf_redirect() helper functions, by introducing bulking for the latter as well. This series makes this change by moving the data structure used for the bulking into struct net_device itself, so we can access it even when there is not devmap. Once this is done, moving the bpf_redirect() helper to use the bulking mechanism becomes quite trivial, and brings bpf_redirect() up to the same as bpf_redirect_map(): Before: After: 1 CPU: bpf_redirect_map: 8.4 Mpps 8.4 Mpps (no change) bpf_redirect: 5.0 Mpps 8.4 Mpps (+68%) 2 CPUs: bpf_redirect_map: 15.9 Mpps 16.1 Mpps (+1% or ~no change) bpf_redirect: 9.5 Mpps 15.9 Mpps (+67%) After this patch series, the only semantics different between the two variants of the bpf() helper (apart from the absence of a map argument, obviously) is that the _map() variant will return an error if passed an invalid map index, whereas the bpf_redirect() helper will succeed, but drop packets on xdp_do_redirect(). This is because the helper has no reference to the calling netdev, so unfortunately we can't do the ifindex lookup directly in the helper. Changelog: v3: - Switch two more fields to avoid a list_head spanning two cache lines - Include Jesper's tracepoint patch - Also rename xdp_do_flush_map() - Fix a few nits from Maciej v2: - Consolidate code paths and tracepoints for map and non-map redirect variants (Björn) - Add performance data for 2-CPU test (Jesper) - Move fields to avoid shifting cache lines in struct net_device (Eric) ==================== Signed-off-by: Alexei Starovoitov ","","This commit merges the 'xdp_redirect-bulking' branch to improve bpf_redirect() performance by applying similar bulking to bpf_redirect_map().","xdp_redirect bulking performance","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"58aa94f922c1b44e0919d1814d2eab5b9e8bf945","58aa94f922c1b44e0919d1814d2eab5b9e8bf945","Jesper Dangaard Brouer","brouer@redhat.com","1579187686","Alexei Starovoitov","ast@kernel.org","1579233814","7de417a5b4a09f9982d8d29e5f3da95299b501bb","1d233886dd904edbf239eeffe435c3308ae97625","devmap: Adjust tracepoint for map-less queue flush Now that we don't have a reference to a devmap when flushing the device bulk queue, let's change the the devmap_xmit tracepoint to remote the map_id and map_index fields entirely. Rearrange the fields so 'drops' and 'sent' stay in the same position in the tracepoint struct, to make it possible for the xdp_monitor utility to read both the old and the new format. Signed-off-by: Jesper Dangaard Brouer Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/157918768613.1458396.9165902403373826572.stgit@toke.dk","include/trace/events/xdp.h | 29 ++++++++++++-----------------; kernel/bpf/devmap.c | 2 +-; samples/bpf/xdp_monitor_kern.c | 8 +++-----; 3 files changed, 16 insertions(+), 23 deletions(-)","The commit refactors the devmap_xmit tracepoint by removing map_id and map_index fields for compatibility across formats.","devmap,tracepoint,refactor","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime."", ""I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear.""]" +"1d233886dd904edbf239eeffe435c3308ae97625","1d233886dd904edbf239eeffe435c3308ae97625","Toke Høiland-Jørgensen","toke@redhat.com","1579187685","Alexei Starovoitov","ast@kernel.org","1579233814","474882b8ddb9584fa8fcf23a0b7598b397c14dc8","75ccae62cb8d42a619323a85c577107b8b37d797","xdp: Use bulking for non-map XDP_REDIRECT and consolidate code paths Since the bulk queue used by XDP_REDIRECT now lives in struct net_device, we can re-use the bulking for the non-map version of the bpf_redirect() helper. This is a simple matter of having xdp_do_redirect_slow() queue the frame on the bulk queue instead of sending it out with __bpf_tx_xdp(). Unfortunately we can't make the bpf_redirect() helper return an error if the ifindex doesn't exit (as bpf_redirect_map() does), because we don't have a reference to the network namespace of the ingress device at the time the helper is called. So we have to leave it as-is and keep the device lookup in xdp_do_redirect_slow(). Since this leaves less reason to have the non-map redirect code in a separate function, so we get rid of the xdp_do_redirect_slow() function entirely. This does lose us the tracepoint disambiguation, but fortunately the xdp_redirect and xdp_redirect_map tracepoints use the same tracepoint entry structures. This means both can contain a map index, so we can just amend the tracepoint definitions so we always emit the xdp_redirect(_err) tracepoints, but with the map ID only populated if a map is present. This means we retire the xdp_redirect_map(_err) tracepoints entirely, but keep the definitions around in case someone is still listening for them. With this change, the performance of the xdp_redirect sample program goes from 5Mpps to 8.4Mpps (a 68% increase). Since the flush functions are no longer map-specific, rename the flush() functions to drop _map from their names. One of the renamed functions is the xdp_do_flush_map() callback used in all the xdp-enabled drivers. To keep from having to update all drivers, use a #define to keep the old name working, and only update the virtual drivers in this patch. Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/157918768505.1458396.17518057312953572912.stgit@toke.dk","drivers/net/tun.c | 4 +-; drivers/net/veth.c | 2 +-; drivers/net/virtio_net.c | 2 +-; include/linux/bpf.h | 13 +++++-; include/linux/filter.h | 10 ++++-; include/trace/events/xdp.h | 101 ++++++++++++++++++++-------------------------; kernel/bpf/devmap.c | 32 +++++++++-----; net/core/filter.c | 90 +++++++++-------------------------------; 8 files changed, 108 insertions(+), 146 deletions(-)","This commit optimizes non-map XDP_REDIRECT by consolidating code paths and increasing performance using bulk queuing.","XDP_REDIRECT,bulking,performance","A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.']" +"75ccae62cb8d42a619323a85c577107b8b37d797","75ccae62cb8d42a619323a85c577107b8b37d797","Toke Høiland-Jørgensen","toke@redhat.com","1579187684","Alexei Starovoitov","ast@kernel.org","1579233814","bdddfb969966af6ac0386a00ccf7341cb2dfb247","20f21d98cf12b8ecd69e8defc93fae9e3b353b13","xdp: Move devmap bulk queue into struct net_device Commit 96360004b862 (""xdp: Make devmap flush_list common for all map instances""), changed devmap flushing to be a global operation instead of a per-map operation. However, the queue structure used for bulking was still allocated as part of the containing map. This patch moves the devmap bulk queue into struct net_device. The motivation for this is reusing it for the non-map variant of XDP_REDIRECT, which will be changed in a subsequent commit. To avoid other fields of struct net_device moving to different cache lines, we also move a couple of other members around. We defer the actual allocation of the bulk queue structure until the NETDEV_REGISTER notification devmap.c. This makes it possible to check for ndo_xdp_xmit support before allocating the structure, which is not possible at the time struct net_device is allocated. However, we keep the freeing in free_netdev() to avoid adding another RCU callback on NETDEV_UNREGISTER. Because of this change, we lose the reference back to the map that originated the redirect, so change the tracepoint to always return 0 as the map ID and index. Otherwise no functional change is intended with this patch. After this patch, the relevant part of struct net_device looks like this, according to pahole: /* --- cacheline 14 boundary (896 bytes) --- */ struct netdev_queue * _tx __attribute__((__aligned__(64))); /* 896 8 */ unsigned int num_tx_queues; /* 904 4 */ unsigned int real_num_tx_queues; /* 908 4 */ struct Qdisc * qdisc; /* 912 8 */ unsigned int tx_queue_len; /* 920 4 */ spinlock_t tx_global_lock; /* 924 4 */ struct xdp_dev_bulk_queue * xdp_bulkq; /* 928 8 */ struct xps_dev_maps * xps_cpus_map; /* 936 8 */ struct xps_dev_maps * xps_rxqs_map; /* 944 8 */ struct mini_Qdisc * miniq_egress; /* 952 8 */ /* --- cacheline 15 boundary (960 bytes) --- */ struct hlist_head qdisc_hash[16]; /* 960 128 */ /* --- cacheline 17 boundary (1088 bytes) --- */ struct timer_list watchdog_timer; /* 1088 40 */ /* XXX last struct has 4 bytes of padding */ int watchdog_timeo; /* 1128 4 */ /* XXX 4 bytes hole, try to pack */ struct list_head todo_list; /* 1136 16 */ /* --- cacheline 18 boundary (1152 bytes) --- */ Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Acked-by: Björn Töpel Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/157918768397.1458396.12673224324627072349.stgit@toke.dk","include/linux/netdevice.h | 13 ++++++----; include/trace/events/xdp.h | 2 +-; kernel/bpf/devmap.c | 63 ++++++++++++++++++++--------------------------; net/core/dev.c | 2 ++; 4 files changed, 38 insertions(+), 42 deletions(-)","The devmap bulk queue is relocated into struct net_device to facilitate improvements in XDP_REDIRECT functionality.","devmap, net_device, XDP_REDIRECT","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"20f21d98cf12b8ecd69e8defc93fae9e3b353b13","20f21d98cf12b8ecd69e8defc93fae9e3b353b13","Andrii Nakryiko","andriin@fb.com","1579221662","Alexei Starovoitov","ast@kernel.org","1579233693","7ad830cc914d26d254a5c6830609c2cca9c33c01","35697c12d7ffd31a56d3c9604066a166b75d0169","libbpf: Revert bpf_helper_defs.h inclusion regression Revert bpf_helpers.h's change to include auto-generated bpf_helper_defs.h through <> instead of """", which causes it to be searched in include path. This can break existing applications that don't have their include path pointing directly to where libbpf installs its headers. There is ongoing work to make all (not just bpf_helper_defs.h) includes more consistent across libbpf and its consumers, but this unbreaks user code as is right now without any regressions. Selftests still behave sub-optimally (taking bpf_helper_defs.h from libbpf's source directory, if it's present there), which will be fixed in subsequent patches. Fixes: 6910d7d3867a (""selftests/bpf: Ensure bpf_helper_defs.h are taken from selftests dir"") Reported-by: Toke Høiland-Jørgensen Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200117004103.148068-1-andriin@fb.com","tools/lib/bpf/bpf_helpers.h | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","Reverts a header inclusion method in libbpf to prevent application breakage due to path issues.","revert, libbpf, include","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"35697c12d7ffd31a56d3c9604066a166b75d0169","35697c12d7ffd31a56d3c9604066a166b75d0169","Yonghong Song","yhs@fb.com","1579196404","Alexei Starovoitov","ast@kernel.org","1579210137","959a081af0c6533335d84f7615b1911fd1911f09","858e284f0ec18bff2620d9a6afe764dc683f8ba1","selftests/bpf: Fix test_progs send_signal flakiness with nmi mode Alexei observed that test_progs send_signal may fail if run with command line ""./test_progs"" and the tests will pass if just run ""./test_progs -n 40"". I observed similar issue with nmi subtest failure and added a delay 100 us in Commit ab8b7f0cb358 (""tools/bpf: Add self tests for bpf_send_signal_thread()"") and the problem is gone for me. But the issue still exists in Alexei's testing environment. The current code uses sample_freq = 50 (50 events/second), which may not be enough. But if the sample_freq value is larger than sysctl kernel/perf_event_max_sample_rate, the perf_event_open syscall will fail. This patch changed nmi perf testing to use sample_period = 1, which means trying to sampling every event. This seems fixing the issue. Fixes: ab8b7f0cb358 (""tools/bpf: Add self tests for bpf_send_signal_thread()"") Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200116174004.1522812-1-yhs@fb.com","tools/testing/selftests/bpf/prog_tests/send_signal.c | 6 +-----; 1 file changed, 1 insertion(+), 5 deletions(-)","The commit resolves flakiness in bpf selftests by adjusting the sampling period for send_signal tests in nmi mode.","selftests,bpf,flakiness","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"858e284f0ec18bff2620d9a6afe764dc683f8ba1","858e284f0ec18bff2620d9a6afe764dc683f8ba1","Brian Vazquez","brianvv@google.com","1579150758","Daniel Borkmann","daniel@iogearbox.net","1579185112","9c1d6041039aa75e86bbb74638aa007f51cb9f07","b65053cd94f46619b4aae746b98f2d8d9274540e","libbpf: Fix unneeded extra initialization in bpf_map_batch_common bpf_attr doesn't required to be declared with '= {}' as memset is used in the code. Fixes: 2ab3d86ea1859 (""libbpf: Add libbpf support to batch ops"") Reported-by: Andrii Nakryiko Signed-off-by: Brian Vazquez Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200116045918.75597-1-brianvv@google.com","tools/lib/bpf/bpf.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","This commit removes unnecessary initialization in libbpf's bpf_map_batch_common function.","libbpf,initialization,bpf_map_batch_common","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"3981f955eb27fd4f52b8cef198091530811229f2","3981f955eb27fd4f52b8cef198091530811229f2","David S. Miller","davem@davemloft.net","1579165480","David S. Miller","davem@davemloft.net","1579165480","5e85999c1a8c4a7ee73f025ffef47f649312a8dc","567110f147b352020138573a90476a1522210f62 85ddd9c3173102930c16b0cfe8dbb771af434532","Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf Daniel Borkmann says: ==================== pull-request: bpf 2020-01-15 The following pull-request contains BPF updates for your *net* tree. We've added 12 non-merge commits during the last 9 day(s) which contain a total of 13 files changed, 95 insertions(+), 43 deletions(-). The main changes are: 1) Fix refcount leak for TCP time wait and request sockets for socket lookup related BPF helpers, from Lorenz Bauer. 2) Fix wrong verification of ARSH instruction under ALU32, from Daniel Borkmann. 3) Batch of several sockmap and related TLS fixes found while operating more complex BPF programs with Cilium and OpenSSL, from John Fastabend. 4) Fix sockmap to read psock's ingress_msg queue before regular sk_receive_queue() to avoid purging data upon teardown, from Lingpeng Chen. 5) Fix printing incorrect pointer in bpftool's btf_dump_ptr() in order to properly dump a BPF map's value with BTF, from Martin KaFai Lau. ==================== Signed-off-by: David S. Miller ","","This commit merges various BPF updates with multiple bug fixes and improvements.","BPF, fixes, updates","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"b65053cd94f46619b4aae746b98f2d8d9274540e","b65053cd94f46619b4aae746b98f2d8d9274540e","Andrii Nakryiko","andriin@fb.com","1579136149","Alexei Starovoitov","ast@kernel.org","1579142319","9f16ab6aeeefd8d7645ed479e76d4e53b6ecf744","7bcfea9615f60506e6573e35bb7596f776640509","selftests/bpf: Add whitelist/blacklist of test names to test_progs Add ability to specify a list of test name substrings for selecting which tests to run. So now -t is accepting a comma-separated list of strings, similarly to how -n accepts a comma-separated list of test numbers. Additionally, add ability to blacklist tests by name. Blacklist takes precedence over whitelist. Blacklisting is important for cases where it's known that some tests can't pass (e.g., due to perf hardware events that are not available within VM). This is going to be used for libbpf testing in Travis CI in its Github repo. Example runs with just whitelist and whitelist + blacklist: $ sudo ./test_progs -tattach,core/existence #1 attach_probe:OK #6 cgroup_attach_autodetach:OK #7 cgroup_attach_multi:OK #8 cgroup_attach_override:OK #9 core_extern:OK #10/44 existence:OK #10/45 existence___minimal:OK #10/46 existence__err_int_sz:OK #10/47 existence__err_int_type:OK #10/48 existence__err_int_kind:OK #10/49 existence__err_arr_kind:OK #10/50 existence__err_arr_value_type:OK #10/51 existence__err_struct_type:OK #10 core_reloc:OK #19 flow_dissector_reattach:OK #60 tp_attach_query:OK Summary: 8/8 PASSED, 0 SKIPPED, 0 FAILED $ sudo ./test_progs -tattach,core/existence -bcgroup,flow/arr #1 attach_probe:OK #9 core_extern:OK #10/44 existence:OK #10/45 existence___minimal:OK #10/46 existence__err_int_sz:OK #10/47 existence__err_int_type:OK #10/48 existence__err_int_kind:OK #10/51 existence__err_struct_type:OK #10 core_reloc:OK #60 tp_attach_query:OK Summary: 4/6 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Cc: Julia Kartseva Link: https://lore.kernel.org/bpf/20200116005549.3644118-1-andriin@fb.com","tools/testing/selftests/bpf/test_progs.c | 83 ++++++++++++++++++++++++++++----; tools/testing/selftests/bpf/test_progs.h | 8 ++-; 2 files changed, 80 insertions(+), 11 deletions(-)","The commit enhances test infrastructure by adding whitelist and blacklist capabilities for selecting specific test names in test_progs.","whitelist,blacklist,tests","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"7bcfea9615f60506e6573e35bb7596f776640509","7bcfea9615f60506e6573e35bb7596f776640509","Alexei Starovoitov","ast@kernel.org","1579130608","Alexei Starovoitov","ast@kernel.org","1579130657","dc987dca94677c0e814dc195fc76dba0ca1e446f","990bca1fc8ad48f7f8b0786b739a9408017b7a74 4e1ea33292ff2ea0a82f52b2600abb4aba752094","Merge branch 'bpftool-improvements' Martin Lau says: ==================== When a map is storing a kernel's struct, its map_info->btf_vmlinux_value_type_id is set. The first map type supporting it is BPF_MAP_TYPE_STRUCT_OPS. This series adds support to dump this kind of map with BTF. The first two patches are bug fixes which are only applicable to bpf-next. Please see individual patches for details. v3: - Remove unnecessary #include ""libbpf_internal.h"" from patch 5 v2: - Expose bpf_find_kernel_btf() as a LIBBPF_API in patch 3 (Andrii) - Cache btf_vmlinux in bpftool/map.c (Andrii) ==================== Signed-off-by: Alexei Starovoitov ","","This commit merges branch 'bpftool-improvements', adding features for handling BPF_MAP_TYPE_STRUCT_OPS with BTF.","bpftool,BTF,struct_ops","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"4e1ea33292ff2ea0a82f52b2600abb4aba752094","4e1ea33292ff2ea0a82f52b2600abb4aba752094","Martin KaFai Lau","kafai@fb.com","1579129244","Alexei Starovoitov","ast@kernel.org","1579130607","dc987dca94677c0e814dc195fc76dba0ca1e446f","84c72ceee91c166e19b506d618dbe9df6eacce97","bpftool: Support dumping a map with btf_vmlinux_value_type_id This patch makes bpftool support dumping a map's value properly when the map's value type is a type of the running kernel's btf. (i.e. map_info.btf_vmlinux_value_type_id is set instead of map_info.btf_value_type_id). The first usecase is for the BPF_MAP_TYPE_STRUCT_OPS. Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200115230044.1103008-1-kafai@fb.com","tools/bpf/bpftool/map.c | 61 ++++++++++++++++++++++++++++++++++++++++---------; 1 file changed, 50 insertions(+), 11 deletions(-)","Enhances bpftool for dumping map values using kernel BTF types, focused on BPF_MAP_TYPE_STRUCT_OPS.","bpftool,map,BTF","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","['Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems.']" +"84c72ceee91c166e19b506d618dbe9df6eacce97","84c72ceee91c166e19b506d618dbe9df6eacce97","Martin KaFai Lau","kafai@fb.com","1579129237","Alexei Starovoitov","ast@kernel.org","1579130607","97fa58b29b323a1e179a48d44bd7580d8cb0a9fb","fb2426ad00b136c88d57457504d1e843159a367a","bpftool: Add struct_ops map name This patch adds BPF_MAP_TYPE_STRUCT_OPS to ""struct_ops"" name mapping so that ""bpftool map show"" can print the ""struct_ops"" map type properly. [root@arch-fb-vm1 bpf]# ~/devshare/fb-kernel/linux/tools/bpf/bpftool/bpftool map show id 8 8: struct_ops name dctcp flags 0x0 key 4B value 256B max_entries 1 memlock 4096B btf_id 7 Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200115230037.1102674-1-kafai@fb.com","tools/bpf/bpftool/map.c | 1 +; 1 file changed, 1 insertion(+)","The commit adds support for displaying BPF_MAP_TYPE_STRUCT_OPS map type in bpftool.","bpftool, struct_ops, map","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","['Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems.']" +"fb2426ad00b136c88d57457504d1e843159a367a","fb2426ad00b136c88d57457504d1e843159a367a","Martin KaFai Lau","kafai@fb.com","1579129231","Alexei Starovoitov","ast@kernel.org","1579130607","06f34558985bd683b3b552d20fb9d04c06ebf56f","188a486619e6c9d7b8531ba6c4215b31304d293f","libbpf: Expose bpf_find_kernel_btf as a LIBBPF_API This patch exposes bpf_find_kernel_btf() as a LIBBPF_API. It will be used in 'bpftool map dump' in a following patch to dump a map with btf_vmlinux_value_type_id set. bpf_find_kernel_btf() is renamed to libbpf_find_kernel_btf() and moved to btf.c. As is included, some of the max/min type casting needs to be fixed. Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200115230031.1102305-1-kafai@fb.com","tools/lib/bpf/btf.c | 102 ++++++++++++++++++++++++++++++++++++++++++++---; tools/lib/bpf/btf.h | 2 +; tools/lib/bpf/libbpf.c | 93 ++----------------------------------------; tools/lib/bpf/libbpf.map | 1 +; 4 files changed, 102 insertions(+), 96 deletions(-)","This commit exposes bpf_find_kernel_btf as a LIBBPF_API, renaming and moving the function, and fixing type casting issues.","libbpf, btf, api","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"188a486619e6c9d7b8531ba6c4215b31304d293f","188a486619e6c9d7b8531ba6c4215b31304d293f","Martin KaFai Lau","kafai@fb.com","1579129225","Alexei Starovoitov","ast@kernel.org","1579130607","76c9146803a78148e3a9f31a8b123fec4e95965c","d7de72674af53c3839eff091899f18c221dd30d2","bpftool: Fix missing BTF output for json during map dump The btf availability check is only done for plain text output. It causes the whole BTF output went missing when json_output is used. This patch simplifies the logic a little by avoiding passing ""int btf"" to map_dump(). For plain text output, the btf_wtr is only created when the map has BTF (i.e. info->btf_id != 0). The nullness of ""json_writer_t *wtr"" in map_dump() alone can decide if dumping BTF output is needed. As long as wtr is not NULL, map_dump() will print out the BTF-described data whenever a map has BTF available (i.e. info->btf_id != 0) regardless of json or plain-text output. In do_dump(), the ""int btf"" is also renamed to ""int do_plain_btf"". Fixes: 99f9863a0c45 (""bpftool: Match maps by name"") Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Cc: Paul Chaignon Link: https://lore.kernel.org/bpf/20200115230025.1101828-1-kafai@fb.com","tools/bpf/bpftool/map.c | 42 ++++++++++++++++++++----------------------; 1 file changed, 20 insertions(+), 22 deletions(-)","Fix missing BTF output in JSON format during map dumps in bpftool.","BTF, JSON, bpftool","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"d7de72674af53c3839eff091899f18c221dd30d2","d7de72674af53c3839eff091899f18c221dd30d2","Martin KaFai Lau","kafai@fb.com","1579129219","Alexei Starovoitov","ast@kernel.org","1579130607","159843e4663abd55fb9170ea1bd833bf1ba64dcb","990bca1fc8ad48f7f8b0786b739a9408017b7a74","bpftool: Fix a leak of btf object When testing a map has btf or not, maps_have_btf() tests it by actually getting a btf_fd from sys_bpf(BPF_BTF_GET_FD_BY_ID). However, it forgot to btf__free() it. In maps_have_btf() stage, there is no need to test it by really calling sys_bpf(BPF_BTF_GET_FD_BY_ID). Testing non zero info.btf_id is good enough. Also, the err_close case is unnecessary, and also causes double close() because the calling func do_dump() will close() all fds again. Fixes: 99f9863a0c45 (""bpftool: Match maps by name"") Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Cc: Paul Chaignon Link: https://lore.kernel.org/bpf/20200115230019.1101352-1-kafai@fb.com","tools/bpf/bpftool/map.c | 16 ++--------------; 1 file changed, 2 insertions(+), 14 deletions(-)","The commit fixes a memory leak in bpftool related to handling BTF objects during map operations.","bpftool,BTF,memory","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"85ddd9c3173102930c16b0cfe8dbb771af434532","85ddd9c3173102930c16b0cfe8dbb771af434532","Daniel Borkmann","daniel@iogearbox.net","1579127174","Daniel Borkmann","daniel@iogearbox.net","1579127183","bf73100781a6b1416cb714f3d72321f247bf44ea","0af2ffc93a4b50948f9dad2786b7f1bd253bf0b9 7361d44896ff20d48bdd502d1a0cd66308055d45","Merge branch 'bpf-sockmap-tls-fixes' John Fastabend says: ==================== To date our usage of sockmap/tls has been fairly simple, the BPF programs did only well-defined pop, push, pull and apply/cork operations. Now that we started to push more complex programs into sockmap we uncovered a series of issues addressed here. Further OpenSSL3.0 version should be released soon with kTLS support so its important to get any remaining issues on BPF and kTLS support resolved. Additionally, I have a patch under development to allow sockmap to be enabled/disabled at runtime for Cilium endpoints. This allows us to stress the map insert/delete with kTLS more than previously where Cilium only added the socket to the map when it entered ESTABLISHED state and never touched it from the control path side again relying on the sockets own close() hook to remove it. To test I have a set of test cases in test_sockmap.c that expose these issues. Once we get fixes here merged and in bpf-next I'll submit the tests to bpf-next tree to ensure we don't regress again. Also I've run these patches in the Cilium CI with OpenSSL (master branch) this will run tools such as netperf, ab, wrk2, curl, etc. to get a broad set of testing. I'm aware of two more issues that we are working to resolve in another couple (probably two) patches. First we see an auth tag corruption in kTLS when sending small 1byte chunks under stress. I've not pinned this down yet. But, guessing because its under 1B stress tests it must be some error path being triggered. And second we need to ensure BPF RX programs are not skipped when kTLS ULP is loaded. This breaks some of the sockmap selftests when running with kTLS. I'll send a follow up for this. v2: I dropped a patch that added !0 size check in tls_push_record this originated from a panic I caught awhile ago with a trace in the crypto stack. But I can not reproduce it anymore so will dig into that and send another patch later if needed. Anyways after a bit of thought it would be nicer if tls/crypto/bpf didn't require special case handling for the !0 size. ==================== Signed-off-by: Daniel Borkmann ","","This commit merges branch 'bpf-sockmap-tls-fixes' to address BPF program issues in sockmap for enhanced kTLS support.","sockmap, kTLS, BPF","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.', ""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"7361d44896ff20d48bdd502d1a0cd66308055d45","7361d44896ff20d48bdd502d1a0cd66308055d45","John Fastabend","john.fastabend@gmail.com","1578723126","Daniel Borkmann","daniel@iogearbox.net","1579127173","bf73100781a6b1416cb714f3d72321f247bf44ea","9aaaa56845a06aeabdd597cbe19492dc01f281ec","bpf: Sockmap/tls, fix pop data with SK_DROP return code When user returns SK_DROP we need to reset the number of copied bytes to indicate to the user the bytes were dropped and not sent. If we don't reset the copied arg sendmsg will return as if those bytes were copied giving the user a positive return value. This works as expected today except in the case where the user also pops bytes. In the pop case the sg.size is reduced but we don't correctly account for this when copied bytes is reset. The popped bytes are not accounted for and we return a small positive value potentially confusing the user. The reason this happens is due to a typo where we do the wrong comparison when accounting for pop bytes. In this fix notice the if/else is not needed and that we have a similar problem if we push data except its not visible to the user because if delta is larger the sg.size we return a negative value so it appears as an error regardless. Fixes: 7246d8ed4dcce (""bpf: helper to pop data from messages"") Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Acked-by: Jonathan Lemon Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20200111061206.8028-9-john.fastabend@gmail.com","net/ipv4/tcp_bpf.c | 5 +----; net/tls/tls_sw.c | 5 +----; 2 files changed, 2 insertions(+), 8 deletions(-)","The commit fixes popping data handling in Sockmap/tls when the SK_DROP return code is used by resetting copied byte counts.","Sockmap,tls,SK_DROP","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"9aaaa56845a06aeabdd597cbe19492dc01f281ec","9aaaa56845a06aeabdd597cbe19492dc01f281ec","John Fastabend","john.fastabend@gmail.com","1578723125","Daniel Borkmann","daniel@iogearbox.net","1579127173","b2a5824d2c4f49e095b913aff1b19de29a79d72f","d468e4775c1c351616947ba0cccc43273963b9b5","bpf: Sockmap/tls, skmsg can have wrapped skmsg that needs extra chaining Its possible through a set of push, pop, apply helper calls to construct a skmsg, which is just a ring of scatterlist elements, with the start value larger than the end value. For example, end start |_0_|_1_| ... |_n_|_n+1_| Where end points at 1 and start points and n so that valid elements is the set {n, n+1, 0, 1}. Currently, because we don't build the correct chain only {n, n+1} will be sent. This adds a check and sg_chain call to correctly submit the above to the crypto and tls send path. Fixes: d3b18ad31f93d (""tls: add bpf support to sk_msg handling"") Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Acked-by: Jonathan Lemon Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20200111061206.8028-8-john.fastabend@gmail.com","net/tls/tls_sw.c | 6 ++++++; 1 file changed, 6 insertions(+)","Fixes a skmsg chaining issue in sockmap/tls to ensure proper handling of wrapped skmsg for crypto and TLS send paths.","skmsg,chaining,tls","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.', ""It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here.""]" +"d468e4775c1c351616947ba0cccc43273963b9b5","d468e4775c1c351616947ba0cccc43273963b9b5","John Fastabend","john.fastabend@gmail.com","1578723124","Daniel Borkmann","daniel@iogearbox.net","1579127173","5cd6d430f80dbb320da7033fee90694ed9054bf2","cf21e9ba1eb86c9333ca5b05b2f1cc94021bcaef","bpf: Sockmap/tls, tls_sw can create a plaintext buf > encrypt buf It is possible to build a plaintext buffer using push helper that is larger than the allocated encrypt buffer. When this record is pushed to crypto layers this can result in a NULL pointer dereference because the crypto API expects the encrypt buffer is large enough to fit the plaintext buffer. Kernel splat below. To resolve catch the cases this can happen and split the buffer into two records to send individually. Unfortunately, there is still one case to handle where the split creates a zero sized buffer. In this case we merge the buffers and unmark the split. This happens when apply is zero and user pushed data beyond encrypt buffer. This fixes the original case as well because the split allocated an encrypt buffer larger than the plaintext buffer and the merge simply moves the pointers around so we now have a reference to the new (larger) encrypt buffer. Perhaps its not ideal but it seems the best solution for a fixes branch and avoids handling these two cases, (a) apply that needs split and (b) non apply case. The are edge cases anyways so optimizing them seems not necessary unless someone wants later in next branches. [ 306.719107] BUG: kernel NULL pointer dereference, address: 0000000000000008 [...] [ 306.747260] RIP: 0010:scatterwalk_copychunks+0x12f/0x1b0 [...] [ 306.770350] Call Trace: [ 306.770956] scatterwalk_map_and_copy+0x6c/0x80 [ 306.772026] gcm_enc_copy_hash+0x4b/0x50 [ 306.772925] gcm_hash_crypt_remain_continue+0xef/0x110 [ 306.774138] gcm_hash_crypt_continue+0xa1/0xb0 [ 306.775103] ? gcm_hash_crypt_continue+0xa1/0xb0 [ 306.776103] gcm_hash_assoc_remain_continue+0x94/0xa0 [ 306.777170] gcm_hash_assoc_continue+0x9d/0xb0 [ 306.778239] gcm_hash_init_continue+0x8f/0xa0 [ 306.779121] gcm_hash+0x73/0x80 [ 306.779762] gcm_encrypt_continue+0x6d/0x80 [ 306.780582] crypto_gcm_encrypt+0xcb/0xe0 [ 306.781474] crypto_aead_encrypt+0x1f/0x30 [ 306.782353] tls_push_record+0x3b9/0xb20 [tls] [ 306.783314] ? sk_psock_msg_verdict+0x199/0x300 [ 306.784287] bpf_exec_tx_verdict+0x3f2/0x680 [tls] [ 306.785357] tls_sw_sendmsg+0x4a3/0x6a0 [tls] test_sockmap test signature to trigger bug, [TEST]: (1, 1, 1, sendmsg, pass,redir,start 1,end 2,pop (1,2),ktls,): Fixes: d3b18ad31f93d (""tls: add bpf support to sk_msg handling"") Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Acked-by: Jonathan Lemon Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20200111061206.8028-7-john.fastabend@gmail.com","net/tls/tls_sw.c | 20 ++++++++++++++++++++; 1 file changed, 20 insertions(+)","The commit resolves a bug causing NULL pointer dereference in sockmap/tls by handling buffer splitting issues during encryption.","tls,plaintext,bug","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.","It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"cf21e9ba1eb86c9333ca5b05b2f1cc94021bcaef","cf21e9ba1eb86c9333ca5b05b2f1cc94021bcaef","John Fastabend","john.fastabend@gmail.com","1578723123","Daniel Borkmann","daniel@iogearbox.net","1579127173","b2010fdecca8c5ea9f0078a7725ca5ac0e285f45","6562e29cf6f0ddd368657d97a8d484ffc30df5ef","bpf: Sockmap/tls, msg_push_data may leave end mark in place Leaving an incorrect end mark in place when passing to crypto layer will cause crypto layer to stop processing data before all data is encrypted. To fix clear the end mark on push data instead of expecting users of the helper to clear the mark value after the fact. This happens when we push data into the middle of a skmsg and have room for it so we don't do a set of copies that already clear the end flag. Fixes: 6fff607e2f14b (""bpf: sk_msg program helper bpf_msg_push_data"") Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Acked-by: Song Liu Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20200111061206.8028-6-john.fastabend@gmail.com","net/core/filter.c | 1 +; 1 file changed, 1 insertion(+)","Fixes a bug where the bpf_msg_push_data helper leaves an end mark affecting data encryption in socket messaging.","bug,msg_push_data,tls","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"6562e29cf6f0ddd368657d97a8d484ffc30df5ef","6562e29cf6f0ddd368657d97a8d484ffc30df5ef","John Fastabend","john.fastabend@gmail.com","1578723122","Daniel Borkmann","daniel@iogearbox.net","1579127173","0e79287aa56874db12b7a7dff266d0cab47c067f","33bfe20dd7117dd81fd896a53f743a233e1ad64f","bpf: Sockmap, skmsg helper overestimates push, pull, and pop bounds In the push, pull, and pop helpers operating on skmsg objects to make data writable or insert/remove data we use this bounds check to ensure specified data is valid, /* Bounds checks: start and pop must be inside message */ if (start >= offset + l || last >= msg->sg.size) return -EINVAL; The problem here is offset has already included the length of the current element the 'l' above. So start could be past the end of the scatterlist element in the case where start also points into an offset on the last skmsg element. To fix do the accounting slightly different by adding the length of the previous entry to offset at the start of the iteration. And ensure its initialized to zero so that the first iteration does nothing. Fixes: 604326b41a6fb (""bpf, sockmap: convert to generic sk_msg interface"") Fixes: 6fff607e2f14b (""bpf: sk_msg program helper bpf_msg_push_data"") Fixes: 7246d8ed4dcce (""bpf: helper to pop data from messages"") Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Acked-by: Song Liu Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20200111061206.8028-5-john.fastabend@gmail.com","net/core/filter.c | 10 +++++-----; 1 file changed, 5 insertions(+), 5 deletions(-)","The commit fixes an overestimation issue in skmsg helper bounds checks for push, pull, and pop operations in eBPF socket maps.","skmsg,bounds,helper","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"33bfe20dd7117dd81fd896a53f743a233e1ad64f","33bfe20dd7117dd81fd896a53f743a233e1ad64f","John Fastabend","john.fastabend@gmail.com","1578723121","Daniel Borkmann","daniel@iogearbox.net","1579127173","441203009c7ea09d634127efe18c3f029335230b","7e81a35302066c5a00b4c72d83e3ea4cad6eeb5b","bpf: Sockmap/tls, push write_space updates through ulp updates When sockmap sock with TLS enabled is removed we cleanup bpf/psock state and call tcp_update_ulp() to push updates to TLS ULP on top. However, we don't push the write_space callback up and instead simply overwrite the op with the psock stored previous op. This may or may not be correct so to ensure we don't overwrite the TLS write space hook pass this field to the ULP and have it fixup the ctx. This completes a previous fix that pushed the ops through to the ULP but at the time missed doing this for write_space, presumably because write_space TLS hook was added around the same time. Fixes: 95fa145479fbc (""bpf: sockmap/tls, close can race with map free"") Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Sitnicki Acked-by: Jonathan Lemon Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20200111061206.8028-4-john.fastabend@gmail.com","include/linux/skmsg.h | 12 ++++++++----; include/net/tcp.h | 6 ++++--; net/ipv4/tcp_ulp.c | 6 ++++--; net/tls/tls_main.c | 10 +++++++---; 4 files changed, 23 insertions(+), 11 deletions(-)","The commit ensures proper handling of the write_space callback during sockmap sock removal when TLS is enabled by updating the ULP context.","write_space, sockmap, TLS","A bug fix. It primarily resolves a bug or issue in the code.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.', ""It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here."", ""I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear.""]" +"7e81a35302066c5a00b4c72d83e3ea4cad6eeb5b","7e81a35302066c5a00b4c72d83e3ea4cad6eeb5b","John Fastabend","john.fastabend@gmail.com","1578723120","Daniel Borkmann","daniel@iogearbox.net","1579127173","127cb0e256fababbd078524456655627e6be4072","4da6a196f93b1af7612340e8c1ad8ce71e18f955","bpf: Sockmap, ensure sock lock held during tear down The sock_map_free() and sock_hash_free() paths used to delete sockmap and sockhash maps walk the maps and destroy psock and bpf state associated with the socks in the map. When done the socks no longer have BPF programs attached and will function normally. This can happen while the socks in the map are still ""live"" meaning data may be sent/received during the walk. Currently, though we don't take the sock_lock when the psock and bpf state is removed through this path. Specifically, this means we can be writing into the ops structure pointers such as sendmsg, sendpage, recvmsg, etc. while they are also being called from the networking side. This is not safe, we never used proper READ_ONCE/WRITE_ONCE semantics here if we believed it was safe. Further its not clear to me its even a good idea to try and do this on ""live"" sockets while networking side might also be using the socket. Instead of trying to reason about using the socks from both sides lets realize that every use case I'm aware of rarely deletes maps, in fact kubernetes/Cilium case builds map at init and never tears it down except on errors. So lets do the simple fix and grab sock lock. This patch wraps sock deletes from maps in sock lock and adds some annotations so we catch any other cases easier. Fixes: 604326b41a6fb (""bpf, sockmap: convert to generic sk_msg interface"") Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Acked-by: Song Liu Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20200111061206.8028-3-john.fastabend@gmail.com","net/core/skmsg.c | 2 ++; net/core/sock_map.c | 7 ++++++-; 2 files changed, 8 insertions(+), 1 deletion(-)","The commit ensures thread safety by adding a sock lock during sockmap teardown.","sockmap, lock, teardown","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"4da6a196f93b1af7612340e8c1ad8ce71e18f955","4da6a196f93b1af7612340e8c1ad8ce71e18f955","John Fastabend","john.fastabend@gmail.com","1578723119","Daniel Borkmann","daniel@iogearbox.net","1579127173","7766c0d105e2378e59e1fac796bced00d382e767","0af2ffc93a4b50948f9dad2786b7f1bd253bf0b9","bpf: Sockmap/tls, during free we may call tcp_bpf_unhash() in loop When a sockmap is free'd and a socket in the map is enabled with tls we tear down the bpf context on the socket, the psock struct and state, and then call tcp_update_ulp(). The tcp_update_ulp() call is to inform the tls stack it needs to update its saved sock ops so that when the tls socket is later destroyed it doesn't try to call the now destroyed psock hooks. This is about keeping stacked ULPs in good shape so they always have the right set of stacked ops. However, recently unhash() hook was removed from TLS side. But, the sockmap/bpf side is not doing any extra work to update the unhash op when is torn down instead expecting TLS side to manage it. So both TLS and sockmap believe the other side is managing the op and instead no one updates the hook so it continues to point at tcp_bpf_unhash(). When unhash hook is called we call tcp_bpf_unhash() which detects the psock has already been destroyed and calls sk->sk_prot_unhash() which calls tcp_bpf_unhash() yet again and so on looping and hanging the core. To fix have sockmap tear down logic fixup the stale pointer. Fixes: 5d92e631b8be (""net/tls: partially revert fix transition through disconnect with close"") Reported-by: syzbot+83979935eb6304f8cd46@syzkaller.appspotmail.com Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Sitnicki Acked-by: Song Liu Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20200111061206.8028-2-john.fastabend@gmail.com","include/linux/skmsg.h | 1 +; 1 file changed, 1 insertion(+)","The commit fixes a looping issue in sockmap with TLS by correcting unhash hook management.","sockmap,TLS,unhash","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"990bca1fc8ad48f7f8b0786b739a9408017b7a74","990bca1fc8ad48f7f8b0786b739a9408017b7a74","Alexei Starovoitov","ast@kernel.org","1579125636","Alexei Starovoitov","ast@kernel.org","1579126067","961ad3ec3d792a2ea195989729709438de87d127","83e4b88be1ff9671f2a2fb040a09c45cc3fb40e6 f0fac2cec2861abc6fc0c094fb2584d9a33f868d","Merge branch 'bpf-batch-ops' Brian Vazquez says: ==================== This patch series introduce batch ops that can be added to bpf maps to lookup/lookup_and_delete/update/delete more than 1 element at the time, this is specially useful when syscall overhead is a problem and in case of hmap it will provide a reliable way of traversing them. The implementation inclues a generic approach that could potentially be used by any bpf map and adds it to arraymap, it also includes the specific implementation of hashmaps which are traversed using buckets instead of keys. The bpf syscall subcommands introduced are: BPF_MAP_LOOKUP_BATCH BPF_MAP_LOOKUP_AND_DELETE_BATCH BPF_MAP_UPDATE_BATCH BPF_MAP_DELETE_BATCH The UAPI attribute is: struct { /* struct used by BPF_MAP_*_BATCH commands */ __aligned_u64 in_batch; /* start batch, * NULL to start from beginning */ __aligned_u64 out_batch; /* output: next start batch */ __aligned_u64 keys; __aligned_u64 values; __u32 count; /* input/output: * input: # of key/value * elements * output: # of filled elements */ __u32 map_fd; __u64 elem_flags; __u64 flags; } batch; in_batch and out_batch are only used for lookup and lookup_and_delete since those are the only two operations that attempt to traverse the map. update/delete batch ops should provide the keys/values that user wants to modify. Here are the previous discussions on the batch processing: - https://lore.kernel.org/bpf/20190724165803.87470-1-brianvv@google.com/ - https://lore.kernel.org/bpf/20190829064502.2750303-1-yhs@fb.com/ - https://lore.kernel.org/bpf/20190906225434.3635421-1-yhs@fb.com/ Changelog sinve v4: - Remove unnecessary checks from libbpf API (Andrii Nakryiko) - Move DECLARE_LIBBPF_OPTS with all var declarations (Andrii Nakryiko) - Change bucket internal buffer size to 5 entries (Yonghong Song) - Fix some minor bugs in hashtab batch ops implementation (Yonghong Song) Changelog sinve v3: - Do not use copy_to_user inside atomic region (Yonghong Song) - Use _opts approach on libbpf APIs (Andrii Nakryiko) - Drop generic_map_lookup_and_delete_batch support - Free malloc-ed memory in tests (Yonghong Song) - Reverse christmas tree (Yonghong Song) - Add acked labels Changelog sinve v2: - Add generic batch support for lpm_trie and test it (Yonghong Song) - Use define MAP_LOOKUP_RETRIES for retries (John Fastabend) - Return errors directly and remove labels (Yonghong Song) - Insert new API functions into libbpf alphabetically (Yonghong Song) - Change hlist_nulls_for_each_entry_rcu to hlist_nulls_for_each_entry_safe in htab batch ops (Yonghong Song) Changelog since v1: - Fix SOB ordering and remove Co-authored-by tag (Alexei Starovoitov) Changelog since RFC: - Change batch to in_batch and out_batch to support more flexible opaque values to iterate the bpf maps. - Remove update/delete specific batch ops for htab and use the generic implementations instead. ==================== Acked-by: Yonghong Song Signed-off-by: Alexei Starovoitov ","","This commit merges batch operations for BPF maps to reduce syscall overhead and improve traversal efficiency.","batch,bpf,maps","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"f0fac2cec2861abc6fc0c094fb2584d9a33f868d","f0fac2cec2861abc6fc0c094fb2584d9a33f868d","Brian Vazquez","brianvv@google.com","1579113788","Alexei Starovoitov","ast@kernel.org","1579125635","961ad3ec3d792a2ea195989729709438de87d127","30ff3c59137d00e083f68437665e00895cc271c7","selftests/bpf: Add batch ops testing to array bpf map Tested bpf_map_lookup_batch() and bpf_map_update_batch() functionality. $ ./test_maps ... test_array_map_batch_ops:PASS ... Signed-off-by: Brian Vazquez Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200115184308.162644-10-brianvv@google.com",".../selftests/bpf/map_tests/array_map_batch_ops.c | 129 +++++++++++++++++++++; 1 file changed, 129 insertions(+)","The commit adds batch operation tests for array BPF maps in the selftests directory.","selftests,batch,testing","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"30ff3c59137d00e083f68437665e00895cc271c7","30ff3c59137d00e083f68437665e00895cc271c7","Yonghong Song","yhs@fb.com","1579113787","Alexei Starovoitov","ast@kernel.org","1579125635","703775e601e7bdc204bc5560f925cc76c5f7e371","2ab3d86ea1859d1a4b830ce3551cba725620593a","selftests/bpf: Add batch ops testing for htab and htab_percpu map Tested bpf_map_lookup_batch(), bpf_map_lookup_and_delete_batch(), bpf_map_update_batch(), and bpf_map_delete_batch() functionality. $ ./test_maps ... test_htab_map_batch_ops:PASS test_htab_percpu_map_batch_ops:PASS ... Signed-off-by: Yonghong Song Signed-off-by: Brian Vazquez Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200115184308.162644-9-brianvv@google.com",".../selftests/bpf/map_tests/htab_map_batch_ops.c | 283 +++++++++++++++++++++; 1 file changed, 283 insertions(+)","This commit introduces tests for batch operations on htab and htab_percpu maps in eBPF selftests.","batch, htab, testing","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"2ab3d86ea1859d1a4b830ce3551cba725620593a","2ab3d86ea1859d1a4b830ce3551cba725620593a","Yonghong Song","yhs@fb.com","1579113786","Alexei Starovoitov","ast@kernel.org","1579125635","0cd83172075796074ac3c27f58ba14e7c3f0ff7e","a1e3a3b8ba2c381a043d0c4273837895c1d3cf9c","libbpf: Add libbpf support to batch ops Added four libbpf API functions to support map batch operations: . int bpf_map_delete_batch( ... ) . int bpf_map_lookup_batch( ... ) . int bpf_map_lookup_and_delete_batch( ... ) . int bpf_map_update_batch( ... ) Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200115184308.162644-8-brianvv@google.com","tools/lib/bpf/bpf.c | 58 ++++++++++++++++++++++++++++++++++++++++++++++++; tools/lib/bpf/bpf.h | 22 ++++++++++++++++++; tools/lib/bpf/libbpf.map | 4 ++++; 3 files changed, 84 insertions(+)","The commit adds batch operation API support to libbpf for map operations.","libbpf,batch,maps","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"a1e3a3b8ba2c381a043d0c4273837895c1d3cf9c","a1e3a3b8ba2c381a043d0c4273837895c1d3cf9c","Yonghong Song","yhs@fb.com","1579113785","Alexei Starovoitov","ast@kernel.org","1579125635","b276e047290d7b36959b6964398f243cd5700171","057996380a42bb64ccc04383cfa9c0ace4ea11f0","tools/bpf: Sync uapi header bpf.h sync uapi header include/uapi/linux/bpf.h to tools/include/uapi/linux/bpf.h Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200115184308.162644-7-brianvv@google.com","tools/include/uapi/linux/bpf.h | 21 +++++++++++++++++++++; 1 file changed, 21 insertions(+)","Synchronize the bpf.h uapi header between kernel and tools directory for consistency.","sync,uapi,header","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"057996380a42bb64ccc04383cfa9c0ace4ea11f0","057996380a42bb64ccc04383cfa9c0ace4ea11f0","Yonghong Song","yhs@fb.com","1579113784","Alexei Starovoitov","ast@kernel.org","1579125635","8cdd6bfa636e365b25f6ddc96c7955fa39254969","c60f2d2861778de6370a4f4ca6ab1d7d4a32efae","bpf: Add batch ops to all htab bpf map htab can't use generic batch support due some problematic behaviours inherent to the data structre, i.e. while iterating the bpf map a concurrent program might delete the next entry that batch was about to use, in that case there's no easy solution to retrieve the next entry, the issue has been discussed multiple times (see [1] and [2]). The only way hmap can be traversed without the problem previously exposed is by making sure that the map is traversing entire buckets. This commit implements those strict requirements for hmap, the implementation follows the same interaction that generic support with some exceptions: - If keys/values buffer are not big enough to traverse a bucket, ENOSPC will be returned. - out_batch contains the value of the next bucket in the iteration, not the next key, but this is transparent for the user since the user should never use out_batch for other than bpf batch syscalls. This commits implements BPF_MAP_LOOKUP_BATCH and adds support for new command BPF_MAP_LOOKUP_AND_DELETE_BATCH. Note that for update/delete batch ops it is possible to use the generic implementations. [1] https://lore.kernel.org/bpf/20190724165803.87470-1-brianvv@google.com/ [2] https://lore.kernel.org/bpf/20190906225434.3635421-1-yhs@fb.com/ Signed-off-by: Yonghong Song Signed-off-by: Brian Vazquez Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200115184308.162644-6-brianvv@google.com","include/linux/bpf.h | 3 +; include/uapi/linux/bpf.h | 1 +; kernel/bpf/hashtab.c | 264 +++++++++++++++++++++++++++++++++++++++++++++++; kernel/bpf/syscall.c | 9 +-; 4 files changed, 276 insertions(+), 1 deletion(-)","This commit introduces batch lookup and delete operations for htab BPF maps to manage concurrent entry iteration.","batch,lookup,htab","A new feature. It adds a new capability or feature that was not previously present.","Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"c60f2d2861778de6370a4f4ca6ab1d7d4a32efae","c60f2d2861778de6370a4f4ca6ab1d7d4a32efae","Brian Vazquez","brianvv@google.com","1579113783","Alexei Starovoitov","ast@kernel.org","1579125635","287e79cef52c774db1fa125a56620d2931e45889","aa2e93b8e58e18442edfb2427446732415bc215e","bpf: Add lookup and update batch ops to arraymap This adds the generic batch ops functionality to bpf arraymap, note that since deletion is not a valid operation for arraymap, only batch and lookup are added. Signed-off-by: Brian Vazquez Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200115184308.162644-5-brianvv@google.com","kernel/bpf/arraymap.c | 2 ++; 1 file changed, 2 insertions(+)","This commit introduces batch lookup and update functionality to bpf arraymaps, excluding deletion operations.","batch,arraymap,operations","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"aa2e93b8e58e18442edfb2427446732415bc215e","aa2e93b8e58e18442edfb2427446732415bc215e","Brian Vazquez","brianvv@google.com","1579113782","Alexei Starovoitov","ast@kernel.org","1579125635","e0d3aa9f1a5e91fc6c9968f961c27a595ae5c4b0","cb4d03ab499d4c040f4ab6fd4389d2b49f42b5a5","bpf: Add generic support for update and delete batch ops This commit adds generic support for update and delete batch ops that can be used for almost all the bpf maps. These commands share the same UAPI attr that lookup and lookup_and_delete batch ops use and the syscall commands are: BPF_MAP_UPDATE_BATCH BPF_MAP_DELETE_BATCH The main difference between update/delete and lookup batch ops is that for update/delete keys/values must be specified for userspace and because of that, neither in_batch nor out_batch are used. Suggested-by: Stanislav Fomichev Signed-off-by: Brian Vazquez Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200115184308.162644-4-brianvv@google.com","include/linux/bpf.h | 10 +++++; include/uapi/linux/bpf.h | 2 +; kernel/bpf/syscall.c | 115 +++++++++++++++++++++++++++++++++++++++++++++++; 3 files changed, 127 insertions(+)","This commit introduces generic support for batch update and delete operations for almost all BPF maps.","batch,update,delete","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"cb4d03ab499d4c040f4ab6fd4389d2b49f42b5a5","cb4d03ab499d4c040f4ab6fd4389d2b49f42b5a5","Brian Vazquez","brianvv@google.com","1579113781","Alexei Starovoitov","ast@kernel.org","1579125635","409289a803a3f328b4b5da43243b4272ec1edde9","15c14a3dca421f086c187155afba3222b879472d","bpf: Add generic support for lookup batch op This commit introduces generic support for the bpf_map_lookup_batch. This implementation can be used by almost all the bpf maps since its core implementation is relying on the existing map_get_next_key and map_lookup_elem. The bpf syscall subcommand introduced is: BPF_MAP_LOOKUP_BATCH The UAPI attribute is: struct { /* struct used by BPF_MAP_*_BATCH commands */ __aligned_u64 in_batch; /* start batch, * NULL to start from beginning */ __aligned_u64 out_batch; /* output: next start batch */ __aligned_u64 keys; __aligned_u64 values; __u32 count; /* input/output: * input: # of key/value * elements * output: # of filled elements */ __u32 map_fd; __u64 elem_flags; __u64 flags; } batch; in_batch/out_batch are opaque values use to communicate between user/kernel space, in_batch/out_batch must be of key_size length. To start iterating from the beginning in_batch must be null, count is the # of key/value elements to retrieve. Note that the 'keys' buffer must be a buffer of key_size * count size and the 'values' buffer must be value_size * count, where value_size must be aligned to 8 bytes by userspace if it's dealing with percpu maps. 'count' will contain the number of keys/values successfully retrieved. Note that 'count' is an input/output variable and it can contain a lower value after a call. If there's no more entries to retrieve, ENOENT will be returned. If error is ENOENT, count might be > 0 in case it copied some values but there were no more entries to retrieve. Note that if the return code is an error and not -EFAULT, count indicates the number of elements successfully processed. Suggested-by: Stanislav Fomichev Signed-off-by: Brian Vazquez Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200115184308.162644-3-brianvv@google.com","include/linux/bpf.h | 5 ++; include/uapi/linux/bpf.h | 18 ++++++; kernel/bpf/syscall.c | 160 +++++++++++++++++++++++++++++++++++++++++++++--; 3 files changed, 179 insertions(+), 4 deletions(-)","This commit adds generic support for batch processing in eBPF maps, introducing the bpf_map_lookup_batch operation.","bpf,map,batch","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The syscall interface. It changes the system calls through which user-space programs interact with eBPF.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"15c14a3dca421f086c187155afba3222b879472d","15c14a3dca421f086c187155afba3222b879472d","Brian Vazquez","brianvv@google.com","1579113780","Alexei Starovoitov","ast@kernel.org","1579125634","cb3253a97afb92ae7d174f4871159bcb8c498bb7","83e4b88be1ff9671f2a2fb040a09c45cc3fb40e6","bpf: Add bpf_map_{value_size, update_value, map_copy_value} functions This commit moves reusable code from map_lookup_elem and map_update_elem to avoid code duplication in kernel/bpf/syscall.c. Signed-off-by: Brian Vazquez Signed-off-by: Alexei Starovoitov Acked-by: John Fastabend Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200115184308.162644-2-brianvv@google.com","kernel/bpf/syscall.c | 280 ++++++++++++++++++++++++++++-----------------------; 1 file changed, 152 insertions(+), 128 deletions(-)","The commit refactors code in kernel/bpf/syscall.c by extracting reusable functions to reduce duplication in bpf map operations.","refactor, bpf_map, syscall","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.","The syscall interface. It changes the system calls through which user-space programs interact with eBPF.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"0af2ffc93a4b50948f9dad2786b7f1bd253bf0b9","0af2ffc93a4b50948f9dad2786b7f1bd253bf0b9","Daniel Borkmann","daniel@iogearbox.net","1579121253","Alexei Starovoitov","ast@kernel.org","1579124399","e84977ed12dbae50801ee5bf91f5052111d5f436","555089fdfc37ad65e0ee9b42ca40c238ff546f83","bpf: Fix incorrect verifier simulation of ARSH under ALU32 Anatoly has been fuzzing with kBdysch harness and reported a hang in one of the outcomes: 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 0: (85) call bpf_get_socket_cookie#46 1: R0_w=invP(id=0) R10=fp0 1: (57) r0 &= 808464432 2: R0_w=invP(id=0,umax_value=808464432,var_off=(0x0; 0x30303030)) R10=fp0 2: (14) w0 -= 810299440 3: R0_w=invP(id=0,umax_value=4294967295,var_off=(0xcf800000; 0x3077fff0)) R10=fp0 3: (c4) w0 s>>= 1 4: R0_w=invP(id=0,umin_value=1740636160,umax_value=2147221496,var_off=(0x67c00000; 0x183bfff8)) R10=fp0 4: (76) if w0 s>= 0x30303030 goto pc+216 221: R0_w=invP(id=0,umin_value=1740636160,umax_value=2147221496,var_off=(0x67c00000; 0x183bfff8)) R10=fp0 221: (95) exit processed 6 insns (limit 1000000) [...] Taking a closer look, the program was xlated as follows: # ./bpftool p d x i 12 0: (85) call bpf_get_socket_cookie#7800896 1: (bf) r6 = r0 2: (57) r6 &= 808464432 3: (14) w6 -= 810299440 4: (c4) w6 s>>= 1 5: (76) if w6 s>= 0x30303030 goto pc+216 6: (05) goto pc-1 7: (05) goto pc-1 8: (05) goto pc-1 [...] 220: (05) goto pc-1 221: (05) goto pc-1 222: (95) exit Meaning, the visible effect is very similar to f54c7898ed1c (""bpf: Fix precision tracking for unbounded scalars""), that is, the fall-through branch in the instruction 5 is considered to be never taken given the conclusion from the min/max bounds tracking in w6, and therefore the dead-code sanitation rewrites it as goto pc-1. However, real-life input disagrees with verification analysis since a soft-lockup was observed. The bug sits in the analysis of the ARSH. The definition is that we shift the target register value right by K bits through shifting in copies of its sign bit. In adjust_scalar_min_max_vals(), we do first coerce the register into 32 bit mode, same happens after simulating the operation. However, for the case of simulating the actual ARSH, we don't take the mode into account and act as if it's always 64 bit, but location of sign bit is different: dst_reg->smin_value >>= umin_val; dst_reg->smax_value >>= umin_val; dst_reg->var_off = tnum_arshift(dst_reg->var_off, umin_val); Consider an unknown R0 where bpf_get_socket_cookie() (or others) would for example return 0xffff. With the above ARSH simulation, we'd see the following results: [...] 1: R1=ctx(id=0,off=0,imm=0) R2_w=invP65535 R10=fp0 1: (85) call bpf_get_socket_cookie#46 2: R0_w=invP(id=0) R10=fp0 2: (57) r0 &= 808464432 -> R0_runtime = 0x3030 3: R0_w=invP(id=0,umax_value=808464432,var_off=(0x0; 0x30303030)) R10=fp0 3: (14) w0 -= 810299440 -> R0_runtime = 0xcfb40000 4: R0_w=invP(id=0,umax_value=4294967295,var_off=(0xcf800000; 0x3077fff0)) R10=fp0 (0xffffffff) 4: (c4) w0 s>>= 1 -> R0_runtime = 0xe7da0000 5: R0_w=invP(id=0,umin_value=1740636160,umax_value=2147221496,var_off=(0x67c00000; 0x183bfff8)) R10=fp0 (0x67c00000) (0x7ffbfff8) [...] In insn 3, we have a runtime value of 0xcfb40000, which is '1100 1111 1011 0100 0000 0000 0000 0000', the result after the shift has 0xe7da0000 that is '1110 0111 1101 1010 0000 0000 0000 0000', where the sign bit is correctly retained in 32 bit mode. In insn4, the umax was 0xffffffff, and changed into 0x7ffbfff8 after the shift, that is, '0111 1111 1111 1011 1111 1111 1111 1000' and means here that the simulation didn't retain the sign bit. With above logic, the updates happen on the 64 bit min/max bounds and given we coerced the register, the sign bits of the bounds are cleared as well, meaning, we need to force the simulation into s32 space for 32 bit alu mode. Verification after the fix below. We're first analyzing the fall-through branch on 32 bit signed >= test eventually leading to rejection of the program in this specific case: 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 0: (b7) r2 = 808464432 1: R1=ctx(id=0,off=0,imm=0) R2_w=invP808464432 R10=fp0 1: (85) call bpf_get_socket_cookie#46 2: R0_w=invP(id=0) R10=fp0 2: (bf) r6 = r0 3: R0_w=invP(id=0) R6_w=invP(id=0) R10=fp0 3: (57) r6 &= 808464432 4: R0_w=invP(id=0) R6_w=invP(id=0,umax_value=808464432,var_off=(0x0; 0x30303030)) R10=fp0 4: (14) w6 -= 810299440 5: R0_w=invP(id=0) R6_w=invP(id=0,umax_value=4294967295,var_off=(0xcf800000; 0x3077fff0)) R10=fp0 5: (c4) w6 s>>= 1 6: R0_w=invP(id=0) R6_w=invP(id=0,umin_value=3888119808,umax_value=4294705144,var_off=(0xe7c00000; 0x183bfff8)) R10=fp0 (0x67c00000) (0xfffbfff8) 6: (76) if w6 s>= 0x30303030 goto pc+216 7: R0_w=invP(id=0) R6_w=invP(id=0,umin_value=3888119808,umax_value=4294705144,var_off=(0xe7c00000; 0x183bfff8)) R10=fp0 7: (30) r0 = *(u8 *)skb[808464432] BPF_LD_[ABS|IND] uses reserved fields processed 8 insns (limit 1000000) [...] Fixes: 9cbe1f5a32dc (""bpf/verifier: improve register value range tracking with ARSH"") Reported-by: Anatoly Trosinenko Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200115204733.16648-1-daniel@iogearbox.net","include/linux/tnum.h | 2 +-; kernel/bpf/tnum.c | 9 +++++++--; kernel/bpf/verifier.c | 13 ++++++++++---; 3 files changed, 18 insertions(+), 6 deletions(-)","The commit fixes a verifier bug with ARSH simulation under ALU32 by correcting sign bit handling in 32-bit mode.","verifier,ARSH,bug","A bug fix. It primarily resolves a bug or issue in the code.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"83e4b88be1ff9671f2a2fb040a09c45cc3fb40e6","83e4b88be1ff9671f2a2fb040a09c45cc3fb40e6","Eelco Chaudron","echaudro@redhat.com","1579094139","Alexei Starovoitov","ast@kernel.org","1579123345","d50aa49e9f112371678bcfb8e41eee40e950d7d1","9173cac3b64e6785dd604f5075e6035b045a0026","selftests/bpf: Add a test for attaching a bpf fentry/fexit trace to an XDP program Add a test that will attach a FENTRY and FEXIT program to the XDP test program. It will also verify data from the XDP context on FENTRY and verifies the return code on exit. Signed-off-by: Eelco Chaudron Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/157909410480.47481.11202505690938004673.stgit@xdp-tutorial",".../testing/selftests/bpf/prog_tests/xdp_bpf2bpf.c | 65 ++++++++++++++++++++++; .../testing/selftests/bpf/progs/test_xdp_bpf2bpf.c | 44 +++++++++++++++; 2 files changed, 109 insertions(+)","Add a selftest for attaching eBPF fentry/fexit trace programs to an XDP program and verifying functionality and return behavior.","selftests,XDP,fentry","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.', 'Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"9173cac3b64e6785dd604f5075e6035b045a0026","9173cac3b64e6785dd604f5075e6035b045a0026","Andrii Nakryiko","andriin@fb.com","1579115336","Alexei Starovoitov","ast@kernel.org","1579117908","69fe32b9d326c5adacc059f02a5f653248407108","5640a771d7971412049d1934d2d030edfdd1c28e","libbpf: Support .text sub-calls relocations The LLVM patch https://reviews.llvm.org/D72197 makes LLVM emit function call relocations within the same section. This includes a default .text section, which contains any BPF sub-programs. This wasn't the case before and so libbpf was able to get a way with slightly simpler handling of subprogram call relocations. This patch adds support for .text section relocations. It needs to ensure correct order of relocations, so does two passes: - first, relocate .text instructions, if there are any relocations in it; - then process all the other programs and copy over patched .text instructions for all sub-program calls. v1->v2: - break early once .text program is processed. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Cc: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200115190856.2391325-1-andriin@fb.com","tools/lib/bpf/libbpf.c | 29 ++++++++++++++++++++++-------; 1 file changed, 22 insertions(+), 7 deletions(-)","The commit enhances libbpf to support internal function call relocations within .text sections due to an LLVM update.","libbpf, relocations, LLVM","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"5640a771d7971412049d1934d2d030edfdd1c28e","5640a771d7971412049d1934d2d030edfdd1c28e","Alexei Starovoitov","ast@kernel.org","1579117491","Alexei Starovoitov","ast@kernel.org","1579117592","e68ec27387482ff400e4f7b7212eae6f6941e6ac","d3a56931f9c8644a52e7a6735954c84ea895e8c3 ab8b7f0cb3585ecb40e3305850f28658a1b8940e","Merge branch 'bpf_send_signal_thread' Yonghong Song says: ==================== Commit 8b401f9ed244 (""bpf: implement bpf_send_signal() helper"") added helper bpf_send_signal() which permits bpf program to send a signal to the current process. The signal may send to any thread of the process. This patch implemented a new helper bpf_send_signal_thread() to send a signal to the thread corresponding to the kernel current task. This helper can simplify user space code if the thread context of bpf sending signal is needed in user space. Please see Patch #1 for details of use case and kernel implementation. Patch #2 added some bpf self tests for the new helper. Changelogs: v2 -> v3: - More simplification for skeleton codes by removing not-needed mmap code and redundantly created tracepoint link. v1 -> v2: - More description for the difference between bpf_send_signal() and bpf_send_signal_thread() in the uapi header bpf.h. - Use skeleton and mmap for send_signal test. ==================== Acked-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov ","","This commit merges a branch adding a new helper function for sending signals to specific thread contexts in eBPF programs.","merge,signal,helper","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"ab8b7f0cb3585ecb40e3305850f28658a1b8940e","ab8b7f0cb3585ecb40e3305850f28658a1b8940e","Yonghong Song","yhs@fb.com","1579060203","Alexei Starovoitov","ast@kernel.org","1579117491","e68ec27387482ff400e4f7b7212eae6f6941e6ac","8482941f09067da42f9c3362e15bfb3f3c19d610","tools/bpf: Add self tests for bpf_send_signal_thread() The test_progs send_signal() is amended to test bpf_send_signal_thread() as well. $ ./test_progs -n 40 #40/1 send_signal_tracepoint:OK #40/2 send_signal_perf:OK #40/3 send_signal_nmi:OK #40/4 send_signal_tracepoint_thread:OK #40/5 send_signal_perf_thread:OK #40/6 send_signal_nmi_thread:OK #40 send_signal:OK Summary: 1/6 PASSED, 0 SKIPPED, 0 FAILED Also took this opportunity to rewrite the send_signal test using skeleton framework and array mmap to make code simpler and more readable. Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200115035003.602425-1-yhs@fb.com",".../testing/selftests/bpf/prog_tests/send_signal.c | 128 ++++++++-------------; .../selftests/bpf/progs/test_send_signal_kern.c | 51 ++++----; 2 files changed, 73 insertions(+), 106 deletions(-)","The commit adds self-tests for bpf_send_signal_thread() and refactors send_signal test with a simpler framework.","self-tests bpf_send_signal_thread refactor","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"8482941f09067da42f9c3362e15bfb3f3c19d610","8482941f09067da42f9c3362e15bfb3f3c19d610","Yonghong Song","yhs@fb.com","1579060202","Alexei Starovoitov","ast@kernel.org","1579117491","66bbf4957c6b903a77ab29ff8fa2a4104cd32e09","d3a56931f9c8644a52e7a6735954c84ea895e8c3","bpf: Add bpf_send_signal_thread() helper Commit 8b401f9ed244 (""bpf: implement bpf_send_signal() helper"") added helper bpf_send_signal() which permits bpf program to send a signal to the current process. The signal may be delivered to any threads in the process. We found a use case where sending the signal to the current thread is more preferable. - A bpf program will collect the stack trace and then send signal to the user application. - The user application will add some thread specific information to the just collected stack trace for later analysis. If bpf_send_signal() is used, user application will need to check whether the thread receiving the signal matches the thread collecting the stack by checking thread id. If not, it will need to send signal to another thread through pthread_kill(). This patch proposed a new helper bpf_send_signal_thread(), which sends the signal to the thread corresponding to the current kernel task. This way, user space is guaranteed that bpf_program execution context and user space signal handling context are the same thread. Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200115035002.602336-1-yhs@fb.com","include/uapi/linux/bpf.h | 19 +++++++++++++++++--; kernel/trace/bpf_trace.c | 27 ++++++++++++++++++++++++---; tools/include/uapi/linux/bpf.h | 19 +++++++++++++++++--; 3 files changed, 58 insertions(+), 7 deletions(-)","This commit introduces the bpf_send_signal_thread() helper for sending signals to the current thread for better stack trace analysis.","bpf,signal,helper","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here.""]" +"d3a56931f9c8644a52e7a6735954c84ea895e8c3","d3a56931f9c8644a52e7a6735954c84ea895e8c3","Magnus Karlsson","magnus.karlsson@intel.com","1578995365","Alexei Starovoitov","ast@kernel.org","1579117312","91d9e96017c76e1a3cc7c1d1c741e571988f731f","0a29275b6300f39f78a87f2038bbfe5bdbaeca47","xsk: Support allocations of large umems When registering a umem area that is sufficiently large (>1G on an x86), kmalloc cannot be used to allocate one of the internal data structures, as the size requested gets too large. Use kvmalloc instead that falls back on vmalloc if the allocation is too large for kmalloc. Also add accounting for this structure as it is triggered by a user space action (the XDP_UMEM_REG setsockopt) and it is by far the largest structure of kernel allocated memory in xsk. Reported-by: Ryan Goodfellow Signed-off-by: Magnus Karlsson Signed-off-by: Alexei Starovoitov Acked-by: Jonathan Lemon Link: https://lore.kernel.org/bpf/1578995365-7050-1-git-send-email-magnus.karlsson@intel.com","net/xdp/xdp_umem.c | 7 ++++---; 1 file changed, 4 insertions(+), 3 deletions(-)","The commit modifies xsk to use kvmalloc for large umem allocations exceeding 1G, enhancing memory handling.","xsk kvmalloc umem","A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.', 'XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"0a29275b6300f39f78a87f2038bbfe5bdbaeca47","0a29275b6300f39f78a87f2038bbfe5bdbaeca47","Li RongQing","lirongqing@baidu.com","1578618277","Daniel Borkmann","daniel@iogearbox.net","1579030344","1d8ed61d64ce17f6f067eca367d76d0fa531ab46","3b4130418f62b0e7a4685cc2c03bb41c6cb8922d","bpf: Return -EBADRQC for invalid map type in __bpf_tx_xdp_map A negative value should be returned if map->map_type is invalid although that is impossible now, but if we run into such situation in future, then xdpbuff could be leaked. Daniel Borkmann suggested: -EBADRQC should be returned to stay consistent with generic XDP for the tracepoint output and not to be confused with -EOPNOTSUPP from other locations like dev_map_enqueue() when ndo_xdp_xmit is missing and such. Suggested-by: Daniel Borkmann Signed-off-by: Li RongQing Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/1578618277-18085-1-git-send-email-lirongqing@baidu.com","net/core/filter.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","The commit ensures a consistent error return for invalid map types in __bpf_tx_xdp_map to prevent potential xdpbuff leaks.","invalid map type, xdpbuff, error","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.', ""It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here."", ""I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear.""]" +"3b4130418f62b0e7a4685cc2c03bb41c6cb8922d","3b4130418f62b0e7a4685cc2c03bb41c6cb8922d","Martin KaFai Lau","kafai@fb.com","1578986807","Alexei Starovoitov","ast@kernel.org","1579024471","e21b8e78a62af42310fbf7d9e0c92061df9ccf97","6dd42aa17fdd59f383998c6c3e0ecc89414f4a04","bpf: Fix seq_show for BPF_MAP_TYPE_STRUCT_OPS Instead of using bpf_struct_ops_map_lookup_elem() which is not implemented, bpf_struct_ops_map_seq_show_elem() should also use bpf_struct_ops_map_sys_lookup_elem() which does an inplace update to the value. The change allocates a value to pass to bpf_struct_ops_map_sys_lookup_elem(). [root@arch-fb-vm1 bpf]# cat /sys/fs/bpf/dctcp {{{1}},BPF_STRUCT_OPS_STATE_INUSE,{{00000000df93eebc,00000000df93eebc},0,2, ... Fixes: 85d33df357b6 (""bpf: Introduce BPF_MAP_TYPE_STRUCT_OPS"") Reported-by: Dan Carpenter Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200114072647.3188298-1-kafai@fb.com","kernel/bpf/bpf_struct_ops.c | 14 ++++++++++----; 1 file changed, 10 insertions(+), 4 deletions(-)","The commit fixes seq_show for BPF_MAP_TYPE_STRUCT_OPS by using the correct lookup function and updating the value appropriately.","seq_show, STRUCT_OPS, lookup","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems.']" +"6dd42aa17fdd59f383998c6c3e0ecc89414f4a04","6dd42aa17fdd59f383998c6c3e0ecc89414f4a04","Alexei Starovoitov","ast@kernel.org","1578966493","Alexei Starovoitov","ast@kernel.org","1579022600","c585f9baa6383174387b5fc1002fdf2cdf9e0fd4","ac065870d92824ee0bc275ab71fd8901dbde5055 3a0d3092a4edbbcd62360c44a931c8feaf4b4ff1","Merge branch 'runqslower' Andrii Nakryiko says: ==================== Based on recent BPF CO-RE, tp_btf, and BPF skeleton changes, re-implement BCC-based runqslower tool as a portable pre-compiled BPF CO-RE-based tool. Make sure it's built as part of selftests to ensure it doesn't bit rot. As part of this patch set, augment `format c` output of `bpftool btf dump` sub-command with applying `preserve_access_index` attribute to all structs and unions. This makes all such structs and unions automatically relocatable under BPF CO-RE, which improves user experience of writing TRACING programs with direct kernel memory read access. Also, further clean up selftest/bpf Makefile output and make it conforming to libbpf and bpftool succinct output format. v1->v2: - build in-tree bpftool for runqslower (Yonghong); - drop `format core` and augment `format c` instead (Alexei); - move runqslower under tools/bpf (Daniel). ==================== Signed-off-by: Alexei Starovoitov ","","This commit merges updates to make runqslower a portable CO-RE-based tool and improves bpftool for better BPF CO-RE usability.","runqslower, CO-RE, bpftool","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"3a0d3092a4edbbcd62360c44a931c8feaf4b4ff1","3a0d3092a4edbbcd62360c44a931c8feaf4b4ff1","Andrii Nakryiko","andriin@fb.com","1578900703","Alexei Starovoitov","ast@kernel.org","1579022592","c585f9baa6383174387b5fc1002fdf2cdf9e0fd4","9c01546d26d28cf57341d8380ba900bf68e26b18","selftests/bpf: Build runqslower from selftests Ensure runqslower tool is built as part of selftests to prevent it from bit rotting. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200113073143.1779940-7-andriin@fb.com","tools/bpf/runqslower/Makefile | 2 +-; tools/testing/selftests/bpf/Makefile | 7 ++++++-; 2 files changed, 7 insertions(+), 2 deletions(-)","This commit ensures the runqslower tool is included in BPF selftests to prevent it from being neglected.","selftests,runqslower,build","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"49e0b6f4e95aa3ade8f512c50d1ccc113fe917b4","49e0b6f4e95aa3ade8f512c50d1ccc113fe917b4","Cengiz Can","cengiz@kernel.wtf","1578937479","Arnaldo Carvalho de Melo","acme@redhat.com","1579016546","0bc5eacfd3c89a3867fe150636793a56a912eba4","93e843f95f095aeb533ab67ac4718f848d38dfa0","perf beauty sockaddr: Fix augmented syscall format warning The sockaddr related examples given in `tools/perf/examples/bpf/augmented_syscalls.c` almost always use `long`s to represent most of their fields. However, `size_t syscall_arg__scnprintf_sockaddr(..)` has a `scnprintf` call that uses `""%#x""` as format string. This throws a warning (whenever the syscall argument is `unsigned long`). Added `l` identifier to indicate that the `arg->value` is an unsigned long. Not sure about the complications of this with x86 though. Signed-off-by: Cengiz Can Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/20200113174438.102975-1-cengiz@kernel.wtf Signed-off-by: Arnaldo Carvalho de Melo ","tools/perf/trace/beauty/sockaddr.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","This commit fixes a format warning for augmented syscalls in perf trace beauty sockaddr by updating format specifier for unsigned long.","format,warning,syscall","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.","It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.","[""It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here.""]" +"f042365dbffea98fb8148c98c700402e8d099f02","f042365dbffea98fb8148c98c700402e8d099f02","Nicolas Dichtel","nicolas.dichtel@6wind.com","1578904367","Steffen Klassert","steffen.klassert@secunet.com","1578988538","b125be0ffb1023e21cd54e6005d9dc2c3849ed4f","95224166a9032ff5d08fca633d37113078ce7d01","xfrm interface: fix packet tx through bpf_redirect() With an ebpf program that redirects packets through a xfrm interface, packets are dropped because no dst is attached to skb. This could also be reproduced with an AF_PACKET socket, with the following python script (xfrm1 is a xfrm interface): import socket send_s = socket.socket(socket.AF_PACKET, socket.SOCK_RAW, 0) # scapy # p = IP(src='10.100.0.2', dst='10.200.0.1')/ICMP(type='echo-request') # raw(p) req = b'E\x00\x00\x1c\x00\x01\x00\x00@\x01e\xb2\nd\x00\x02\n\xc8\x00\x01\x08\x00\xf7\xff\x00\x00\x00\x00' send_s.sendto(req, ('xfrm1', 0x800, 0, 0)) It was also not possible to send an ip packet through an AF_PACKET socket because a LL header was expected. Let's remove those LL header constraints. Signed-off-by: Nicolas Dichtel Signed-off-by: Steffen Klassert ","net/xfrm/xfrm_interface.c | 32 +++++++++++++++++++++++++-------; 1 file changed, 25 insertions(+), 7 deletions(-)","Fixes dropped packets issue by ensuring the correct handling when redirecting packets through a xfrm interface without requiring a link layer header.","packet, xfrm, bpf_redirect","A bug fix. It primarily resolves a bug or issue in the code.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime."", ""I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear.""]" +"95224166a9032ff5d08fca633d37113078ce7d01","95224166a9032ff5d08fca633d37113078ce7d01","Nicolas Dichtel","nicolas.dichtel@6wind.com","1578904366","Steffen Klassert","steffen.klassert@secunet.com","1578988538","21181101c0a61e77ab1082dc80fd028249719eb9","a112adafcb47760feff959ee1ecd10b74d2c5467","vti[6]: fix packet tx through bpf_redirect() With an ebpf program that redirects packets through a vti[6] interface, the packets are dropped because no dst is attached. This could also be reproduced with an AF_PACKET socket, with the following python script (vti1 is an ip_vti interface): import socket send_s = socket.socket(socket.AF_PACKET, socket.SOCK_RAW, 0) # scapy # p = IP(src='10.100.0.2', dst='10.200.0.1')/ICMP(type='echo-request') # raw(p) req = b'E\x00\x00\x1c\x00\x01\x00\x00@\x01e\xb2\nd\x00\x02\n\xc8\x00\x01\x08\x00\xf7\xff\x00\x00\x00\x00' send_s.sendto(req, ('vti1', 0x800, 0, 0)) Signed-off-by: Nicolas Dichtel Signed-off-by: Steffen Klassert ","net/ipv4/ip_vti.c | 13 +++++++++++--; net/ipv6/ip6_vti.c | 13 +++++++++++--; 2 files changed, 22 insertions(+), 4 deletions(-)","The commit resolves packet dropping issues in bpf_redirect() for vti[6] interfaces by ensuring packets have a destination attached.","bpf_redirect,vti,packet","A bug fix. It primarily resolves a bug or issue in the code.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.', ""It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here.""]" +"9c01546d26d28cf57341d8380ba900bf68e26b18","9c01546d26d28cf57341d8380ba900bf68e26b18","Andrii Nakryiko","andriin@fb.com","1578900702","Alexei Starovoitov","ast@kernel.org","1578966493","06640835fe8f1d79e93687db289bcf8451548380","1cf5b23988ea0086a252a5c8b005b075f1e9b030","tools/bpf: Add runqslower tool to tools/bpf Convert one of BCC tools (runqslower [0]) to BPF CO-RE + libbpf. It matches its BCC-based counterpart 1-to-1, supporting all the same parameters and functionality. runqslower tool utilizes BPF skeleton, auto-generated from BPF object file, as well as memory-mapped interface to global (read-only, in this case) data. Its Makefile also ensures auto-generation of ""relocatable"" vmlinux.h, which is necessary for BTF-typed raw tracepoints with direct memory access. [0] https://github.com/iovisor/bcc/blob/11bf5d02c895df9646c117c713082eb192825293/tools/runqslower.py Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200113073143.1779940-6-andriin@fb.com","tools/bpf/Makefile | 20 +++-; tools/bpf/runqslower/.gitignore | 1 +; tools/bpf/runqslower/Makefile | 80 +++++++++++++++; tools/bpf/runqslower/runqslower.bpf.c | 100 ++++++++++++++++++; tools/bpf/runqslower/runqslower.c | 187 ++++++++++++++++++++++++++++++++++; tools/bpf/runqslower/runqslower.h | 13 +++; 6 files changed, 396 insertions(+), 5 deletions(-)","The commit adds the runqslower tool to the BPF tools directory by converting it from BCC to BPF CO-RE and libbpf.","runqslower,BPF CO-RE,libbpf","A new feature. It adds a new capability or feature that was not previously present.","Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"1cf5b23988ea0086a252a5c8b005b075f1e9b030","1cf5b23988ea0086a252a5c8b005b075f1e9b030","Andrii Nakryiko","andriin@fb.com","1578900701","Alexei Starovoitov","ast@kernel.org","1578966493","8dabe0a326970a8b8a47ce8457b9530dad94f744","2cc51d34d93c9cf76128da6535a2a0a38c9faddb","bpftool: Apply preserve_access_index attribute to all types in BTF dump This patch makes structs and unions, emitted through BTF dump, automatically CO-RE-relocatable (unless disabled with `#define BPF_NO_PRESERVE_ACCESS_INDEX`, specified before including generated header file). This effectivaly turns usual bpf_probe_read() call into equivalent of bpf_core_read(), by automatically applying builtin_preserve_access_index to any field accesses of types in generated C types header. This is especially useful for tp_btf/fentry/fexit BPF program types. They allow direct memory access, so BPF C code just uses straightfoward a->b->c access pattern to read data from kernel. But without kernel structs marked as CO-RE relocatable through preserve_access_index attribute, one has to enclose all the data reads into a special __builtin_preserve_access_index code block, like so: __builtin_preserve_access_index(({ x = p->pid; /* where p is struct task_struct *, for example */ })); This is very inconvenient and obscures the logic quite a bit. By marking all auto-generated types with preserve_access_index attribute the above code is reduced to just a clean and natural `x = p->pid;`. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200113073143.1779940-5-andriin@fb.com","tools/bpf/bpftool/btf.c | 8 ++++++++; 1 file changed, 8 insertions(+)","The commit updates bpftool to use preserve_access_index attribute for BTF dump types, simplifying direct memory access in BPF programs.","bpftool,BTF,preserve_access_index","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.', 'Scheduler related type programs. It modifies programs that interact with kernel-level scheduling mechanisms.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"2cc51d34d93c9cf76128da6535a2a0a38c9faddb","2cc51d34d93c9cf76128da6535a2a0a38c9faddb","Andrii Nakryiko","andriin@fb.com","1578900700","Alexei Starovoitov","ast@kernel.org","1578966493","a8b61965b87c8d0b59f36a6d4c73d796351039c8","292e1d73b125d7a3fd7ff382557e003ece3c0d65","selftests/bpf: Conform selftests/bpf Makefile output to libbpf and bpftool Bring selftest/bpf's Makefile output to the same format used by libbpf and bpftool: 2 spaces of padding on the left + 8-character left-aligned build step identifier. Also, hide feature detection output by default. Can be enabled back by setting V=1. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200113073143.1779940-4-andriin@fb.com","tools/testing/selftests/bpf/Makefile | 47 +++++++++++++++++++-----------------; 1 file changed, 25 insertions(+), 22 deletions(-)","The commit updates the selftests/bpf Makefile for consistent output formatting with libbpf and bpftool.","selftests, Makefile, formatting","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"292e1d73b125d7a3fd7ff382557e003ece3c0d65","292e1d73b125d7a3fd7ff382557e003ece3c0d65","Andrii Nakryiko","andriin@fb.com","1578900699","Alexei Starovoitov","ast@kernel.org","1578966493","808d3cd36b91f34f2724e9dcdf3924ba56bdac57","533420a4151e28e6a38a830cb876afddb5587d7d","libbpf: Clean up bpf_helper_defs.h generation output bpf_helpers_doc.py script, used to generate bpf_helper_defs.h, unconditionally emits one informational message to stderr. Remove it and preserve stderr to contain only relevant errors. Also make sure script invocations command is muted by default in libbpf's Makefile. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200113073143.1779940-3-andriin@fb.com","scripts/bpf_helpers_doc.py | 2 --; tools/lib/bpf/Makefile | 2 +-; 2 files changed, 1 insertion(+), 3 deletions(-)","The commit refines console output during bpf_helper_defs.h generation and adjusts default command verbosity in libbpf Makefile.","libbpf, generation, Makefile","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"533420a4151e28e6a38a830cb876afddb5587d7d","533420a4151e28e6a38a830cb876afddb5587d7d","Andrii Nakryiko","andriin@fb.com","1578900698","Alexei Starovoitov","ast@kernel.org","1578966492","34bdb4d8d56a0ce2508508810450098a3c240c6e","ac065870d92824ee0bc275ab71fd8901dbde5055","tools: Sync uapi/linux/if_link.h Sync uapi/linux/if_link.h into tools to avoid out of sync warnings during libbpf build. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200113073143.1779940-2-andriin@fb.com","tools/include/uapi/linux/if_link.h | 1 +; 1 file changed, 1 insertion(+)","Sync uapi/linux/if_link.h in tools to avoid out-of-sync warnings during libbpf build.","sync,uapi,libbpf","A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"8649c322f75c96e7ced2fec201e123b2b073bf09","8649c322f75c96e7ced2fec201e123b2b073bf09","Sargun Dhillon","sargun@sargun.me","1578419965","Christian Brauner","christian.brauner@ubuntu.com","1578948576","791d90016044b13207400609c491f71654fc5f34","5e876fb43dbf24c941a323139752bcb2f0a80da0","pid: Implement pidfd_getfd syscall This syscall allows for the retrieval of file descriptors from other processes, based on their pidfd. This is possible using ptrace, and injection of parasitic code to inject code which leverages SCM_RIGHTS to move file descriptors between a tracee and a tracer. Unfortunately, ptrace comes with a high cost of requiring the process to be stopped, and breaks debuggers. This does not require stopping the process under manipulation. One reason to use this is to allow sandboxers to take actions on file descriptors on the behalf of another process. For example, this can be combined with seccomp-bpf's user notification to do on-demand fd extraction and take privileged actions. One such privileged action is binding a socket to a privileged port. /* prototype */ /* flags is currently reserved and should be set to 0 */ int sys_pidfd_getfd(int pidfd, int fd, unsigned int flags); /* testing */ Ran self-test suite on x86_64 Signed-off-by: Sargun Dhillon Acked-by: Christian Brauner Reviewed-by: Arnd Bergmann Link: https://lore.kernel.org/r/20200107175927.4558-3-sargun@sargun.me Signed-off-by: Christian Brauner ","kernel/pid.c | 90 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++; 1 file changed, 90 insertions(+)","This commit implements the new syscall pidfd_getfd to retrieve file descriptors from other processes without stopping them.","pidfd_getfd, syscall, file_descriptors","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.","It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.","[""It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.""]" +"555089fdfc37ad65e0ee9b42ca40c238ff546f83","555089fdfc37ad65e0ee9b42ca40c238ff546f83","Martin KaFai Lau","kafai@fb.com","1578698204","Alexei Starovoitov","ast@kernel.org","1578798501","49325ac48be165288896658c354b0bad03c5118a","2e012c74823629d9db27963c79caa3f5b2010746","bpftool: Fix printing incorrect pointer in btf_dump_ptr For plain text output, it incorrectly prints the pointer value ""void *data"". The ""void *data"" is actually pointing to memory that contains a bpf-map's value. The intention is to print the content of the bpf-map's value instead of printing the pointer pointing to the bpf-map's value. In this case, a member of the bpf-map's value is a pointer type. Thus, it should print the ""*(void **)data"". Fixes: 22c349e8db89 (""tools: bpftool: fix format strings and arguments for jsonw_printf()"") Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200110231644.3484151-1-kafai@fb.com","tools/bpf/bpftool/btf_dumper.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","The commit corrects bpftool to properly print the content of bpf-maps' values instead of pointer addresses.","bpftool, pointer, bpf-map","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"ac065870d92824ee0bc275ab71fd8901dbde5055","ac065870d92824ee0bc275ab71fd8901dbde5055","Andrii Nakryiko","andriin@fb.com","1578690994","Alexei Starovoitov","ast@kernel.org","1578693727","04bb05190a5b863e18a6d0bc775cb0bbebb021fe","1d1a3bcffe360a56fd8cc287ed74d4c3066daf42","selftests/bpf: Add BPF_PROG, BPF_KPROBE, and BPF_KRETPROBE macros Streamline BPF_TRACE_x macro by moving out return type and section attribute definition out of macro itself. That makes those function look in source code similar to other BPF programs. Additionally, simplify its usage by determining number of arguments automatically (so just single BPF_TRACE vs a family of BPF_TRACE_1, BPF_TRACE_2, etc). Also, allow more natural function argument syntax without commas inbetween argument type and name. Given this helper is useful not only for tracing tp_btf/fenty/fexit programs, but could be used for LSM programs and others following the same pattern, rename BPF_TRACE macro into more generic BPF_PROG. Existing BPF_TRACE_x usages in selftests are converted to new BPF_PROG macro. Following the same pattern, define BPF_KPROBE and BPF_KRETPROBE macros for nicer usage of kprobe/kretprobe arguments, respectively. BPF_KRETPROBE, adopts same convention used by fexit programs, that last defined argument is probed function's return result. v4->v5: - fix test_overhead test (__set_task_comm is void) (Alexei); v3->v4: - rebased and fixed one more BPF_TRACE_x occurence (Alexei); v2->v3: - rename to shorter and as generic BPF_PROG (Alexei); v1->v2: - verified GCC handles pragmas as expected; - added descriptions to macros; - converted new STRUCT_OPS selftest to BPF_HANDLER (worked as expected); - added original context as 'ctx' parameter, for cases where it has to be passed into BPF helpers. This might cause an accidental naming collision, unfortunately, but at least it's easy to work around. Fortunately, this situation produces quite legible compilation error: progs/bpf_dctcp.c:46:6: error: redefinition of 'ctx' with a different type: 'int' vs 'unsigned long long *' int ctx = 123; ^ progs/bpf_dctcp.c:42:6: note: previous definition is here void BPF_HANDLER(dctcp_init, struct sock *sk) ^ ./bpf_trace_helpers.h:58:32: note: expanded from macro 'BPF_HANDLER' ____##name(unsigned long long *ctx, ##args) Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200110211634.1614739-1-andriin@fb.com","tools/testing/selftests/bpf/bpf_tcp_helpers.h | 9 --; tools/testing/selftests/bpf/bpf_trace_helpers.h | 166 ++++++++++++++-------; tools/testing/selftests/bpf/progs/bpf_dctcp.c | 26 ++--; tools/testing/selftests/bpf/progs/fentry_test.c | 21 +--; tools/testing/selftests/bpf/progs/fexit_bpf2bpf.c | 12 +-; .../selftests/bpf/progs/fexit_bpf2bpf_simple.c | 5 +-; tools/testing/selftests/bpf/progs/fexit_test.c | 23 +--; tools/testing/selftests/bpf/progs/kfree_skb.c | 16 +-; tools/testing/selftests/bpf/progs/test_overhead.c | 30 ++--; .../testing/selftests/bpf/progs/test_perf_buffer.c | 3 +-; .../testing/selftests/bpf/progs/test_probe_user.c | 3 +-; 11 files changed, 193 insertions(+), 121 deletions(-)","This commit introduces new macros for BPF programs to streamline and simplify function declaration and usage in selftests.","macros,BPF_PROG,selftests","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"db885e66d268884dc72967279b7e84f522556abc","db885e66d268884dc72967279b7e84f522556abc","Jakub Kicinski","jakub.kicinski@netronome.com","1578659912","David S. Miller","davem@davemloft.net","1578684046","f35e8641beeca511e3340a7b604c1532c172a3a1","5c5d22a750d4bcf35e9539dccec397b0edcce176","net/tls: fix async operation Mallesham reports the TLS with async accelerator was broken by commit d10523d0b3d7 (""net/tls: free the record on encryption error"") because encryption can return -EINPROGRESS in such setups, which should not be treated as an error. The error is also present in the BPF path (likely copied from there). Reported-by: Mallesham Jatharakonda Fixes: d3b18ad31f93 (""tls: add bpf support to sk_msg handling"") Fixes: d10523d0b3d7 (""net/tls: free the record on encryption error"") Signed-off-by: Jakub Kicinski Reviewed-by: Simon Horman Signed-off-by: David S. Miller ","net/tls/tls_sw.c | 4 ++--; 1 file changed, 2 insertions(+), 2 deletions(-)","The commit fixes an issue with async TLS operations incorrectly treating -EINPROGRESS as an error.","TLS, async, fix","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.","It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.","[""It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.""]" +"2e012c74823629d9db27963c79caa3f5b2010746","2e012c74823629d9db27963c79caa3f5b2010746","Lorenz Bauer","lmb@cloudflare.com","1578662616","Alexei Starovoitov","ast@kernel.org","1578681743","f7076cabc30ef3bea7a5ec1485c1e8449594cb2c","e7a5f1f1cd0008e5ad379270a8657e121eedb669","net: bpf: Don't leak time wait and request sockets It's possible to leak time wait and request sockets via the following BPF pseudo code:   sk = bpf_skc_lookup_tcp(...) if (sk) bpf_sk_release(sk) If sk->sk_state is TCP_NEW_SYN_RECV or TCP_TIME_WAIT the refcount taken by bpf_skc_lookup_tcp is not undone by bpf_sk_release. This is because sk_flags is re-used for other data in both kinds of sockets. The check !sock_flag(sk, SOCK_RCU_FREE) therefore returns a bogus result. Check that sk_flags is valid by calling sk_fullsock. Skip checking SOCK_RCU_FREE if we already know that sk is not a full socket. Fixes: edbf8c01de5a (""bpf: add skc_lookup_tcp helper"") Fixes: f7355a6c0497 (""bpf: Check sk_fullsock() before returning from bpf_sk_lookup()"") Signed-off-by: Lorenz Bauer Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200110132336.26099-1-lmb@cloudflare.com","net/core/filter.c | 9 ++++-----; 1 file changed, 4 insertions(+), 5 deletions(-)","Fixes a socket reference leak in eBPF when using the bpf_skc_lookup_tcp helper function.","socket,leak,bpf_skc_lookup_tcp","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"1d1a3bcffe360a56fd8cc287ed74d4c3066daf42","1d1a3bcffe360a56fd8cc287ed74d4c3066daf42","Andrii Nakryiko","andriin@fb.com","1578680356","Alexei Starovoitov","ast@kernel.org","1578681480","a5dd199f093ed5cd8a2dd179c2682ea5520b26b5","7a2d070f91db83a1e08bf212e8f6a34d852efb7f","libbpf: Poison kernel-only integer types It's been a recurring issue with types like u32 slipping into libbpf source code accidentally. This is not detected during builds inside kernel source tree, but becomes a compilation error in libbpf's Github repo. Libbpf is supposed to use only __{s,u}{8,16,32,64} typedefs, so poison {s,u}{8,16,32,64} explicitly in every .c file. Doing that in a bit more centralized way, e.g., inside libbpf_internal.h breaks selftests, which are both using kernel u32 and libbpf_internal.h. This patch also fixes a new u32 occurence in libbpf.c, added recently. Fixes: 590a00888250 (""bpf: libbpf: Add STRUCT_OPS support"") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200110181916.271446-1-andriin@fb.com","tools/lib/bpf/bpf.c | 3 +++; tools/lib/bpf/bpf_prog_linfo.c | 3 +++; tools/lib/bpf/btf.c | 3 +++; tools/lib/bpf/btf_dump.c | 3 +++; tools/lib/bpf/hashmap.c | 3 +++; tools/lib/bpf/libbpf.c | 5 ++++-; tools/lib/bpf/libbpf_errno.c | 3 +++; tools/lib/bpf/libbpf_probes.c | 3 +++; tools/lib/bpf/netlink.c | 3 +++; tools/lib/bpf/nlattr.c | 3 +++; tools/lib/bpf/str_error.c | 3 +++; tools/lib/bpf/xsk.c | 3 +++; 12 files changed, 37 insertions(+), 1 deletion(-)","The commit poisons kernel-only integer types in libbpf to prevent accidental use outside the kernel repository.","libbpf,integer,types","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"7a2d070f91db83a1e08bf212e8f6a34d852efb7f","7a2d070f91db83a1e08bf212e8f6a34d852efb7f","Daniel Borkmann","daniel@iogearbox.net","1578673207","Daniel Borkmann","daniel@iogearbox.net","1578673219","29f80d80eff2526f251e5def34a8b7eb870b0504","f41aa387a7896c193b384c5fb531cd2cb9e00128 360301a6c21be87fe881546bd5f22eccf7a165c5","Merge branch 'bpf-global-funcs' Alexei Starovoitov says: ==================== Introduce static vs global functions and function by function verification. This is another step toward dynamic re-linking (or replacement) of global functions. See patch 2 for details. v2->v3: - cleaned up a check spotted by Song. - rebased and dropped patch 2 that was trying to improve BTF based on ELF. - added one more unit test for scalar return value from global func. v1->v2: - addressed review comments from Song, Andrii, Yonghong - fixed memory leak in error path - added modified ctx check - added more tests in patch 7 ==================== Signed-off-by: Daniel Borkmann ","","The commit merges changes to introduce static vs global functions and function-by-function verification towards dynamic re-linking of global functions in eBPF.","static functions,global functions,verification","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"360301a6c21be87fe881546bd5f22eccf7a165c5","360301a6c21be87fe881546bd5f22eccf7a165c5","Alexei Starovoitov","ast@kernel.org","1578638484","Daniel Borkmann","daniel@iogearbox.net","1578673207","29f80d80eff2526f251e5def34a8b7eb870b0504","e528d1c0127accbc2be48f57dd67ab89b32fd815","selftests/bpf: Add unit tests for global functions test_global_func[12] - check 512 stack limit. test_global_func[34] - check 8 frame call chain limit. test_global_func5 - check that non-ctx pointer cannot be passed into a function that expects context. test_global_func6 - check that ctx pointer is unmodified. test_global_func7 - check that global function returns scalar. Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200110064124.1760511-7-ast@kernel.org",".../selftests/bpf/prog_tests/test_global_funcs.c | 82 ++++++++++++++++++++++; .../selftests/bpf/progs/test_global_func1.c | 45 ++++++++++++; .../selftests/bpf/progs/test_global_func2.c | 4 ++; .../selftests/bpf/progs/test_global_func3.c | 65 +++++++++++++++++; .../selftests/bpf/progs/test_global_func4.c | 4 ++; .../selftests/bpf/progs/test_global_func5.c | 31 ++++++++; .../selftests/bpf/progs/test_global_func6.c | 31 ++++++++; .../selftests/bpf/progs/test_global_func7.c | 18 +++++; 8 files changed, 280 insertions(+)","The commit adds unit tests for global eBPF functions to enforce stack, call chain limits, and context handling.","unit tests, stack limit, call chain","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"e528d1c0127accbc2be48f57dd67ab89b32fd815","e528d1c0127accbc2be48f57dd67ab89b32fd815","Alexei Starovoitov","ast@kernel.org","1578638483","Daniel Borkmann","daniel@iogearbox.net","1578673207","2346cc0b08cf7c97fd40779a38d1fdfb05ea6b0e","6db2d81a46f99edb5690cf0b03bbe3b7f29dfd7b","selftests/bpf: Modify a test to check global functions Make two static functions in test_xdp_noinline.c global: before: processed 2790 insns after: processed 2598 insns Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200110064124.1760511-6-ast@kernel.org","tools/testing/selftests/bpf/progs/test_xdp_noinline.c | 4 ++--; 1 file changed, 2 insertions(+), 2 deletions(-)","The commit modifies a selftest to evaluate global function behavior by converting static functions to global in a BPF test file.","selftests,bpf,global","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.']" +"6db2d81a46f99edb5690cf0b03bbe3b7f29dfd7b","6db2d81a46f99edb5690cf0b03bbe3b7f29dfd7b","Alexei Starovoitov","ast@kernel.org","1578638482","Daniel Borkmann","daniel@iogearbox.net","1578673207","4cdd4b38078ed60f308ebe16787f36cfd7dfd4e4","7608e4db6ded8e965dd213baddedba9602959e7d","selftests/bpf: Add a test for a large global function test results: pyperf50 with always_inlined the same function five times: processed 46378 insns pyperf50 with global function: processed 6102 insns Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200110064124.1760511-5-ast@kernel.org","tools/testing/selftests/bpf/prog_tests/bpf_verif_scale.c | 2 ++; tools/testing/selftests/bpf/progs/pyperf.h | 9 +++++++--; tools/testing/selftests/bpf/progs/pyperf_global.c | 5 +++++; 3 files changed, 14 insertions(+), 2 deletions(-)","This commit adds selftests for large global function processing in eBPF, comparing inline and global function results.","selftests,global,function","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"7608e4db6ded8e965dd213baddedba9602959e7d","7608e4db6ded8e965dd213baddedba9602959e7d","Alexei Starovoitov","ast@kernel.org","1578638481","Daniel Borkmann","daniel@iogearbox.net","1578673207","3da1445e925efe469d7d8fe1fc0d542c5a115200","51c39bb1d5d105a02e29aa7960f0a395086e6342","selftests/bpf: Add fexit-to-skb test for global funcs Add simple fexit prog type to skb prog type test when subprogram is a global function. Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200110064124.1760511-4-ast@kernel.org",".../selftests/bpf/prog_tests/fexit_bpf2bpf.c | 1 +; tools/testing/selftests/bpf/progs/fexit_bpf2bpf.c | 15 ++++++++++++; .../testing/selftests/bpf/progs/test_pkt_access.c | 28 ++++++++++++++++++++++; 3 files changed, 44 insertions(+)","This commit adds a test to verify fexit programs with global functions in skb program type.","selftests,bpf,tests","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.']" +"51c39bb1d5d105a02e29aa7960f0a395086e6342","51c39bb1d5d105a02e29aa7960f0a395086e6342","Alexei Starovoitov","ast@kernel.org","1578638480","Daniel Borkmann","daniel@iogearbox.net","1578673207","74321d27fc8f03f12ac201aef205686d28ab91bd","2d3eb67f64ec317bbfe340cfcc8325d40a6ff317","bpf: Introduce function-by-function verification New llvm and old llvm with libbpf help produce BTF that distinguish global and static functions. Unlike arguments of static function the arguments of global functions cannot be removed or optimized away by llvm. The compiler has to use exactly the arguments specified in a function prototype. The argument type information allows the verifier validate each global function independently. For now only supported argument types are pointer to context and scalars. In the future pointers to structures, sizes, pointer to packet data can be supported as well. Consider the following example: static int f1(int ...) { ... } int f3(int b); int f2(int a) { f1(a) + f3(a); } int f3(int b) { ... } int main(...) { f1(...) + f2(...) + f3(...); } The verifier will start its safety checks from the first global function f2(). It will recursively descend into f1() because it's static. Then it will check that arguments match for the f3() invocation inside f2(). It will not descend into f3(). It will finish f2() that has to be successfully verified for all possible values of 'a'. Then it will proceed with f3(). That function also has to be safe for all possible values of 'b'. Then it will start subprog 0 (which is main() function). It will recursively descend into f1() and will skip full check of f2() and f3(), since they are global. The order of processing global functions doesn't affect safety, since all global functions must be proven safe based on their arguments only. Such function by function verification can drastically improve speed of the verification and reduce complexity. Note that the stack limit of 512 still applies to the call chain regardless whether functions were static or global. The nested level of 8 also still applies. The same recursion prevention checks are in place as well. The type information and static/global kind is preserved after the verification hence in the above example global function f2() and f3() can be replaced later by equivalent functions with the same types that are loaded and verified later without affecting safety of this main() program. Such replacement (re-linking) of global functions is a subject of future patches. Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200110064124.1760511-3-ast@kernel.org","include/linux/bpf.h | 7 +-; include/linux/bpf_verifier.h | 10 +-; include/uapi/linux/btf.h | 6 ++; kernel/bpf/btf.c | 175 ++++++++++++++++++++++++------; kernel/bpf/verifier.c | 252 ++++++++++++++++++++++++++++++++++---------; 5 files changed, 366 insertions(+), 84 deletions(-)","The commit introduces a function-by-function verification approach in eBPF to improve verification speed and reduce complexity.","eBPF,verification,llvm","A new feature. It adds a new capability or feature that was not previously present.","Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.","The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"2d3eb67f64ec317bbfe340cfcc8325d40a6ff317","2d3eb67f64ec317bbfe340cfcc8325d40a6ff317","Alexei Starovoitov","ast@kernel.org","1578638479","Daniel Borkmann","daniel@iogearbox.net","1578673207","5af845b22b56292a359da753e7dff4d53aa49aa6","f41aa387a7896c193b384c5fb531cd2cb9e00128","libbpf: Sanitize global functions In case the kernel doesn't support BTF_FUNC_GLOBAL sanitize BTF produced by the compiler for global functions. Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200110064124.1760511-2-ast@kernel.org","tools/include/uapi/linux/btf.h | 6 ++++++; tools/lib/bpf/libbpf.c | 35 ++++++++++++++++++++++++++++++++++-; 2 files changed, 40 insertions(+), 1 deletion(-)","The commit sanitizes BTF data for global functions in libbpf when kernel lacks BTF_FUNC_GLOBAL support.","sanitize, global, BTF","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"f41aa387a7896c193b384c5fb531cd2cb9e00128","f41aa387a7896c193b384c5fb531cd2cb9e00128","Alexei Starovoitov","ast@kernel.org","1578635708","Alexei Starovoitov","ast@kernel.org","1578635776","4681721bd9f37365151220662868193e65b603ff","492ab0205f500ebd20b4f0c9e95a1ba007b0c542 965b9fee28d062c79a5fdaa3dfbe04c5129ee63d","Merge branch 'selftest-makefile-cleanup' Andrii Nakryiko says: ==================== Fix issues with bpf_helper_defs.h usage in selftests/bpf. As part of that, fix the way clean up is performed for libbpf and selftests/bpf. Some for Makefile output clean ups as well. ==================== Signed-off-by: Alexei Starovoitov ","","Merge commit addressing selftest Makefile cleanup and bpf_helper_defs.h issues with libbpf adjustments.","selftest, libbpf, Makefile","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"965b9fee28d062c79a5fdaa3dfbe04c5129ee63d","965b9fee28d062c79a5fdaa3dfbe04c5129ee63d","Andrii Nakryiko","andriin@fb.com","1578633436","Alexei Starovoitov","ast@kernel.org","1578635708","4681721bd9f37365151220662868193e65b603ff","6910d7d3867a8e65eaecb18a9527ecc9eb2e5edf","selftests/bpf: Further clean up Makefile output Further clean up Makefile output: - hide ""entering directory"" messages; - silvence sub-Make command echoing; - succinct MKDIR messages. Also remove few test binaries that are not produced anymore from .gitignore. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200110051716.1591485-4-andriin@fb.com","tools/testing/selftests/bpf/.gitignore | 2 --; tools/testing/selftests/bpf/Makefile | 10 +++++++---; 2 files changed, 7 insertions(+), 5 deletions(-)","The commit improves Makefile output readability and updates .gitignore by removing obsolete test binaries in selftests/bpf.","Makefile, output, .gitignore","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"6910d7d3867a8e65eaecb18a9527ecc9eb2e5edf","6910d7d3867a8e65eaecb18a9527ecc9eb2e5edf","Andrii Nakryiko","andriin@fb.com","1578633435","Alexei Starovoitov","ast@kernel.org","1578635708","4817729063634f933adb744f1b33779370f58916","2031af28a42f18cc65ec3aa85b4e5cfdf5ee0fe8","selftests/bpf: Ensure bpf_helper_defs.h are taken from selftests dir Reorder includes search path to ensure $(OUTPUT) and $(CURDIR) go before libbpf's directory. Also fix bpf_helpers.h to include bpf_helper_defs.h in such a way as to leverage includes search path. This allows selftests to not use libbpf's local and potentially stale bpf_helper_defs.h. It's important because selftests/bpf's Makefile only re-generates bpf_helper_defs.h in seltests' output directory, not the one in libbpf's directory. Also force regeneration of bpf_helper_defs.h when libbpf.a is updated to reduce staleness. Fixes: fa633a0f8919 (""libbpf: Fix build on read-only filesystems"") Reported-by: Alexei Starovoitov Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200110051716.1591485-3-andriin@fb.com","tools/lib/bpf/bpf_helpers.h | 2 +-; tools/testing/selftests/bpf/Makefile | 12 ++++++------; 2 files changed, 7 insertions(+), 7 deletions(-)","This commit updates the include paths for selftests to use the correct bpf_helper_defs.h directory.","selftests,BPF,Makefile","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"2031af28a42f18cc65ec3aa85b4e5cfdf5ee0fe8","2031af28a42f18cc65ec3aa85b4e5cfdf5ee0fe8","Andrii Nakryiko","andriin@fb.com","1578633434","Alexei Starovoitov","ast@kernel.org","1578635708","6995c76f5a0f89d50ee8501893adc087f427aede","492ab0205f500ebd20b4f0c9e95a1ba007b0c542","libbpf,selftests/bpf: Fix clean targets Libbpf's clean target should clean out generated files in $(OUTPUT) directory and not make assumption that $(OUTPUT) directory is current working directory. Selftest's Makefile should delegate cleaning of libbpf-generated files to libbpf's Makefile. This ensures more robust clean up. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200110051716.1591485-2-andriin@fb.com","tools/lib/bpf/Makefile | 9 +++++----; tools/testing/selftests/bpf/Makefile | 5 +++--; 2 files changed, 8 insertions(+), 6 deletions(-)","Fixes clean targets for libbpf and selftests to ensure robust cleanup of generated files.","libbpf,Makefile,clean","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"492ab0205f500ebd20b4f0c9e95a1ba007b0c542","492ab0205f500ebd20b4f0c9e95a1ba007b0c542","Andrii Nakryiko","andriin@fb.com","1578627766","Alexei Starovoitov","ast@kernel.org","1578633421","46cf10d9d9f327bc4d67268d1b91934a9303e0b5","f5bfcd953d811dbb8913de36b96b38da6bb62135","libbpf: Make bpf_map order and indices stable Currently, libbpf re-sorts bpf_map structs after all the maps are added and initialized, which might change their relative order and invalidate any bpf_map pointer or index taken before that. This is inconvenient and error-prone. For instance, it can cause .kconfig map index to point to a wrong map. Furthermore, libbpf itself doesn't rely on any specific ordering of bpf_maps, so it's just an unnecessary complication right now. This patch drops sorting of maps and makes their relative positions fixed. If efficient index is ever needed, it's better to have a separate array of pointers as a search index, instead of reordering bpf_map struct in-place. This will be less error-prone and will allow multiple independent orderings, if necessary (e.g., either by section index or by name). Fixes: 166750bc1dd2 (""libbpf: Support libbpf-provided extern variables"") Reported-by: Martin KaFai Lau Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200110034247.1220142-1-andriin@fb.com","tools/lib/bpf/libbpf.c | 14 --------------; 1 file changed, 14 deletions(-)","This commit stabilizes the order and indices of bpf_maps in libbpf to prevent errors.","libbpf,bpf_map,indices","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"bf9765145b856fa2e238a5b8a54453795ba30ad6","bf9765145b856fa2e238a5b8a54453795ba30ad6","Mat Martineau","mathew.j.martineau@linux.intel.com","1578585555","David S. Miller","davem@davemloft.net","1578624101","183b344b23e0e55bbb6582521eefdacb3d79d460","e9cdced78dc20c1592c1fb98ed064943007a46c5","sock: Make sk_protocol a 16-bit value Match the 16-bit width of skbuff->protocol. Fills an 8-bit hole so sizeof(struct sock) does not change. Also take care of BPF field access for sk_type/sk_protocol. Both of them are now outside the bitfield, so we can use load instructions without further shifting/masking. v5 -> v6: - update eBPF accessors, too (Intel's kbuild test robot) v2 -> v3: - keep 'sk_type' 2 bytes aligned (Eric) v1 -> v2: - preserve sk_pacing_shift as bit field (Eric) Cc: Alexei Starovoitov Cc: Daniel Borkmann Cc: bpf@vger.kernel.org Co-developed-by: Paolo Abeni Signed-off-by: Paolo Abeni Co-developed-by: Matthieu Baerts Signed-off-by: Matthieu Baerts Signed-off-by: Mat Martineau Signed-off-by: David S. Miller ","include/net/sock.h | 25 ++++---------------; include/trace/events/sock.h | 2 +-; net/core/filter.c | 60 +++++++++++++++++----------------------------; 3 files changed, 28 insertions(+), 59 deletions(-)","This commit changes sk_protocol to a 16-bit value and updates eBPF field access accordingly.","sk_protocol,eBPF,sock","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"36366e367ee93ced84fddb8fae6675e12985f5a4","36366e367ee93ced84fddb8fae6675e12985f5a4","Paul Burton","paulburton@kernel.org","1575570198","Paul Burton","paulburton@kernel.org","1578610950","bb3178a7acc61062a0c9af493bea1fbc766b7df1","11d06df7b9f29ec5898901c2c94a58f4ecf60446","MIPS: BPF: Restore MIPS32 cBPF JIT Commit 716850ab104d (""MIPS: eBPF: Initial eBPF support for MIPS32 architecture."") enabled our eBPF JIT for MIPS32 kernels, whereas it has previously only been availailable for MIPS64. It was my understanding at the time that the BPF test suite was passing & JITing a comparable number of tests to our cBPF JIT [1], but it turns out that was not the case. The eBPF JIT has a number of problems on MIPS32: - Most notably various code paths still result in emission of MIPS64 instructions which will cause reserved instruction exceptions & kernel panics when run on MIPS32 CPUs. - The eBPF JIT doesn't account for differences between the O32 ABI used by MIPS32 kernels versus the N64 ABI used by MIPS64 kernels. Notably arguments beyond the first 4 are passed on the stack in O32, and this is entirely unhandled when JITing a BPF_CALL instruction. Stack space must be reserved for arguments even if they all fit in registers, and the callee is free to assume that stack space has been reserved for its use - with the eBPF JIT this is not the case, so calling any function can result in clobbering values on the stack & unpredictable behaviour. Function arguments in eBPF are always 64-bit values which is also entirely unhandled - the JIT still uses a single (32-bit) register per argument. As a result all function arguments are always passed incorrectly when JITing a BPF_CALL instruction, leading to kernel crashes or strange behavior. - The JIT attempts to bail our on use of ALU64 instructions or 64-bit memory access instructions. The code doing this at the start of build_one_insn() incorrectly checks whether BPF_OP() equals BPF_DW, when it should really be checking BPF_SIZE() & only doing so when BPF_CLASS() is one of BPF_{LD,LDX,ST,STX}. This results in false positives that cause more bailouts than intended, and that in turns hides some of the problems described above. - The kernel's cBPF->eBPF translation makes heavy use of 64-bit eBPF instructions that the MIPS32 eBPF JIT bails out on, leading to most cBPF programs not being JITed at all. Until these problems are resolved, revert the removal of the cBPF JIT performed by commit 716850ab104d (""MIPS: eBPF: Initial eBPF support for MIPS32 architecture.""). Together with commit f8fffebdea75 (""MIPS: BPF: Disable MIPS32 eBPF JIT"") this restores MIPS32 BPF JIT behavior back to the same state it was prior to the introduction of the broken eBPF JIT support. [1] https://lore.kernel.org/linux-mips/MWHPR2201MB13583388481F01A422CE7D66D4410@MWHPR2201MB1358.namprd22.prod.outlook.com/ Signed-off-by: Paul Burton Fixes: 716850ab104d (""MIPS: eBPF: Initial eBPF support for MIPS32 architecture."") Cc: Daniel Borkmann Cc: Hassan Naveed Cc: Tony Ambardar Cc: bpf@vger.kernel.org Cc: netdev@vger.kernel.org Cc: linux-mips@vger.kernel.org Cc: linux-kernel@vger.kernel.org","arch/mips/Kconfig | 1 +; arch/mips/net/Makefile | 1 +; arch/mips/net/bpf_jit.c | 1270 +++++++++++++++++++++++++++++++++++++++++++; arch/mips/net/bpf_jit_asm.S | 285 ++++++++++; 4 files changed, 1557 insertions(+)","The commit restores the MIPS32 cBPF JIT due to unresolved issues with the eBPF JIT on MIPS32 architecture.","MIPS32,JIT,restore","A bug fix. It primarily resolves a bug or issue in the code.","Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"e7a5f1f1cd0008e5ad379270a8657e121eedb669","e7a5f1f1cd0008e5ad379270a8657e121eedb669","Lingpeng Chen","forrest0579@gmail.com","1578534513","Daniel Borkmann","daniel@iogearbox.net","1578608028","dadfdc408f412c057c4fb1bb74b38fc0578d6bc0","da29f2d84bd10234df570b7f07cbd0166e738230","bpf/sockmap: Read psock ingress_msg before sk_receive_queue Right now in tcp_bpf_recvmsg, sock read data first from sk_receive_queue if not empty than psock->ingress_msg otherwise. If a FIN packet arrives and there's also some data in psock->ingress_msg, the data in psock->ingress_msg will be purged. It is always happen when request to a HTTP1.0 server like python SimpleHTTPServer since the server send FIN packet after data is sent out. Fixes: 604326b41a6fb (""bpf, sockmap: convert to generic sk_msg interface"") Reported-by: Arika Chen Suggested-by: Arika Chen Signed-off-by: Lingpeng Chen Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200109014833.18951-1-forrest0579@gmail.com","net/ipv4/tcp_bpf.c | 12 ++++++------; 1 file changed, 6 insertions(+), 6 deletions(-)","This commit fixes a bug in tcp_bpf_recvmsg to correctly handle psock ingress_msg before sk_receive_queue after a FIN packet.","sockmap ingress_msg tcp_bpf_recvmsg","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.', ""It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here."", ""It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.""]" +"a5f48c7878d2365f6ff7008e9317abbc16f68847","a5f48c7878d2365f6ff7008e9317abbc16f68847","Linus Torvalds","torvalds@linux-foundation.org","1578594847","Linus Torvalds","torvalds@linux-foundation.org","1578594847","160311e302f91aecdc1fd160f4a7f6bd7673da30","b07f636fca1c8fbba124b0082487c0b3890a0e0c 9546a0b7ce0077d827470f603f2522b845ce5954","Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from David Miller: 1) Missing netns pointer init in arp_tables, from Florian Westphal. 2) Fix normal tcp SACK being treated as D-SACK, from Pengcheng Yang. 3) Fix divide by zero in sch_cake, from Wen Yang. 4) Len passed to skb_put_padto() is wrong in qrtr code, from Carl Huang. 5) cmd->obj.chunk is leaked in sctp code error paths, from Xin Long. 6) cgroup bpf programs can be released out of order, fix from Roman Gushchin. 7) Make sure stmmac debugfs entry name is changed when device name changes, from Jiping Ma. 8) Fix memory leak in vlan_dev_set_egress_priority(), from Eric Dumazet. 9) SKB leak in lan78xx usb driver, also from Eric Dumazet. 10) Ridiculous TCA_FQ_QUANTUM values configured can cause loops in fq packet scheduler, reject them. From Eric Dumazet. * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (69 commits) tipc: fix wrong connect() return code tipc: fix link overflow issue at socket shutdown netfilter: ipset: avoid null deref when IPSET_ATTR_LINENO is present netfilter: conntrack: dccp, sctp: handle null timeout argument atm: eni: fix uninitialized variable warning macvlan: do not assume mac_header is set in macvlan_broadcast() net: sch_prio: When ungrafting, replace with FIFO mlxsw: spectrum_qdisc: Ignore grafting of invisible FIFO MAINTAINERS: Remove myself as co-maintainer for qcom-ethqos gtp: fix bad unlock balance in gtp_encap_enable_socket pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM tipc: remove meaningless assignment in Makefile tipc: do not add socket.o to tipc-y twice net: stmmac: dwmac-sun8i: Allow all RGMII modes net: stmmac: dwmac-sunxi: Allow all RGMII modes net: usb: lan78xx: fix possible skb leak net: stmmac: Fixed link does not need MDIO Bus vlan: vlan_changelink() should propagate errors vlan: fix memory leak in vlan_dev_set_egress_priority stmmac: debugfs entry name is not be changed when udev rename device name. ...","","Merge commit integrating various networking fixes addressing issues like netns pointer initialization and TCP SACK handling.","networking,fixes,merge","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"f5bfcd953d811dbb8913de36b96b38da6bb62135","f5bfcd953d811dbb8913de36b96b38da6bb62135","Andrey Ignatov","rdna@fb.com","1578447606","Alexei Starovoitov","ast@kernel.org","1578591606","ad65489a49e1c9a2b54411bff64256c5d6a30159","417759f7d4cf44a5fb526fbafcc9372e3dbfc0ae","bpf: Document BPF_F_QUERY_EFFECTIVE flag Document BPF_F_QUERY_EFFECTIVE flag, mostly to clarify how it affects attach_flags what may not be obvious and what may lead to confision. Specifically attach_flags is returned only for target_fd but if programs are inherited from an ancestor cgroup then returned attach_flags for current cgroup may be confusing. For example, two effective programs of same attach_type can be returned but w/o BPF_F_ALLOW_MULTI in attach_flags. Simple repro: # bpftool c s /sys/fs/cgroup/path/to/task ID AttachType AttachFlags Name # bpftool c s /sys/fs/cgroup/path/to/task effective ID AttachType AttachFlags Name 95043 ingress tw_ipt_ingress 95048 ingress tw_ingress Signed-off-by: Andrey Ignatov Signed-off-by: Alexei Starovoitov Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200108014006.938363-1-rdna@fb.com","include/uapi/linux/bpf.h | 7 ++++++-; tools/include/uapi/linux/bpf.h | 7 ++++++-; 2 files changed, 12 insertions(+), 2 deletions(-)","The commit documents the BPF_F_QUERY_EFFECTIVE flag to clarify its impact on attach_flags in cgroup scenarios.","BPF_F_QUERY_EFFECTIVE,attach_flags,cgroup","A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The syscall interface. It changes the system calls through which user-space programs interact with eBPF.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","['cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups).']" +"417759f7d4cf44a5fb526fbafcc9372e3dbfc0ae","417759f7d4cf44a5fb526fbafcc9372e3dbfc0ae","Alexei Starovoitov","ast@kernel.org","1578588379","Alexei Starovoitov","ast@kernel.org","1578590125","c07bf1d77af64ba689ace342512ccbbc0c2d6a00","65726b5b7efae718391752ae8bb85b9843fd83f4 09903869f69f37fd7a465183545b5739c6274654","Merge branch 'tcp-bpf-cc' Martin Lau says: ==================== This series introduces BPF STRUCT_OPS. It is an infra to allow implementing some specific kernel's function pointers in BPF. The first use case included in this series is to implement TCP congestion control algorithm in BPF (i.e. implement struct tcp_congestion_ops in BPF). There has been attempt to move the TCP CC to the user space (e.g. CCP in TCP). The common arguments are faster turn around, get away from long-tail kernel versions in production...etc, which are legit points. BPF has been the continuous effort to join both kernel and userspace upsides together (e.g. XDP to gain the performance advantage without bypassing the kernel). The recent BPF advancements (in particular BTF-aware verifier, BPF trampoline, BPF CO-RE...) made implementing kernel struct ops (e.g. tcp cc) possible in BPF. The idea is to allow implementing tcp_congestion_ops in bpf. It allows a faster turnaround for testing algorithm in the production while leveraging the existing (and continue growing) BPF feature/framework instead of building one specifically for userspace TCP CC. Please see individual patch for details. The bpftool support will be posted in follow-up patches. v4: - Expose tcp_ca_find() to tcp.h in patch 7. It is used to check the same bpf-tcp-cc does not exist to guarantee the register() will succeed. - set_memory_ro() and then set_memory_x() only after all trampolines are written to the image in patch 6. (Daniel) spinlock is replaced by mutex because set_memory_* requires sleepable context. v3: - Fix kbuild error by considering CONFIG_BPF_SYSCALL (kbuild) - Support anonymous bitfield in patch 4 (Andrii, Yonghong) - Push boundary safety check to a specific arch's trampoline function (in patch 6) (Yonghong). Reuse the WANR_ON_ONCE check in arch_prepare_bpf_trampoline() in x86. - Check module field is 0 in udata in patch 6 (Yonghong) - Check zero holes in patch 6 (Andrii) - s/_btf_vmlinux/btf/ in patch 5 and 7 (Andrii) - s/check_xxx/is_xxx/ in patch 7 (Andrii) - Use ""struct_ops/"" convention in patch 11 (Andrii) - Use the skel instead of bpf_object in patch 11 (Andrii) - libbpf: Decide BPF_PROG_TYPE_STRUCT_OPS at open phase by using find_sec_def() - libbpf: Avoid a debug message at open phase (Andrii) - libbpf: Add bpf_program__(is|set)_struct_ops() for consistency (Andrii) - libbpf: Add ""struct_ops"" to section_defs (Andrii) - libbpf: Some code shuffling in init_kern_struct_ops() (Andrii) - libbpf: A few safety checks (Andrii) v2: - Dropped cubic for now. They will be reposted once there are more clarity in ""jiffies"" on both bpf side (about the helper) and tcp_cubic side (some of jiffies usages are being replaced by tp->tcp_mstamp) - Remove unnecssary check on bitfield support from btf_struct_access() (Yonghong) - BTF_TYPE_EMIT macro (Yonghong, Andrii) - value_name's length check to avoid an unlikely type match during truncation case (Yonghong) - BUILD_BUG_ON to ensure no trampoline-image overrun in the future (Yonghong) - Simplify get_next_key() (Yonghong) - Added comment to explain how to check mandatory func ptr in net/ipv4/bpf_tcp_ca.c (Yonghong) - Rename ""__bpf_"" to ""bpf_struct_ops_"" for value prefix (Andrii) - Add comment to highlight the bpf_dctcp.c is not necessarily the same as tcp_dctcp.c. (Alexei, Eric) - libbpf: Renmae ""struct_ops"" to "".struct_ops"" for elf sec (Andrii) - libbpf: Expose struct_ops as a bpf_map (Andrii) - libbpf: Support multiple struct_ops in SEC("".struct_ops"") (Andrii) - libbpf: Add bpf_map__attach_struct_ops() (Andrii) ==================== Signed-off-by: Alexei Starovoitov ","","The commit merges changes that introduce BPF STRUCT_OPS for implementing TCP congestion control algorithms in BPF.","BPF, STRUCT_OPS, TCP","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"09903869f69f37fd7a465183545b5739c6274654","09903869f69f37fd7a465183545b5739c6274654","Martin KaFai Lau","kafai@fb.com","1578530117","Alexei Starovoitov","ast@kernel.org","1578588378","c07bf1d77af64ba689ace342512ccbbc0c2d6a00","590a0088825016ca7ec53f1aef7e84e1211778d8","bpf: Add bpf_dctcp example This patch adds a bpf_dctcp example. It currently does not do no-ECN fallback but the same could be done through the cgrp2-bpf. Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200109003517.3856825-1-kafai@fb.com","tools/testing/selftests/bpf/bpf_tcp_helpers.h | 228 +++++++++++++++++++++; .../testing/selftests/bpf/prog_tests/bpf_tcp_ca.c | 187 +++++++++++++++++; tools/testing/selftests/bpf/progs/bpf_dctcp.c | 210 +++++++++++++++++++; 3 files changed, 625 insertions(+)","The commit adds an example program demonstrating bpf_dctcp functionality for self-tests in the bpf subsystem.","bpf, dctcp, example","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups).', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime."", ""I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear.""]" +"590a0088825016ca7ec53f1aef7e84e1211778d8","590a0088825016ca7ec53f1aef7e84e1211778d8","Martin KaFai Lau","kafai@fb.com","1578530114","Alexei Starovoitov","ast@kernel.org","1578588378","52b5cbb3c88cd6600754c545453e2e00b38e7091","17328d618c17e0c8deab892ac227efcd55957e4d","bpf: libbpf: Add STRUCT_OPS support This patch adds BPF STRUCT_OPS support to libbpf. The only sec_name convention is SEC("".struct_ops"") to identify the struct_ops implemented in BPF, e.g. To implement a tcp_congestion_ops: SEC("".struct_ops"") struct tcp_congestion_ops dctcp = { .init = (void *)dctcp_init, /* <-- a bpf_prog */ /* ... some more func prts ... */ .name = ""bpf_dctcp"", }; Each struct_ops is defined as a global variable under SEC("".struct_ops"") as above. libbpf creates a map for each variable and the variable name is the map's name. Multiple struct_ops is supported under SEC("".struct_ops""). In the bpf_object__open phase, libbpf will look for the SEC("".struct_ops"") section and find out what is the btf-type the struct_ops is implementing. Note that the btf-type here is referring to a type in the bpf_prog.o's btf. A ""struct bpf_map"" is added by bpf_object__add_map() as other maps do. It will then collect (through SHT_REL) where are the bpf progs that the func ptrs are referring to. No btf_vmlinux is needed in the open phase. In the bpf_object__load phase, the map-fields, which depend on the btf_vmlinux, are initialized (in bpf_map__init_kern_struct_ops()). It will also set the prog->type, prog->attach_btf_id, and prog->expected_attach_type. Thus, the prog's properties do not rely on its section name. [ Currently, the bpf_prog's btf-type ==> btf_vmlinux's btf-type matching process is as simple as: member-name match + btf-kind match + size match. If these matching conditions fail, libbpf will reject. The current targeting support is ""struct tcp_congestion_ops"" which most of its members are function pointers. The member ordering of the bpf_prog's btf-type can be different from the btf_vmlinux's btf-type. ] Then, all obj->maps are created as usual (in bpf_object__create_maps()). Once the maps are created and prog's properties are all set, the libbpf will proceed to load all the progs. bpf_map__attach_struct_ops() is added to register a struct_ops map to a kernel subsystem. Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200109003514.3856730-1-kafai@fb.com","tools/lib/bpf/bpf.c | 10 +-; tools/lib/bpf/bpf.h | 5 +-; tools/lib/bpf/libbpf.c | 649 +++++++++++++++++++++++++++++++++++++++++-; tools/lib/bpf/libbpf.h | 5 +-; tools/lib/bpf/libbpf.map | 3 +; tools/lib/bpf/libbpf_probes.c | 2 +; 6 files changed, 661 insertions(+), 13 deletions(-)","This commit introduces STRUCT_OPS support to libbpf by adding functionality to handle BPF program struct operations.","STRUCT_OPS,libbpf,BPF","A new feature. It adds a new capability or feature that was not previously present.","Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems.']" +"17328d618c17e0c8deab892ac227efcd55957e4d","17328d618c17e0c8deab892ac227efcd55957e4d","Martin KaFai Lau","kafai@fb.com","1578530112","Alexei Starovoitov","ast@kernel.org","1578588378","bc3ab8cbbbbff9124e3b603d926078e3062506b8","206057fe020ac5c037d5e2dd6562a9bd216ec765","bpf: Synch uapi bpf.h to tools/ This patch sync uapi bpf.h to tools/ Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200109003512.3856559-1-kafai@fb.com","tools/include/uapi/linux/bpf.h | 19 +++++++++++++++++--; 1 file changed, 17 insertions(+), 2 deletions(-)","This commit synchronizes the uapi bpf.h header file to the tools directory.","synchronize,uapi,bpf","A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"206057fe020ac5c037d5e2dd6562a9bd216ec765","206057fe020ac5c037d5e2dd6562a9bd216ec765","Martin KaFai Lau","kafai@fb.com","1578530751","Alexei Starovoitov","ast@kernel.org","1578588378","4e4b87e6b400b03b472793c007485d5df57584a9","0baf26b0fcd74bbfcef53c5d5e8bad2b99c8d0d2","bpf: Add BPF_FUNC_tcp_send_ack helper Add a helper to send out a tcp-ack. It will be used in the later bpf_dctcp implementation that requires to send out an ack when the CE state changed. Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200109004551.3900448-1-kafai@fb.com","include/uapi/linux/bpf.h | 11 ++++++++++-; net/ipv4/bpf_tcp_ca.c | 24 +++++++++++++++++++++++-; 2 files changed, 33 insertions(+), 2 deletions(-)","Add a helper function BPF_FUNC_tcp_send_ack to send TCP acknowledgments, supporting future bpf_dctcp implementation.","helper,tcp-ack,bpf_dctcp","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"0baf26b0fcd74bbfcef53c5d5e8bad2b99c8d0d2","0baf26b0fcd74bbfcef53c5d5e8bad2b99c8d0d2","Martin KaFai Lau","kafai@fb.com","1578530108","Alexei Starovoitov","ast@kernel.org","1578588378","93c4e390a842dbf29bc83e53f5098c14cf07c869","85d33df357b634649ddbe0a20fd2d0fc5732c3cb","bpf: tcp: Support tcp_congestion_ops in bpf This patch makes ""struct tcp_congestion_ops"" to be the first user of BPF STRUCT_OPS. It allows implementing a tcp_congestion_ops in bpf. The BPF implemented tcp_congestion_ops can be used like regular kernel tcp-cc through sysctl and setsockopt. e.g. [root@arch-fb-vm1 bpf]# sysctl -a | egrep congestion net.ipv4.tcp_allowed_congestion_control = reno cubic bpf_cubic net.ipv4.tcp_available_congestion_control = reno bic cubic bpf_cubic net.ipv4.tcp_congestion_control = bpf_cubic There has been attempt to move the TCP CC to the user space (e.g. CCP in TCP). The common arguments are faster turn around, get away from long-tail kernel versions in production...etc, which are legit points. BPF has been the continuous effort to join both kernel and userspace upsides together (e.g. XDP to gain the performance advantage without bypassing the kernel). The recent BPF advancements (in particular BTF-aware verifier, BPF trampoline, BPF CO-RE...) made implementing kernel struct ops (e.g. tcp cc) possible in BPF. It allows a faster turnaround for testing algorithm in the production while leveraging the existing (and continue growing) BPF feature/framework instead of building one specifically for userspace TCP CC. This patch allows write access to a few fields in tcp-sock (in bpf_tcp_ca_btf_struct_access()). The optional ""get_info"" is unsupported now. It can be added later. One possible way is to output the info with a btf-id to describe the content. Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200109003508.3856115-1-kafai@fb.com","include/linux/filter.h | 2 +; include/net/tcp.h | 2 +; kernel/bpf/bpf_struct_ops_types.h | 7 +-; net/core/filter.c | 2 +-; net/ipv4/Makefile | 4 +; net/ipv4/bpf_tcp_ca.c | 230 ++++++++++++++++++++++++++++++++++++++; net/ipv4/tcp_cong.c | 16 +--; net/ipv4/tcp_ipv4.c | 6 +-; net/ipv4/tcp_minisocks.c | 4 +-; net/ipv4/tcp_output.c | 4 +-; 10 files changed, 261 insertions(+), 16 deletions(-)","This commit enables implementation of TCP congestion control operations using BPF in the kernel via STRUCT_OPS for faster integration and experimentation.","tcp congestion bpf","A new feature. It adds a new capability or feature that was not previously present.","Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.","The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['tc related type programs. It affects programs managing traffic control (tc) for queuing or prioritizing network traffic.', 'Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"85d33df357b634649ddbe0a20fd2d0fc5732c3cb","85d33df357b634649ddbe0a20fd2d0fc5732c3cb","Martin KaFai Lau","kafai@fb.com","1578530105","Alexei Starovoitov","ast@kernel.org","1578588378","f568eea4c6ac6e33555a2923fa821f47914ec5f3","27ae7997a66174cb8afd6a75b3989f5e0c1b9e5a","bpf: Introduce BPF_MAP_TYPE_STRUCT_OPS The patch introduces BPF_MAP_TYPE_STRUCT_OPS. The map value is a kernel struct with its func ptr implemented in bpf prog. This new map is the interface to register/unregister/introspect a bpf implemented kernel struct. The kernel struct is actually embedded inside another new struct (or called the ""value"" struct in the code). For example, ""struct tcp_congestion_ops"" is embbeded in: struct bpf_struct_ops_tcp_congestion_ops { refcount_t refcnt; enum bpf_struct_ops_state state; struct tcp_congestion_ops data; /* <-- kernel subsystem struct here */ } The map value is ""struct bpf_struct_ops_tcp_congestion_ops"". The ""bpftool map dump"" will then be able to show the state (""inuse""/""tobefree"") and the number of subsystem's refcnt (e.g. number of tcp_sock in the tcp_congestion_ops case). This ""value"" struct is created automatically by a macro. Having a separate ""value"" struct will also make extending ""struct bpf_struct_ops_XYZ"" easier (e.g. adding ""void (*init)(void)"" to ""struct bpf_struct_ops_XYZ"" to do some initialization works before registering the struct_ops to the kernel subsystem). The libbpf will take care of finding and populating the ""struct bpf_struct_ops_XYZ"" from ""struct XYZ"". Register a struct_ops to a kernel subsystem: 1. Load all needed BPF_PROG_TYPE_STRUCT_OPS prog(s) 2. Create a BPF_MAP_TYPE_STRUCT_OPS with attr->btf_vmlinux_value_type_id set to the btf id ""struct bpf_struct_ops_tcp_congestion_ops"" of the running kernel. Instead of reusing the attr->btf_value_type_id, btf_vmlinux_value_type_id s added such that attr->btf_fd can still be used as the ""user"" btf which could store other useful sysadmin/debug info that may be introduced in the furture, e.g. creation-date/compiler-details/map-creator...etc. 3. Create a ""struct bpf_struct_ops_tcp_congestion_ops"" object as described in the running kernel btf. Populate the value of this object. The function ptr should be populated with the prog fds. 4. Call BPF_MAP_UPDATE with the object created in (3) as the map value. The key is always ""0"". During BPF_MAP_UPDATE, the code that saves the kernel-func-ptr's args as an array of u64 is generated. BPF_MAP_UPDATE also allows the specific struct_ops to do some final checks in ""st_ops->init_member()"" (e.g. ensure all mandatory func ptrs are implemented). If everything looks good, it will register this kernel struct to the kernel subsystem. The map will not allow further update from this point. Unregister a struct_ops from the kernel subsystem: BPF_MAP_DELETE with key ""0"". Introspect a struct_ops: BPF_MAP_LOOKUP_ELEM with key ""0"". The map value returned will have the prog _id_ populated as the func ptr. The map value state (enum bpf_struct_ops_state) will transit from: INIT (map created) => INUSE (map updated, i.e. reg) => TOBEFREE (map value deleted, i.e. unreg) The kernel subsystem needs to call bpf_struct_ops_get() and bpf_struct_ops_put() to manage the ""refcnt"" in the ""struct bpf_struct_ops_XYZ"". This patch uses a separate refcnt for the purose of tracking the subsystem usage. Another approach is to reuse the map->refcnt and then ""show"" (i.e. during map_lookup) the subsystem's usage by doing map->refcnt - map->usercnt to filter out the map-fd/pinned-map usage. However, that will also tie down the future semantics of map->refcnt and map->usercnt. The very first subsystem's refcnt (during reg()) holds one count to map->refcnt. When the very last subsystem's refcnt is gone, it will also release the map->refcnt. All bpf_prog will be freed when the map->refcnt reaches 0 (i.e. during map_free()). Here is how the bpftool map command will look like: [root@arch-fb-vm1 bpf]# bpftool map show 6: struct_ops name dctcp flags 0x0 key 4B value 256B max_entries 1 memlock 4096B btf_id 6 [root@arch-fb-vm1 bpf]# bpftool map dump id 6 [{ ""value"": { ""refcnt"": { ""refs"": { ""counter"": 1 } }, ""state"": 1, ""data"": { ""list"": { ""next"": 0, ""prev"": 0 }, ""key"": 0, ""flags"": 2, ""init"": 24, ""release"": 0, ""ssthresh"": 25, ""cong_avoid"": 30, ""set_state"": 27, ""cwnd_event"": 28, ""in_ack_event"": 26, ""undo_cwnd"": 29, ""pkts_acked"": 0, ""min_tso_segs"": 0, ""sndbuf_expand"": 0, ""cong_control"": 0, ""get_info"": 0, ""name"": [98,112,102,95,100,99,116,99,112,0,0,0,0,0,0,0 ], ""owner"": 0 } } } ] Misc Notes: * bpf_struct_ops_map_sys_lookup_elem() is added for syscall lookup. It does an inplace update on ""*value"" instead returning a pointer to syscall.c. Otherwise, it needs a separate copy of ""zero"" value for the BPF_STRUCT_OPS_STATE_INIT to avoid races. * The bpf_struct_ops_map_delete_elem() is also called without preempt_disable() from map_delete_elem(). It is because the ""->unreg()"" may requires sleepable context, e.g. the ""tcp_unregister_congestion_control()"". * ""const"" is added to some of the existing ""struct btf_func_model *"" function arg to avoid a compiler warning caused by this patch. Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200109003505.3855919-1-kafai@fb.com","arch/x86/net/bpf_jit_comp.c | 18 +-; include/linux/bpf.h | 49 ++++-; include/linux/bpf_types.h | 3 +; include/linux/btf.h | 13 ++; include/uapi/linux/bpf.h | 7 +-; kernel/bpf/bpf_struct_ops.c | 511 +++++++++++++++++++++++++++++++++++++++++++-; kernel/bpf/btf.c | 20 +-; kernel/bpf/map_in_map.c | 3 +-; kernel/bpf/syscall.c | 52 +++--; kernel/bpf/trampoline.c | 8 +-; kernel/bpf/verifier.c | 5 +; 11 files changed, 642 insertions(+), 47 deletions(-)","This commit introduces BPF_MAP_TYPE_STRUCT_OPS for eBPF, facilitating struct operations integration with kernel subsystems.","BPF_MAP_TYPE_STRUCT_OPS,kernel struct,eBPF","A new feature. It adds a new capability or feature that was not previously present.","Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems.']" +"27ae7997a66174cb8afd6a75b3989f5e0c1b9e5a","27ae7997a66174cb8afd6a75b3989f5e0c1b9e5a","Martin KaFai Lau","kafai@fb.com","1578530103","Alexei Starovoitov","ast@kernel.org","1578588378","cd309990484990799c2577f51cf027941ebd4b0c","976aba002fcb4b1baa71e4b0854f3d4ae48c1d4d","bpf: Introduce BPF_PROG_TYPE_STRUCT_OPS This patch allows the kernel's struct ops (i.e. func ptr) to be implemented in BPF. The first use case in this series is the ""struct tcp_congestion_ops"" which will be introduced in a latter patch. This patch introduces a new prog type BPF_PROG_TYPE_STRUCT_OPS. The BPF_PROG_TYPE_STRUCT_OPS prog is verified against a particular func ptr of a kernel struct. The attr->attach_btf_id is the btf id of a kernel struct. The attr->expected_attach_type is the member ""index"" of that kernel struct. The first member of a struct starts with member index 0. That will avoid ambiguity when a kernel struct has multiple func ptrs with the same func signature. For example, a BPF_PROG_TYPE_STRUCT_OPS prog is written to implement the ""init"" func ptr of the ""struct tcp_congestion_ops"". The attr->attach_btf_id is the btf id of the ""struct tcp_congestion_ops"" of the _running_ kernel. The attr->expected_attach_type is 3. The ctx of BPF_PROG_TYPE_STRUCT_OPS is an array of u64 args saved by arch_prepare_bpf_trampoline that will be done in the next patch when introducing BPF_MAP_TYPE_STRUCT_OPS. ""struct bpf_struct_ops"" is introduced as a common interface for the kernel struct that supports BPF_PROG_TYPE_STRUCT_OPS prog. The supporting kernel struct will need to implement an instance of the ""struct bpf_struct_ops"". The supporting kernel struct also needs to implement a bpf_verifier_ops. During BPF_PROG_LOAD, bpf_struct_ops_find() will find the right bpf_verifier_ops by searching the attr->attach_btf_id. A new ""btf_struct_access"" is also added to the bpf_verifier_ops such that the supporting kernel struct can optionally provide its own specific check on accessing the func arg (e.g. provide limited write access). After btf_vmlinux is parsed, the new bpf_struct_ops_init() is called to initialize some values (e.g. the btf id of the supporting kernel struct) and it can only be done once the btf_vmlinux is available. The R0 checks at BPF_EXIT is excluded for the BPF_PROG_TYPE_STRUCT_OPS prog if the return type of the prog->aux->attach_func_proto is ""void"". Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200109003503.3855825-1-kafai@fb.com","include/linux/bpf.h | 30 +++++++++; include/linux/bpf_types.h | 4 ++; include/linux/btf.h | 34 ++++++++++; include/uapi/linux/bpf.h | 1 +; kernel/bpf/Makefile | 3 +; kernel/bpf/bpf_struct_ops.c | 121 ++++++++++++++++++++++++++++++++++; kernel/bpf/bpf_struct_ops_types.h | 4 ++; kernel/bpf/btf.c | 88 +++++++++++++++++--------; kernel/bpf/syscall.c | 17 +++--; kernel/bpf/verifier.c | 134 +++++++++++++++++++++++++++++---------; 10 files changed, 373 insertions(+), 63 deletions(-)","This commit introduces a new eBPF program type, BPF_PROG_TYPE_STRUCT_OPS, allowing struct operation implementations in BPF.","BPF,struct_ops,program","A new feature. It adds a new capability or feature that was not previously present.","Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.","The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","['Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems.']" +"976aba002fcb4b1baa71e4b0854f3d4ae48c1d4d","976aba002fcb4b1baa71e4b0854f3d4ae48c1d4d","Martin KaFai Lau","kafai@fb.com","1578530101","Alexei Starovoitov","ast@kernel.org","1578588378","cfd45993bac0afa64b8bc0ae9685c2ad6273d7b1","218b3f65f9081f5e1bffe6de5f0f4b22c935410b","bpf: Support bitfield read access in btf_struct_access This patch allows bitfield access as a scalar. It checks ""off + size > t->size"" to avoid accessing bitfield end up accessing beyond the struct. This check is done outside of the loop since it is applicable to all access. It also takes this chance to break early on the ""off < moff"" case. Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200109003501.3855427-1-kafai@fb.com","kernel/bpf/btf.c | 44 +++++++++++++++++++++++++++++++++++++++-----; 1 file changed, 39 insertions(+), 5 deletions(-)","This commit adds support for bitfield read access in btf_struct_access within the BPF subsystem.","bitfield, access, btf","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.","BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"218b3f65f9081f5e1bffe6de5f0f4b22c935410b","218b3f65f9081f5e1bffe6de5f0f4b22c935410b","Martin KaFai Lau","kafai@fb.com","1578530099","Alexei Starovoitov","ast@kernel.org","1578588378","9d66fc821e86ac07295f33718371c80390838e46","275517ff452a535da5eef25b1c22e53fc50b0a12","bpf: Add enum support to btf_ctx_access() It allows bpf prog (e.g. tracing) to attach to a kernel function that takes enum argument. Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200109003459.3855366-1-kafai@fb.com","kernel/bpf/btf.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","This commit adds enum support to btf_ctx_access for bpf programs to attach to kernel functions with enum arguments.","bpf, enum, btf_ctx_access","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.","BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.']" +"275517ff452a535da5eef25b1c22e53fc50b0a12","275517ff452a535da5eef25b1c22e53fc50b0a12","Martin KaFai Lau","kafai@fb.com","1578530096","Alexei Starovoitov","ast@kernel.org","1578588378","575a22cc0151a9fae57ebd2c23f3c58f77b20b02","65726b5b7efae718391752ae8bb85b9843fd83f4","bpf: Avoid storing modifier to info->btf_id info->btf_id expects the btf_id of a struct, so it should store the final result after skipping modifiers (if any). It also takes this chanace to add a missing newline in one of the bpf_log() messages. Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200109003456.3855176-1-kafai@fb.com","kernel/bpf/btf.c | 9 ++++++---; 1 file changed, 6 insertions(+), 3 deletions(-)","This commit corrects the storage of BTF IDs by skipping modifiers and fixes a log message formatting issue.","btf_id, modifier, fix","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.","BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"65726b5b7efae718391752ae8bb85b9843fd83f4","65726b5b7efae718391752ae8bb85b9843fd83f4","Martin KaFai Lau","kafai@fb.com","1578530094","Alexei Starovoitov","ast@kernel.org","1578588332","4e07d0e4334e550a892f4a05dc89fc1706329aa5","e43002242a47e8d7b2f9446f54de982f09e7dbd1","bpf: Save PTR_TO_BTF_ID register state when spilling to stack This patch makes the verifier save the PTR_TO_BTF_ID register state when spilling to the stack. Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200109003454.3854870-1-kafai@fb.com","kernel/bpf/verifier.c | 1 +; 1 file changed, 1 insertion(+)","The commit updates the eBPF verifier to save PTR_TO_BTF_ID register state when spilling to the stack.","verifier,PTR_TO_BTF_ID,stack","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"e43002242a47e8d7b2f9446f54de982f09e7dbd1","e43002242a47e8d7b2f9446f54de982f09e7dbd1","Stanislav Fomichev","sdf@google.com","1578511292","Alexei Starovoitov","ast@kernel.org","1578588127","f60e38d0eed3125391cb1677beab3e3b85ba7e93","2faef64aa6b3c94c940c3a62ed22f3af4980223a","selftests/bpf: Restore original comm in test_overhead test_overhead changes task comm in order to estimate BPF trampoline overhead but never sets the comm back to the original one. We have the tests (like core_reloc.c) that have 'test_progs' as hard-coded expected comm, so let's try to preserve the original comm. Currently, everything works because the order of execution is: first core_recloc, then test_overhead; but let's make it a bit future-proof. Other related changes: use 'test_overhead' as new comm instead of 'test' to make it easy to debug and drop '\n' at the end. Signed-off-by: Stanislav Fomichev Signed-off-by: Alexei Starovoitov Acked-by: Petar Penkov Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200108192132.189221-1-sdf@google.com","tools/testing/selftests/bpf/prog_tests/test_overhead.c | 8 +++++++-; 1 file changed, 7 insertions(+), 1 deletion(-)","The commit fixes the task comm restoration in test_overhead to ensure test consistency.","comm,test,overhead","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"2faef64aa6b3c94c940c3a62ed22f3af4980223a","2faef64aa6b3c94c940c3a62ed22f3af4980223a","Michal Rostecki","mrostecki@opensuse.org","1578500633","Daniel Borkmann","daniel@iogearbox.net","1578508485","3591ae414b4de4232dcba6941d8a2464e4b6a184","5ff051200308ab6f4c64c0fe52187bf4a1234dac","bpftool: Add misc section and probe for large INSN limit Introduce a new probe section (misc) for probes not related to concrete map types, program types, functions or kernel configuration. Introduce a probe for large INSN limit as the first one in that section. Example outputs: # bpftool feature probe [...] Scanning miscellaneous eBPF features... Large program size limit is available # bpftool feature probe macros [...] /*** eBPF misc features ***/ #define HAVE_HAVE_LARGE_INSN_LIMIT # bpftool feature probe -j | jq '.[""misc""]' { ""have_large_insn_limit"": true } Signed-off-by: Michal Rostecki Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200108162428.25014-3-mrostecki@opensuse.org","tools/bpf/bpftool/feature.c | 18 ++++++++++++++++++; 1 file changed, 18 insertions(+)","The commit adds a new probe for large instruction limits in the bpftool's miscellaneous section.","bpftool,probe,insn","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"5ff051200308ab6f4c64c0fe52187bf4a1234dac","5ff051200308ab6f4c64c0fe52187bf4a1234dac","Michal Rostecki","mrostecki@opensuse.org","1578500632","Daniel Borkmann","daniel@iogearbox.net","1578508295","16c2c9c645d2acc8f0a4d52c6e54619db7a799d7","1ece2fbe9b427d379455f18a874bcd3ab86a2419","libbpf: Add probe for large INSN limit Introduce a new probe which checks whether kernel has large maximum program size which was increased in the following commit: c04c0d2b968a (""bpf: increase complexity limit and maximum program size"") Based on the similar check in Cilium[0], authored by Daniel Borkmann. [0] https://github.com/cilium/cilium/commit/657d0f585afd26232cfa5d4e70b6f64d2ea91596 Co-authored-by: Daniel Borkmann Signed-off-by: Michal Rostecki Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200108162428.25014-2-mrostecki@opensuse.org","tools/lib/bpf/libbpf.h | 1 +; tools/lib/bpf/libbpf.map | 1 +; tools/lib/bpf/libbpf_probes.c | 21 +++++++++++++++++++++; 3 files changed, 23 insertions(+)","The commit adds a probe in libbpf to check for large maximum program size support in the kernel.","libbpf,probe,INSN","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"96b11e9358080e8b705babd078cefa753109204b","96b11e9358080e8b705babd078cefa753109204b","David S. Miller","davem@davemloft.net","1578432683","David S. Miller","davem@davemloft.net","1578432683","9e9d57873a40090e58959df67d1c442bfeae42ab","481a7d154cbbd5ca355cc01cc8969876b240eded 6d4f151acf9a4f6fab09b615f246c717ddedcf0c","Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf Daniel Borkmann says: ==================== pull-request: bpf 2020-01-07 The following pull-request contains BPF updates for your *net* tree. We've added 2 non-merge commits during the last 1 day(s) which contain a total of 2 files changed, 16 insertions(+), 4 deletions(-). The main changes are: 1) Fix a use-after-free in cgroup BPF due to auto-detachment, from Roman Gushchin. 2) Fix skb out-of-bounds access in ld_abs/ind instruction, from Daniel Borkmann. ==================== Signed-off-by: David S. Miller ","","The commit merges BPF updates into the net tree, fixing a use-after-free and an skb out-of-bounds access.","use-after-free,merge,fix","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","['cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups).', ""It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here."", ""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"6d4f151acf9a4f6fab09b615f246c717ddedcf0c","6d4f151acf9a4f6fab09b615f246c717ddedcf0c","Daniel Borkmann","daniel@iogearbox.net","1578347517","Alexei Starovoitov","ast@kernel.org","1578349187","3296015eb0def5ca3f13b4953c360147bec231ec","e10360f815ca6367357b2c2cfef17fc663e50f7b","bpf: Fix passing modified ctx to ld/abs/ind instruction Anatoly has been fuzzing with kBdysch harness and reported a KASAN slab oob in one of the outcomes: [...] [ 77.359642] BUG: KASAN: slab-out-of-bounds in bpf_skb_load_helper_8_no_cache+0x71/0x130 [ 77.360463] Read of size 4 at addr ffff8880679bac68 by task bpf/406 [ 77.361119] [ 77.361289] CPU: 2 PID: 406 Comm: bpf Not tainted 5.5.0-rc2-xfstests-00157-g2187f215eba #1 [ 77.362134] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 [ 77.362984] Call Trace: [ 77.363249] dump_stack+0x97/0xe0 [ 77.363603] print_address_description.constprop.0+0x1d/0x220 [ 77.364251] ? bpf_skb_load_helper_8_no_cache+0x71/0x130 [ 77.365030] ? bpf_skb_load_helper_8_no_cache+0x71/0x130 [ 77.365860] __kasan_report.cold+0x37/0x7b [ 77.366365] ? bpf_skb_load_helper_8_no_cache+0x71/0x130 [ 77.366940] kasan_report+0xe/0x20 [ 77.367295] bpf_skb_load_helper_8_no_cache+0x71/0x130 [ 77.367821] ? bpf_skb_load_helper_8+0xf0/0xf0 [ 77.368278] ? mark_lock+0xa3/0x9b0 [ 77.368641] ? kvm_sched_clock_read+0x14/0x30 [ 77.369096] ? sched_clock+0x5/0x10 [ 77.369460] ? sched_clock_cpu+0x18/0x110 [ 77.369876] ? bpf_skb_load_helper_8+0xf0/0xf0 [ 77.370330] ___bpf_prog_run+0x16c0/0x28f0 [ 77.370755] __bpf_prog_run32+0x83/0xc0 [ 77.371153] ? __bpf_prog_run64+0xc0/0xc0 [ 77.371568] ? match_held_lock+0x1b/0x230 [ 77.371984] ? rcu_read_lock_held+0xa1/0xb0 [ 77.372416] ? rcu_is_watching+0x34/0x50 [ 77.372826] sk_filter_trim_cap+0x17c/0x4d0 [ 77.373259] ? sock_kzfree_s+0x40/0x40 [ 77.373648] ? __get_filter+0x150/0x150 [ 77.374059] ? skb_copy_datagram_from_iter+0x80/0x280 [ 77.374581] ? do_raw_spin_unlock+0xa5/0x140 [ 77.375025] unix_dgram_sendmsg+0x33a/0xa70 [ 77.375459] ? do_raw_spin_lock+0x1d0/0x1d0 [ 77.375893] ? unix_peer_get+0xa0/0xa0 [ 77.376287] ? __fget_light+0xa4/0xf0 [ 77.376670] __sys_sendto+0x265/0x280 [ 77.377056] ? __ia32_sys_getpeername+0x50/0x50 [ 77.377523] ? lock_downgrade+0x350/0x350 [ 77.377940] ? __sys_setsockopt+0x2a6/0x2c0 [ 77.378374] ? sock_read_iter+0x240/0x240 [ 77.378789] ? __sys_socketpair+0x22a/0x300 [ 77.379221] ? __ia32_sys_socket+0x50/0x50 [ 77.379649] ? mark_held_locks+0x1d/0x90 [ 77.380059] ? trace_hardirqs_on_thunk+0x1a/0x1c [ 77.380536] __x64_sys_sendto+0x74/0x90 [ 77.380938] do_syscall_64+0x68/0x2a0 [ 77.381324] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 77.381878] RIP: 0033:0x44c070 [...] After further debugging, turns out while in case of other helper functions we disallow passing modified ctx, the special case of ld/abs/ind instruction which has similar semantics (except r6 being the ctx argument) is missing such check. Modified ctx is impossible here as bpf_skb_load_helper_8_no_cache() and others are expecting skb fields in original position, hence, add check_ctx_reg() to reject any modified ctx. Issue was first introduced back in f1174f77b50c (""bpf/verifier: rework value tracking""). Fixes: f1174f77b50c (""bpf/verifier: rework value tracking"") Reported-by: Anatoly Trosinenko Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200106215157.3553-1-daniel@iogearbox.net","kernel/bpf/verifier.c | 9 +++++++--; 1 file changed, 7 insertions(+), 2 deletions(-)","Fixes a bug where modified ctx was incorrectly allowed for ld/abs/ind instructions in eBPF verifier, causing KASAN slab out-of-bounds error.","bugfix,verifier,KASAN","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"e10360f815ca6367357b2c2cfef17fc663e50f7b","e10360f815ca6367357b2c2cfef17fc663e50f7b","Roman Gushchin","guro@fb.com","1577483434","Alexei Starovoitov","ast@kernel.org","1578348030","182ae79380cb810571dc2db4e3f0490d27d28c10","4012a6f2fa562b4b2884ea96db263caa4c6057a8","bpf: cgroup: prevent out-of-order release of cgroup bpf Before commit 4bfc0bb2c60e (""bpf: decouple the lifetime of cgroup_bpf from cgroup itself"") cgroup bpf structures were released with corresponding cgroup structures. It guaranteed the hierarchical order of destruction: children were always first. It preserved attached programs from being released before their propagated copies. But with cgroup auto-detachment there are no such guarantees anymore: cgroup bpf is released as soon as the cgroup is offline and there are no live associated sockets. It means that an attached program can be detached and released, while its propagated copy is still living in the cgroup subtree. This will obviously lead to an use-after-free bug. To reproduce the issue the following script can be used: #!/bin/bash CGROOT=/sys/fs/cgroup mkdir -p ${CGROOT}/A ${CGROOT}/B ${CGROOT}/A/C sleep 1 ./test_cgrp2_attach ${CGROOT}/A egress & A_PID=$! ./test_cgrp2_attach ${CGROOT}/B egress & B_PID=$! echo $$ > ${CGROOT}/A/C/cgroup.procs iperf -s & S_PID=$! iperf -c localhost -t 100 & C_PID=$! sleep 1 echo $$ > ${CGROOT}/B/cgroup.procs echo ${S_PID} > ${CGROOT}/B/cgroup.procs echo ${C_PID} > ${CGROOT}/B/cgroup.procs sleep 1 rmdir ${CGROOT}/A/C rmdir ${CGROOT}/A sleep 1 kill -9 ${S_PID} ${C_PID} ${A_PID} ${B_PID} On the unpatched kernel the following stacktrace can be obtained: [ 33.619799] BUG: unable to handle page fault for address: ffffbdb4801ab002 [ 33.620677] #PF: supervisor read access in kernel mode [ 33.621293] #PF: error_code(0x0000) - not-present page [ 33.622754] Oops: 0000 [#1] SMP NOPTI [ 33.623202] CPU: 0 PID: 601 Comm: iperf Not tainted 5.5.0-rc2+ #23 [ 33.625545] RIP: 0010:__cgroup_bpf_run_filter_skb+0x29f/0x3d0 [ 33.635809] Call Trace: [ 33.636118] ? __cgroup_bpf_run_filter_skb+0x2bf/0x3d0 [ 33.636728] ? __switch_to_asm+0x40/0x70 [ 33.637196] ip_finish_output+0x68/0xa0 [ 33.637654] ip_output+0x76/0xf0 [ 33.638046] ? __ip_finish_output+0x1c0/0x1c0 [ 33.638576] __ip_queue_xmit+0x157/0x410 [ 33.639049] __tcp_transmit_skb+0x535/0xaf0 [ 33.639557] tcp_write_xmit+0x378/0x1190 [ 33.640049] ? _copy_from_iter_full+0x8d/0x260 [ 33.640592] tcp_sendmsg_locked+0x2a2/0xdc0 [ 33.641098] ? sock_has_perm+0x10/0xa0 [ 33.641574] tcp_sendmsg+0x28/0x40 [ 33.641985] sock_sendmsg+0x57/0x60 [ 33.642411] sock_write_iter+0x97/0x100 [ 33.642876] new_sync_write+0x1b6/0x1d0 [ 33.643339] vfs_write+0xb6/0x1a0 [ 33.643752] ksys_write+0xa7/0xe0 [ 33.644156] do_syscall_64+0x5b/0x1b0 [ 33.644605] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fix this by grabbing a reference to the bpf structure of each ancestor on the initialization of the cgroup bpf structure, and dropping the reference at the end of releasing the cgroup bpf structure. This will restore the hierarchical order of cgroup bpf releasing, without adding any operations on hot paths. Thanks to Josef Bacik for the debugging and the initial analysis of the problem. Fixes: 4bfc0bb2c60e (""bpf: decouple the lifetime of cgroup_bpf from cgroup itself"") Reported-by: Josef Bacik Signed-off-by: Roman Gushchin Acked-by: Song Liu Signed-off-by: Alexei Starovoitov ","kernel/bpf/cgroup.c | 11 +++++++++--; 1 file changed, 9 insertions(+), 2 deletions(-)","The commit fixes an issue causing out-of-order release of cgroup bpf structures that led to a use-after-free bug.","cgroup,bpf,bug","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","['cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups).']" +"6794200fa3c9c3e6759dae099145f23e4310f4f7","6794200fa3c9c3e6759dae099145f23e4310f4f7","Andrey Zhizhikin","andrey.z@gmail.com","1576051269","Arnaldo Carvalho de Melo","acme@redhat.com","1578321969","c75d3035a26b630e0435feaa2d259e4cd0a9d15b","81de3bf37a8bf58ecdbef608d16ddb0f4bbb71ca","tools lib api fs: Fix gcc9 stringop-truncation compilation error GCC9 introduced string hardening mechanisms, which exhibits the error during fs api compilation: error: '__builtin_strncpy' specified bound 4096 equals destination size [-Werror=stringop-truncation] This comes when the length of copy passed to strncpy is is equal to destination size, which could potentially lead to buffer overflow. There is a need to mitigate this potential issue by limiting the size of destination by 1 and explicitly terminate the destination with NULL. Signed-off-by: Andrey Zhizhikin Reviewed-by: Petr Mladek Acked-by: Jiri Olsa Cc: Alexei Starovoitov Cc: Andrii Nakryiko Cc: Daniel Borkmann Cc: Kefeng Wang Cc: Martin KaFai Lau Cc: Petr Mladek Cc: Sergey Senozhatsky Cc: Song Liu Cc: Yonghong Song Cc: bpf@vger.kernel.org Cc: netdev@vger.kernel.org Link: http://lore.kernel.org/lkml/20191211080109.18765-1-andrey.zhizhikin@leica-geosystems.com Signed-off-by: Arnaldo Carvalho de Melo ","tools/lib/api/fs/fs.c | 4 +++-; 1 file changed, 3 insertions(+), 1 deletion(-)","Fix gcc9 stringop-truncation error in tools lib api fs by modifying string copy to prevent buffer overflow.","gcc9,stringop-truncation,fs","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.","It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.","[""It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.""]" +"31d518f35e1a80268a24a855be9477eb458540ad","31d518f35e1a80268a24a855be9477eb458540ad","David S. Miller","davem@davemloft.net","1577828233","David S. Miller","davem@davemloft.net","1577828233","28494f630aede8f95d4ed2ebbfd14c222bd24fa6","9e860947d8d7a1504476ac49abfce90a4ce600f3 738d2902773e30939a982c8df7a7f94293659810","Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Simple overlapping changes in bpf land wrt. bpf_helper_defs.h handling. Signed-off-by: David S. Miller ","","A merge commit addressing overlapping changes related to bpf_helper_defs.h handling.","merge, bpf, changes","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"738d2902773e30939a982c8df7a7f94293659810","738d2902773e30939a982c8df7a7f94293659810","Linus Torvalds","torvalds@linux-foundation.org","1577819698","Linus Torvalds","torvalds@linux-foundation.org","1577819698","f103145e7668e9f73d69ea9978adea14bf489a7f","c5c928c667cd1e34cbcac6af5b7c2f9f4512d612 04b69426d846cd04ca9acefff1ea39e1c64d2714","Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from David Miller: 1) Fix big endian overflow in nf_flow_table, from Arnd Bergmann. 2) Fix port selection on big endian in nft_tproxy, from Phil Sutter. 3) Fix precision tracking for unbound scalars in bpf verifier, from Daniel Borkmann. 4) Fix integer overflow in socket rcvbuf check in UDP, from Antonio Messina. 5) Do not perform a neigh confirmation during a pmtu update over a tunnel, from Hangbin Liu. 6) Fix DMA mapping leak in dpaa_eth driver, from Madalin Bucur. 7) Various PTP fixes for sja1105 dsa driver, from Vladimir Oltean. 8) Add missing to dummy definition of of_mdiobus_child_is_phy(), from Geert Uytterhoeven * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (54 commits) hsr: fix slab-out-of-bounds Read in hsr_debugfs_rename() net/sched: add delete_empty() to filters and use it in cls_flower tcp: Fix highest_sack and highest_sack_seq ptp: fix the race between the release of ptp_clock and cdev net: dsa: sja1105: Reconcile the meaning of TPID and TPID2 for E/T and P/Q/R/S Documentation: net: dsa: sja1105: Remove text about taprio base-time limitation net: dsa: sja1105: Remove restriction of zero base-time for taprio offload net: dsa: sja1105: Really make the PTP command read-write net: dsa: sja1105: Take PTP egress timestamp by port, not mgmt slot cxgb4/cxgb4vf: fix flow control display for auto negotiation mlxsw: spectrum: Use dedicated policer for VRRP packets mlxsw: spectrum_router: Skip loopback RIFs during MAC validation net: stmmac: dwmac-meson8b: Fix the RGMII TX delay on Meson8b/8m2 SoCs net/sched: act_mirred: Pull mac prior redir to non mac_header_xmit device net_sched: sch_fq: properly set sk->sk_pacing_status bnx2x: Fix accounting of vlan resources among the PFs bnx2x: Use appropriate define for vlan credit of: mdio: Add missing inline to of_mdiobus_child_is_phy() dummy net: phy: aquantia: add suspend / resume ops for AQR105 dpaa_eth: fix DMA mapping leak ...","","This commit merges various networking fixes from David Miller's repository into the mainline kernel.","merge,networking,fixes","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"04b69426d846cd04ca9acefff1ea39e1c64d2714","04b69426d846cd04ca9acefff1ea39e1c64d2714","Taehee Yoo","ap420073@gmail.com","1577550489","David S. Miller","davem@davemloft.net","1577766987","1a898f1a4c8460655a6cbdcd716f95cf28587ee2","a5b72a083da197b493c7ed1e5730d62d3199f7d6","hsr: fix slab-out-of-bounds Read in hsr_debugfs_rename() hsr slave interfaces don't have debugfs directory. So, hsr_debugfs_rename() shouldn't be called when hsr slave interface name is changed. Test commands: ip link add dummy0 type dummy ip link add dummy1 type dummy ip link add hsr0 type hsr slave1 dummy0 slave2 dummy1 ip link set dummy0 name ap Splat looks like: [21071.899367][T22666] ap: renamed from dummy0 [21071.914005][T22666] ================================================================== [21071.919008][T22666] BUG: KASAN: slab-out-of-bounds in hsr_debugfs_rename+0xaa/0xb0 [hsr] [21071.923640][T22666] Read of size 8 at addr ffff88805febcd98 by task ip/22666 [21071.926941][T22666] [21071.927750][T22666] CPU: 0 PID: 22666 Comm: ip Not tainted 5.5.0-rc2+ #240 [21071.929919][T22666] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [21071.935094][T22666] Call Trace: [21071.935867][T22666] dump_stack+0x96/0xdb [21071.936687][T22666] ? hsr_debugfs_rename+0xaa/0xb0 [hsr] [21071.937774][T22666] print_address_description.constprop.5+0x1be/0x360 [21071.939019][T22666] ? hsr_debugfs_rename+0xaa/0xb0 [hsr] [21071.940081][T22666] ? hsr_debugfs_rename+0xaa/0xb0 [hsr] [21071.940949][T22666] __kasan_report+0x12a/0x16f [21071.941758][T22666] ? hsr_debugfs_rename+0xaa/0xb0 [hsr] [21071.942674][T22666] kasan_report+0xe/0x20 [21071.943325][T22666] hsr_debugfs_rename+0xaa/0xb0 [hsr] [21071.944187][T22666] hsr_netdev_notify+0x1fe/0x9b0 [hsr] [21071.945052][T22666] ? __module_text_address+0x13/0x140 [21071.945897][T22666] notifier_call_chain+0x90/0x160 [21071.946743][T22666] dev_change_name+0x419/0x840 [21071.947496][T22666] ? __read_once_size_nocheck.constprop.6+0x10/0x10 [21071.948600][T22666] ? netdev_adjacent_rename_links+0x280/0x280 [21071.949577][T22666] ? __read_once_size_nocheck.constprop.6+0x10/0x10 [21071.950672][T22666] ? lock_downgrade+0x6e0/0x6e0 [21071.951345][T22666] ? do_setlink+0x811/0x2ef0 [21071.951991][T22666] do_setlink+0x811/0x2ef0 [21071.952613][T22666] ? is_bpf_text_address+0x81/0xe0 [ ... ] Reported-by: syzbot+9328206518f08318a5fd@syzkaller.appspotmail.com Fixes: 4c2d5e33dcd3 (""hsr: rename debugfs file when interface name is changed"") Signed-off-by: Taehee Yoo Signed-off-by: David S. Miller ","net/hsr/hsr_main.c | 3 ++-; 1 file changed, 2 insertions(+), 1 deletion(-)","The commit fixes a slab-out-of-bounds read issue in hsr_debugfs_rename function by avoiding its call for hsr slave interfaces.","fix, slab-out-of-bounds, hsr","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.","It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.","[""It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.""]" +"2bbc078f812d45b8decb55935dab21199bd21489","2bbc078f812d45b8decb55935dab21199bd21489","David S. Miller","davem@davemloft.net","1577485210","David S. Miller","davem@davemloft.net","1577485210","b217e030e0f80a26561cef679e8ae2643162b346","9e41fbf3dd38327d440a8f3ba0c234519dbb5280 7c8dce4b166113743adad131b5a24c4acc12f92c","Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next Daniel Borkmann says: ==================== pull-request: bpf-next 2019-12-27 The following pull-request contains BPF updates for your *net-next* tree. We've added 127 non-merge commits during the last 17 day(s) which contain a total of 110 files changed, 6901 insertions(+), 2721 deletions(-). There are three merge conflicts. Conflicts and resolution looks as follows: 1) Merge conflict in net/bpf/test_run.c: There was a tree-wide cleanup c593642c8be0 (""treewide: Use sizeof_field() macro"") which gets in the way with b590cb5f802d (""bpf: Switch to offsetofend in BPF_PROG_TEST_RUN""): <<<<<<< HEAD if (!range_is_zero(__skb, offsetof(struct __sk_buff, priority) + sizeof_field(struct __sk_buff, priority), ======= if (!range_is_zero(__skb, offsetofend(struct __sk_buff, priority), >>>>>>> 7c8dce4b166113743adad131b5a24c4acc12f92c There are a few occasions that look similar to this. Always take the chunk with offsetofend(). Note that there is one where the fields differ in here: <<<<<<< HEAD if (!range_is_zero(__skb, offsetof(struct __sk_buff, tstamp) + sizeof_field(struct __sk_buff, tstamp), ======= if (!range_is_zero(__skb, offsetofend(struct __sk_buff, gso_segs), >>>>>>> 7c8dce4b166113743adad131b5a24c4acc12f92c Just take the one with offsetofend() /and/ gso_segs. Latter is correct due to 850a88cc4096 (""bpf: Expose __sk_buff wire_len/gso_segs to BPF_PROG_TEST_RUN""). 2) Merge conflict in arch/riscv/net/bpf_jit_comp.c: (I'm keeping Bjorn in Cc here for a double-check in case I got it wrong.) <<<<<<< HEAD if (is_13b_check(off, insn)) return -1; emit(rv_blt(tcc, RV_REG_ZERO, off >> 1), ctx); ======= emit_branch(BPF_JSLT, RV_REG_T1, RV_REG_ZERO, off, ctx); >>>>>>> 7c8dce4b166113743adad131b5a24c4acc12f92c Result should look like: emit_branch(BPF_JSLT, tcc, RV_REG_ZERO, off, ctx); 3) Merge conflict in arch/riscv/include/asm/pgtable.h: <<<<<<< HEAD ======= #define VMALLOC_SIZE (KERN_VIRT_SIZE >> 1) #define VMALLOC_END (PAGE_OFFSET - 1) #define VMALLOC_START (PAGE_OFFSET - VMALLOC_SIZE) #define BPF_JIT_REGION_SIZE (SZ_128M) #define BPF_JIT_REGION_START (PAGE_OFFSET - BPF_JIT_REGION_SIZE) #define BPF_JIT_REGION_END (VMALLOC_END) /* * Roughly size the vmemmap space to be large enough to fit enough * struct pages to map half the virtual address space. Then * position vmemmap directly below the VMALLOC region. */ #define VMEMMAP_SHIFT \ (CONFIG_VA_BITS - PAGE_SHIFT - 1 + STRUCT_PAGE_MAX_SHIFT) #define VMEMMAP_SIZE BIT(VMEMMAP_SHIFT) #define VMEMMAP_END (VMALLOC_START - 1) #define VMEMMAP_START (VMALLOC_START - VMEMMAP_SIZE) #define vmemmap ((struct page *)VMEMMAP_START) >>>>>>> 7c8dce4b166113743adad131b5a24c4acc12f92c Only take the BPF_* defines from there and move them higher up in the same file. Remove the rest from the chunk. The VMALLOC_* etc defines got moved via 01f52e16b868 (""riscv: define vmemmap before pfn_to_page calls""). Result: [...] #define __S101 PAGE_READ_EXEC #define __S110 PAGE_SHARED_EXEC #define __S111 PAGE_SHARED_EXEC #define VMALLOC_SIZE (KERN_VIRT_SIZE >> 1) #define VMALLOC_END (PAGE_OFFSET - 1) #define VMALLOC_START (PAGE_OFFSET - VMALLOC_SIZE) #define BPF_JIT_REGION_SIZE (SZ_128M) #define BPF_JIT_REGION_START (PAGE_OFFSET - BPF_JIT_REGION_SIZE) #define BPF_JIT_REGION_END (VMALLOC_END) /* * Roughly size the vmemmap space to be large enough to fit enough * struct pages to map half the virtual address space. Then * position vmemmap directly below the VMALLOC region. */ #define VMEMMAP_SHIFT \ (CONFIG_VA_BITS - PAGE_SHIFT - 1 + STRUCT_PAGE_MAX_SHIFT) #define VMEMMAP_SIZE BIT(VMEMMAP_SHIFT) #define VMEMMAP_END (VMALLOC_START - 1) #define VMEMMAP_START (VMALLOC_START - VMEMMAP_SIZE) [...] Let me know if there are any other issues. Anyway, the main changes are: 1) Extend bpftool to produce a struct (aka ""skeleton"") tailored and specific to a provided BPF object file. This provides an alternative, simplified API compared to standard libbpf interaction. Also, add libbpf extern variable resolution for .kconfig section to import Kconfig data, from Andrii Nakryiko. 2) Add BPF dispatcher for XDP which is a mechanism to avoid indirect calls by generating a branch funnel as discussed back in bpfconf'19 at LSF/MM. Also, add various BPF riscv JIT improvements, from Björn Töpel. 3) Extend bpftool to allow matching BPF programs and maps by name, from Paul Chaignon. 4) Support for replacing cgroup BPF programs attached with BPF_F_ALLOW_MULTI flag for allowing updates without service interruption, from Andrey Ignatov. 5) Cleanup and simplification of ring access functions for AF_XDP with a bonus of 0-5% performance improvement, from Magnus Karlsson. 6) Enable BPF JITs for x86-64 and arm64 by default. Also, final version of audit support for BPF, from Daniel Borkmann and latter with Jiri Olsa. 7) Move and extend test_select_reuseport into BPF program tests under BPF selftests, from Jakub Sitnicki. 8) Various BPF sample improvements for xdpsock for customizing parameters to set up and benchmark AF_XDP, from Jay Jayatheerthan. 9) Improve libbpf to provide a ulimit hint on permission denied errors. Also change XDP sample programs to attach in driver mode by default, from Toke Høiland-Jørgensen. 10) Extend BPF test infrastructure to allow changing skb mark from tc BPF programs, from Nikita V. Shirokov. 11) Optimize prologue code sequence in BPF arm32 JIT, from Russell King. 12) Fix xdp_redirect_cpu BPF sample to manually attach to tracepoints after libbpf conversion, from Jesper Dangaard Brouer. 13) Minor misc improvements from various others. ==================== Signed-off-by: David S. Miller ","","This commit merges BPF updates from the bpf-next branch into the net-next tree, resolving conflicts and introducing features like bpftool skeleton and BPF dispatcher for XDP.","BPF, merge, updates","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"7c8dce4b166113743adad131b5a24c4acc12f92c","7c8dce4b166113743adad131b5a24c4acc12f92c","Andrii Nakryiko","andriin@fb.com","1577394173","Daniel Borkmann","daniel@iogearbox.net","1577437865","90b8cb27d1ec83d9086fac9b4d8fee846bfbc3d5","1162f844030ac1ac7321b5e8f6c9badc7a11428f","bpftool: Make skeleton C code compilable with C++ compiler When auto-generated BPF skeleton C code is included from C++ application, it triggers compilation error due to void * being implicitly casted to whatever target pointer type. This is supported by C, but not C++. To solve this problem, add explicit casts, where necessary. To ensure issues like this are captured going forward, add skeleton usage in test_cpp test. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191226210253.3132060-1-andriin@fb.com","tools/bpf/bpftool/gen.c | 10 +++++-----; tools/testing/selftests/bpf/Makefile | 2 +-; tools/testing/selftests/bpf/test_cpp.cpp | 10 ++++++++++; 3 files changed, 16 insertions(+), 6 deletions(-)","The commit makes bpftool skeleton code compatible with C++ compilers by adding explicit type casts and includes a test for C++ compilation.","bpftool, C++, compatibility","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"3c2f450e553ce47fcb0d6141807a8858e3213c9c","3c2f450e553ce47fcb0d6141807a8858e3213c9c","David S. Miller","davem@davemloft.net","1577402704","David S. Miller","davem@davemloft.net","1577402704","dd8b8b0b258a82168e40bcd216df6176dd19c63e","7df2281a174bd0fdbb2211a26914e5440740fcde fa633a0f89192379828103957874682d389eae83","Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf Daniel Borkmann says: ==================== pull-request: bpf 2019-12-23 The following pull-request contains BPF updates for your *net* tree. We've added 2 non-merge commits during the last 1 day(s) which contain a total of 4 files changed, 34 insertions(+), 31 deletions(-). The main changes are: 1) Fix libbpf build when building on a read-only filesystem with O=dir option, from Namhyung Kim. 2) Fix a precision tracking bug for unknown scalars, from Daniel Borkmann. ==================== Signed-off-by: David S. Miller ","","This commit merges BPF updates related to build and precision tracking fixes into the net tree.","bpf, merge, fixes","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"1162f844030ac1ac7321b5e8f6c9badc7a11428f","1162f844030ac1ac7321b5e8f6c9badc7a11428f","Hechao Li","hechaol@fb.com","1577150262","Daniel Borkmann","daniel@iogearbox.net","1577352954","bf84a24566a166a5c26ebc952a28ec0be6c87f4c","8ab9da573dad95536d8a92f19d7967e8142cd827","bpf: Print error message for bpftool cgroup show Currently, when bpftool cgroup show has an error, no error message is printed. This is confusing because the user may think the result is empty. Before the change: $ bpftool cgroup show /sys/fs/cgroup ID AttachType AttachFlags Name $ echo $? 255 After the change: $ ./bpftool cgroup show /sys/fs/cgroup Error: can't query bpf programs attached to /sys/fs/cgroup: Operation not permitted v2: Rename check_query_cgroup_progs to cgroup_has_attached_progs Signed-off-by: Hechao Li Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191224011742.3714301-1-hechaol@fb.com","tools/bpf/bpftool/cgroup.c | 56 ++++++++++++++++++++++++++++++++--------------; 1 file changed, 39 insertions(+), 17 deletions(-)","The commit improves user feedback by adding error messages for failures in the bpftool cgroup show command.","error,bpftool,cgroup","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups).']" +"8ab9da573dad95536d8a92f19d7967e8142cd827","8ab9da573dad95536d8a92f19d7967e8142cd827","Andrii Nakryiko","andriin@fb.com","1577124185","Daniel Borkmann","daniel@iogearbox.net","1577352704","ca2dd1d41f6f6e3a13c7fafd9435a5adde257e75","f9e6bfdbaf0cf304d72c70a05d81acac01a04f48","libbpf: Support CO-RE relocations for LDX/ST/STX instructions Clang patch [0] enables emitting relocatable generic ALU/ALU64 instructions (i.e, shifts and arithmetic operations), as well as generic load/store instructions. The former ones are already supported by libbpf as is. This patch adds further support for load/store instructions. Relocatable field offset is encoded in BPF instruction's 16-bit offset section and are adjusted by libbpf based on target kernel BTF. These Clang changes and corresponding libbpf changes allow for more succinct generated BPF code by encoding relocatable field reads as a single ST/LDX/STX instruction. It also enables relocatable access to BPF context. Previously, if context struct (e.g., __sk_buff) was accessed with CO-RE relocations (e.g., due to preserve_access_index attribute), it would be rejected by BPF verifier due to modified context pointer dereference. With Clang patch, such context accesses are both relocatable and have a fixed offset from the point of view of BPF verifier. [0] https://reviews.llvm.org/D71790 Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20191223180305.86417-1-andriin@fb.com","tools/lib/bpf/libbpf.c | 31 ++++++++++++++++++++++++++++---; 1 file changed, 28 insertions(+), 3 deletions(-)","This commit adds support for CO-RE relocations for load/store instructions in libbpf using Clang enhancements.","libbpf,Clang,CO-RE","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"fa633a0f89192379828103957874682d389eae83","fa633a0f89192379828103957874682d389eae83","Namhyung Kim","namhyung@kernel.org","1577081606","Daniel Borkmann","daniel@iogearbox.net","1577111646","2a7f70307542ac7805d419c4f73f23b6771f56b7","f54c7898ed1c3c9331376c0337a5049c38f66497","libbpf: Fix build on read-only filesystems I got the following error when I tried to build perf on a read-only filesystem with O=dir option. $ cd /some/where/ro/linux/tools/perf $ make O=$HOME/build/perf ... CC /home/namhyung/build/perf/lib.o /bin/sh: bpf_helper_defs.h: Read-only file system make[3]: *** [Makefile:184: bpf_helper_defs.h] Error 1 make[2]: *** [Makefile.perf:778: /home/namhyung/build/perf/libbpf.a] Error 2 make[2]: *** Waiting for unfinished jobs.... LD /home/namhyung/build/perf/libperf-in.o AR /home/namhyung/build/perf/libperf.a PERF_VERSION = 5.4.0 make[1]: *** [Makefile.perf:225: sub-make] Error 2 make: *** [Makefile:70: all] Error 2 It was becaused bpf_helper_defs.h was generated in current directory. Move it to OUTPUT directory. Signed-off-by: Namhyung Kim Signed-off-by: Daniel Borkmann Tested-by: Andrii Nakryiko Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20191223061326.843366-1-namhyung@kernel.org","tools/lib/bpf/Makefile | 15 ++++++++-------; tools/testing/selftests/bpf/.gitignore | 1 +; tools/testing/selftests/bpf/Makefile | 6 +++---; 3 files changed, 12 insertions(+), 10 deletions(-)","The commit fixes a build issue on read-only filesystems by changing the generation path for bpf_helper_defs.h.","build, read-only, filesystem","A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"f54c7898ed1c3c9331376c0337a5049c38f66497","f54c7898ed1c3c9331376c0337a5049c38f66497","Daniel Borkmann","daniel@iogearbox.net","1577054260","Alexei Starovoitov","ast@kernel.org","1577064070","62870d41394d200e8c10d964dbe5b2eeb21cbf37","c60174717544aa8959683d7e19d568309c3a0c65","bpf: Fix precision tracking for unbounded scalars Anatoly has been fuzzing with kBdysch harness and reported a hang in one of the outcomes. Upon closer analysis, it turns out that precise scalar value tracking is missing a few precision markings for unknown scalars: 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 0: (b7) r0 = 0 1: R0_w=invP0 R1=ctx(id=0,off=0,imm=0) R10=fp0 1: (35) if r0 >= 0xf72e goto pc+0 --> only follow fallthrough 2: R0_w=invP0 R1=ctx(id=0,off=0,imm=0) R10=fp0 2: (35) if r0 >= 0x80fe0000 goto pc+0 --> only follow fallthrough 3: R0_w=invP0 R1=ctx(id=0,off=0,imm=0) R10=fp0 3: (14) w0 -= -536870912 4: R0_w=invP536870912 R1=ctx(id=0,off=0,imm=0) R10=fp0 4: (0f) r1 += r0 5: R0_w=invP536870912 R1_w=inv(id=0) R10=fp0 5: (55) if r1 != 0x104c1500 goto pc+0 --> push other branch for later analysis R0_w=invP536870912 R1_w=inv273421568 R10=fp0 6: R0_w=invP536870912 R1_w=inv273421568 R10=fp0 6: (b7) r0 = 0 7: R0=invP0 R1=inv273421568 R10=fp0 7: (76) if w1 s>= 0xffffff00 goto pc+3 --> only follow goto 11: R0=invP0 R1=inv273421568 R10=fp0 11: (95) exit 6: R0_w=invP536870912 R1_w=inv(id=0) R10=fp0 6: (b7) r0 = 0 propagating r0 7: safe processed 11 insns [...] In the analysis of the second path coming after the successful exit above, the path is being pruned at line 7. Pruning analysis found that both r0 are precise P0 and both R1 are non-precise scalars and given prior path with R1 as non-precise scalar succeeded, this one is therefore safe as well. However, problem is that given condition at insn 7 in the first run, we only followed goto and didn't push the other branch for later analysis, we've never walked the few insns in there and therefore dead-code sanitation rewrites it as goto pc-1, causing the hang depending on the skb address hitting these conditions. The issue is that R1 should have been marked as precise as well such that pruning enforces range check and conluded that new R1 is not in range of old R1. In insn 4, we mark R1 (skb) as unknown scalar via __mark_reg_unbounded() but not mark_reg_unbounded() and therefore regs->precise remains as false. Back in b5dc0163d8fd (""bpf: precise scalar_value tracking""), this was not the case since marking out of __mark_reg_unbounded() had this covered as well. Once in both are set as precise in 4 as they should have been, we conclude that given R1 was in prior fall-through path 0x104c1500 and now is completely unknown, the check at insn 7 concludes that we need to continue walking. Analysis after the fix: 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 0: (b7) r0 = 0 1: R0_w=invP0 R1=ctx(id=0,off=0,imm=0) R10=fp0 1: (35) if r0 >= 0xf72e goto pc+0 2: R0_w=invP0 R1=ctx(id=0,off=0,imm=0) R10=fp0 2: (35) if r0 >= 0x80fe0000 goto pc+0 3: R0_w=invP0 R1=ctx(id=0,off=0,imm=0) R10=fp0 3: (14) w0 -= -536870912 4: R0_w=invP536870912 R1=ctx(id=0,off=0,imm=0) R10=fp0 4: (0f) r1 += r0 5: R0_w=invP536870912 R1_w=invP(id=0) R10=fp0 5: (55) if r1 != 0x104c1500 goto pc+0 R0_w=invP536870912 R1_w=invP273421568 R10=fp0 6: R0_w=invP536870912 R1_w=invP273421568 R10=fp0 6: (b7) r0 = 0 7: R0=invP0 R1=invP273421568 R10=fp0 7: (76) if w1 s>= 0xffffff00 goto pc+3 11: R0=invP0 R1=invP273421568 R10=fp0 11: (95) exit 6: R0_w=invP536870912 R1_w=invP(id=0) R10=fp0 6: (b7) r0 = 0 7: R0_w=invP0 R1_w=invP(id=0) R10=fp0 7: (76) if w1 s>= 0xffffff00 goto pc+3 R0_w=invP0 R1_w=invP(id=0) R10=fp0 8: R0_w=invP0 R1_w=invP(id=0) R10=fp0 8: (a5) if r0 < 0x2007002a goto pc+0 9: R0_w=invP0 R1_w=invP(id=0) R10=fp0 9: (57) r0 &= -16316416 10: R0_w=invP0 R1_w=invP(id=0) R10=fp0 10: (a6) if w0 < 0x1201 goto pc+0 11: R0_w=invP0 R1_w=invP(id=0) R10=fp0 11: (95) exit 11: R0=invP0 R1=invP(id=0) R10=fp0 11: (95) exit processed 16 insns [...] Fixes: 6754172c208d (""bpf: fix precision tracking in presence of bpf2bpf calls"") Reported-by: Anatoly Trosinenko Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191222223740.25297-1-daniel@iogearbox.net","kernel/bpf/verifier.c | 43 ++++++++++++++++++++++---------------------; 1 file changed, 22 insertions(+), 21 deletions(-)","The commit fixes precision tracking for unbounded scalars in the eBPF verifier to prevent hangs from dead-code sanitation errors.","precision,tracking,scalars","A bug fix. It primarily resolves a bug or issue in the code.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"f9e6bfdbaf0cf304d72c70a05d81acac01a04f48","f9e6bfdbaf0cf304d72c70a05d81acac01a04f48","Jesper Dangaard Brouer","brouer@redhat.com","1576858776","Alexei Starovoitov","ast@kernel.org","1576887223","ac70f4b3f3111f5c8001e2beec6510d527279109","6cd6e64e3603bd5d1677365cf935c2d8e9f496e0","samples/bpf: Xdp_redirect_cpu fix missing tracepoint attach When sample xdp_redirect_cpu was converted to use libbpf, the tracepoints used by this sample were not getting attached automatically like with bpf_load.c. The BPF-maps was still getting loaded, thus nobody notice that the tracepoints were not updating these maps. This fix doesn't use the new skeleton code, as this bug was introduced in v5.1 and stable might want to backport this. E.g. Red Hat QA uses this sample as part of their testing. Fixes: bbaf6029c49c (""samples/bpf: Convert XDP samples to libbpf usage"") Signed-off-by: Jesper Dangaard Brouer Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/157685877642.26195.2798780195186786841.stgit@firesoul","samples/bpf/xdp_redirect_cpu_user.c | 59 ++++++++++++++++++++++++++++++++++---; 1 file changed, 55 insertions(+), 4 deletions(-)","This commit fixes a missing tracepoint attachment issue in the xdp_redirect_cpu sample when using libbpf.","tracepoint, libbpf, fix","A bug fix. It primarily resolves a bug or issue in the code.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.']" +"46e3268eaaca9f8a0f145872b96fe6d54a232890","46e3268eaaca9f8a0f145872b96fe6d54a232890","Jay Jayatheerthan","jay.jayatheerthan@intel.com","1576832130","Alexei Starovoitov","ast@kernel.org","1576887039","8ef2139e4421af7f64a5aede0c2190c30634dd7c","4a3c23ae3acc6185a9d418830f22672a52ff986a","samples/bpf: xdpsock: Add option to specify transmit fill pattern The UDP payload fill pattern can be specified using '-P' or '--tx-pkt-pattern' option. It is an unsigned 32 bit field and defaulted to 0x12345678. The IP and UDP checksum is calculated by the code as per the content of the packet before transmission. Signed-off-by: Jay Jayatheerthan Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191220085530.4980-7-jay.jayatheerthan@intel.com","samples/bpf/xdpsock_user.c | 13 +++++++++----; 1 file changed, 9 insertions(+), 4 deletions(-)","The commit introduces an option to specify a UDP payload transmit fill pattern in the xdpsock sample program.","xdpsock,pattern,UDP","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.']" +"4a3c23ae3acc6185a9d418830f22672a52ff986a","4a3c23ae3acc6185a9d418830f22672a52ff986a","Jay Jayatheerthan","jay.jayatheerthan@intel.com","1576832129","Alexei Starovoitov","ast@kernel.org","1576887039","abe2b6d44e23d7c9735db6b44cb9bfd87d12827d","ece6e9694751a4f0b99372724a0705a0217132b3","samples/bpf: xdpsock: Add option to specify tx packet size New option '-s' or '--tx-pkt-size' has been added to specify the transmit packet size. The packet size ranges from 47 to 4096 bytes. When this option is not provided, it defaults to 64 byte packet. The code uses struct ethhdr, struct iphdr and struct udphdr to form the transmit packet. The MAC address, IP address and UDP ports are set to default values. The code calculates IP and UDP checksums before sending the packet. Checksum calculation code in Linux kernel is used for this purpose. The Ethernet FCS is not filled by the code. Signed-off-by: Jay Jayatheerthan Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191220085530.4980-6-jay.jayatheerthan@intel.com","samples/bpf/xdpsock_user.c | 276 +++++++++++++++++++++++++++++++++++++++++++--; 1 file changed, 265 insertions(+), 11 deletions(-)","This commit introduces a new option to set the transmit packet size in the xdpsock example program.","xdpsock, transmit, packet","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.']" +"ece6e9694751a4f0b99372724a0705a0217132b3","ece6e9694751a4f0b99372724a0705a0217132b3","Jay Jayatheerthan","jay.jayatheerthan@intel.com","1576832128","Alexei Starovoitov","ast@kernel.org","1576887039","f8db82bdb2b120deb34011b6f2bbd7bd584868bc","cd9e72b6f21044b36a096833003811c2b2038455","samples/bpf: xdpsock: Add option to specify number of packets to send Use '-C' or '--tx-pkt-count' to specify number of packets to send. If it is not specified, the application sends packets forever. If packet count is not a multiple of batch size, last batch sent is less than the batch size. Signed-off-by: Jay Jayatheerthan Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191220085530.4980-5-jay.jayatheerthan@intel.com","samples/bpf/xdpsock_user.c | 73 +++++++++++++++++++++++++++++++++++++---------; 1 file changed, 59 insertions(+), 14 deletions(-)","The commit adds an option to the xdpsock sample to specify the number of packets to send.","xdpsock,packets,option","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.', 'Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.', ""It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here.""]" +"cd9e72b6f21044b36a096833003811c2b2038455","cd9e72b6f21044b36a096833003811c2b2038455","Jay Jayatheerthan","jay.jayatheerthan@intel.com","1576832127","Alexei Starovoitov","ast@kernel.org","1576887039","499f73f7ea2132ec76efebbcce60eb24021cbd7a","695255882bdf63da240db33d0f2aa9ccca1cbe67","samples/bpf: xdpsock: Add option to specify batch size New option to specify batch size for tx, rx and l2fwd has been added. This allows fine tuning to maximize performance. It is specified using '-b' or '--batch_size' options. When not specified default is 64. Signed-off-by: Jay Jayatheerthan Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191220085530.4980-4-jay.jayatheerthan@intel.com","samples/bpf/xdpsock_user.c | 52 ++++++++++++++++++++++++++--------------------; 1 file changed, 29 insertions(+), 23 deletions(-)","The commit adds a new option for specifying batch size in the xdpsock sample application to optimize performance.","batch,performance,xdpsock","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.']" +"695255882bdf63da240db33d0f2aa9ccca1cbe67","695255882bdf63da240db33d0f2aa9ccca1cbe67","Jay Jayatheerthan","jay.jayatheerthan@intel.com","1576832126","Alexei Starovoitov","ast@kernel.org","1576887039","b0d2e401f806f62d302ac9f359d2090631f808aa","d3f11b018f6ce278e683008e9c225fe87afc532d","samples/bpf: xdpsock: Use common code to handle signal and main exit Add code to do cleanup for signals and application completion in a unified fashion. The signal handler sets benckmark_done flag terminating the threads. The cleanup is called before returning from main() function. Signed-off-by: Jay Jayatheerthan Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191220085530.4980-3-jay.jayatheerthan@intel.com","samples/bpf/xdpsock_user.c | 9 +++++++--; 1 file changed, 7 insertions(+), 2 deletions(-)","Unified signal handling and cleanup in the xdpsock sample for better resource management upon application exit.","xdpsock,signal,cleanup","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.']" +"d3f11b018f6ce278e683008e9c225fe87afc532d","d3f11b018f6ce278e683008e9c225fe87afc532d","Jay Jayatheerthan","jay.jayatheerthan@intel.com","1576832125","Alexei Starovoitov","ast@kernel.org","1576887039","bc53979422396ee6e4a1a1c1dcdfa1f44b3e2330","478bee0df0ec9067c12e7d058d78721a7e7a1b29","samples/bpf: xdpsock: Add duration option to specify how long to run The application now supports '-d' or '--duration' option to specify number of seconds to run. This is used in tx, rx and l2fwd features. If this option is not provided, the application runs forever. Signed-off-by: Jay Jayatheerthan Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191220085530.4980-2-jay.jayatheerthan@intel.com","samples/bpf/xdpsock_user.c | 37 +++++++++++++++++++++++++++++++++++--; 1 file changed, 35 insertions(+), 2 deletions(-)","The xdpsock sample now supports a duration option to specify run time in seconds.","xdpsock,duration,option","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.']" +"478bee0df0ec9067c12e7d058d78721a7e7a1b29","478bee0df0ec9067c12e7d058d78721a7e7a1b29","Andrey Ignatov","rdna@fb.com","1576800311","Alexei Starovoitov","ast@kernel.org","1576886762","537e46aa39c0c2fe37da471dd970177c513051d8","ce3cec27933c069d2015a81e59b93eb656fe7ee4","selftests/bpf: Preserve errno in test_progs CHECK macros It's follow-up for discussion [1] CHECK and CHECK_FAIL macros in test_progs.h can affect errno in some circumstances, e.g. if some code accidentally closes stdout. It makes checking errno in patterns like this unreliable: if (CHECK(!bpf_prog_attach_xattr(...), ""tag"", ""msg"")) goto err; CHECK_FAIL(errno != ENOENT); , since by CHECK_FAIL time errno could be affected not only by bpf_prog_attach_xattr but by CHECK as well. Fix it by saving and restoring errno in the macros. There is no ""Fixes"" tag since no problems were discovered yet and it's rather precaution. test_progs was run with this change and no difference was identified. [1] https://lore.kernel.org/bpf/20191219210907.GD16266@rdna-mbp.dhcp.thefacebook.com/ Signed-off-by: Andrey Ignatov Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20191220000511.1684853-1-rdna@fb.com","tools/testing/selftests/bpf/test_progs.h | 4 ++++; 1 file changed, 4 insertions(+)","The commit updates test macros in selftests for bpf to preserve errno value for reliable error checking.","errno,macros,selftests","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"ce3cec27933c069d2015a81e59b93eb656fe7ee4","ce3cec27933c069d2015a81e59b93eb656fe7ee4","Alexei Starovoitov","ast@kernel.org","1576886410","Alexei Starovoitov","ast@kernel.org","1576886420","1aea2b20504a1fddec4bcec2e78bd0d3ed032167","99cacdc6f661f50f44a0ef006a1a3db20c0577f6 1d9cb1f381860b529edec57cf7a08133f40366eb","Merge branch 'xsk-cleanup' Magnus Karlsson says: ==================== This patch set cleans up the ring access functions of AF_XDP in hope that it will now be easier to understand and maintain. I used to get a headache every time I looked at this code in order to really understand it, but now I do think it is a lot less painful. The code has been simplified a lot and as a bonus we get better performance in nearly all cases. On my new 2.1 GHz Cascade Lake machine with a standard default config plus AF_XDP support and CONFIG_PREEMPT on I get the following results in percent performance increases with this patch set compared to without it: Zero-copy (-N): rxdrop txpush l2fwd 1 core: -2% 0% 3% 2 cores: 4% 0% 3% Zero-copy with poll() (-N -p): rxdrop txpush l2fwd 1 core: 3% 0% 1% 2 cores: 21% 0% 9% Skb mode (-S): Shows a 0% to 5% performance improvement over the same benchmarks as above. Here 1 core means that we are running the driver processing and the application on the same core, while 2 cores means that they execute on separate cores. The applications are from the xdpsock sample app. On my older 2.0 Ghz Broadwell machine that I used for the v1, I get the following results: Zero-copy (-N): rxdrop txpush l2fwd 1 core: 4% 5% 4% 2 cores: 1% 0% 2% Zero-copy with poll() (-N -p): rxdrop txpush l2fwd 1 core: 1% 3% 3% 2 cores: 22% 0% 5% Skb mode (-S): Shows a 0% to 1% performance improvement over the same benchmarks as above. When a results says 21 or 22% better, as in the case of poll mode with 2 cores and rxdrop, my first reaction is that it must be a bug. Everything else shows between 0% and 5% performance improvement. What is giving rise to 22%? A quick bisect indicates that it is patches 2, 3, 4, 5, and 6 that are giving rise to most of this improvement. So not one patch in particular, but something around 4% improvement from each one of them. Note that exactly this benchmark has previously had an extraordinary slow down compared to when running without poll syscalls. For all the other poll tests above, the slowdown has always been around 4% for using poll syscalls. But with the bad performing test in question, it was above 25%. Interestingly, after this clean up, the slow down is 4%, just like all the other poll tests. Please take an extra peek at this so I have not messed up something. The 0% for several txpush results are due to the test bottlenecking on a non-CPU HW resource. If I eliminated that bottleneck on my system, I would expect to see an increase there too. Changes v1 -> v2: * Corrected textual errors in the commit logs (Sergei and Martin) * Fixed the functions that detect empty and full rings so that they now operate on the global ring state (Maxim) This patch has been applied against commit a352a82496d1 (""Merge branch 'libbpf-extern-followups'"") Structure of the patch set: Patch 1: Eliminate the lazy update threshold used when preallocating entries in the completion ring Patch 2: Simplify the detection of empty and full rings Patch 3: Consolidate the two local producer pointers into one Patch 4: Standardize the naming of the producer ring access functions Patch 5: Eliminate the Rx batch size used for the fill ring Patch 6: Simplify the functions xskq_nb_avail and xskq_nb_free Patch 7: Simplify and standardize the naming of the consumer ring access functions Patch 8: Change the names of the validation functions to improve readability and also the return value of these functions Patch 9: Change the name of xsk_umem_discard_addr() to xsk_umem_release_addr() to better reflect the new names. Requires a name change in the drivers that support AF_XDP zero-copy. Patch 10: Remove unnecessary READ_ONCE of data in the ring Patch 11: Add overall function naming comment and reorder the functions for easier reference Patch 12: Use the struct_size helper function when allocating rings ==================== Reviewed-by: Björn Töpel Tested-by: Björn Töpel Acked-by: Björn Töpel Signed-off-by: Alexei Starovoitov ","","This commit merges a patch set aimed at simplifying AF_XDP ring access functions for better readability and performance.","AF_XDP,rings,cleanup","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.', ""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"1d9cb1f381860b529edec57cf7a08133f40366eb","1d9cb1f381860b529edec57cf7a08133f40366eb","Magnus Karlsson","magnus.karlsson@intel.com","1576759171","Alexei Starovoitov","ast@kernel.org","1576886409","1aea2b20504a1fddec4bcec2e78bd0d3ed032167","15d8c9162ced1789d25261859a7b37db8426e409","xsk: Use struct_size() helper Improve readability and maintainability by using the struct_size() helper when allocating the AF_XDP rings. Signed-off-by: Magnus Karlsson Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/1576759171-28550-13-git-send-email-magnus.karlsson@intel.com","net/xdp/xsk_queue.c | 15 +++++++--------; 1 file changed, 7 insertions(+), 8 deletions(-)","This commit enhances code readability by using struct_size() for AF_XDP ring allocations.","xsk struct_size readability","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"15d8c9162ced1789d25261859a7b37db8426e409","15d8c9162ced1789d25261859a7b37db8426e409","Magnus Karlsson","magnus.karlsson@intel.com","1576759170","Alexei Starovoitov","ast@kernel.org","1576886409","68eb70d43dcc4d24d0ac88ec3261cdef01b393b3","c34787fcc90f0732ff00754057f11780007002e4","xsk: Add function naming comments and reorder functions Add comments on how the ring access functions are named and how they are supposed to be used for producers and consumers. The functions are also reordered so that the consumer functions are in the beginning and the producer functions in the end, for easier reference. Put this in a separate patch as the diff might look a little odd, but no functionality has changed in this patch. Signed-off-by: Magnus Karlsson Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/1576759171-28550-12-git-send-email-magnus.karlsson@intel.com","net/xdp/xsk.c | 10 ++; net/xdp/xsk_queue.h | 293 ++++++++++++++++++++++++++++------------------------; 2 files changed, 167 insertions(+), 136 deletions(-)","This commit adds comments and reorders xsk functions to enhance clarity without altering functionality.","function,naming,reorder","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"c34787fcc90f0732ff00754057f11780007002e4","c34787fcc90f0732ff00754057f11780007002e4","Magnus Karlsson","magnus.karlsson@intel.com","1576759169","Alexei Starovoitov","ast@kernel.org","1576886409","e2b70e5a4cebd0e99f5cbbd8dfd4d5df94cb8db6","f8509aa078de0842ec1817e8026e58620cd05d3b","xsk: Remove unnecessary READ_ONCE of data There are two unnecessary READ_ONCE of descriptor data. These are not needed since the data is written by the producer before it signals that the data is available by incrementing the producer pointer. As the access to this producer pointer is serialized and the consumer always reads the descriptor after it has read and synchronized with the producer counter, the write of the descriptor will have fully completed and it does not matter if the consumer has any read tearing. Signed-off-by: Magnus Karlsson Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/1576759171-28550-11-git-send-email-magnus.karlsson@intel.com","net/xdp/xsk_queue.h | 4 ++--; 1 file changed, 2 insertions(+), 2 deletions(-)","The commit removes unnecessary READ_ONCE operations on descriptor data in the xsk code.","xsk,READ_ONCE,descriptor","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"f8509aa078de0842ec1817e8026e58620cd05d3b","f8509aa078de0842ec1817e8026e58620cd05d3b","Magnus Karlsson","magnus.karlsson@intel.com","1576759168","Alexei Starovoitov","ast@kernel.org","1576886409","782bd2d3c8e903e67cc6bcf8c6811df389099301","03896ef1f0cb23d2742ddf486c531c700a2da7d6","xsk: ixgbe: i40e: ice: mlx5: Xsk_umem_discard_addr to xsk_umem_release_addr Change the name of xsk_umem_discard_addr to xsk_umem_release_addr to better reflect the new naming of the AF_XDP queue manipulation functions. As this functions is used by drivers implementing support for AF_XDP zero-copy, it requires a name change to these drivers. The function xsk_umem_release_addr_rq has also changed name in the same fashion. Signed-off-by: Magnus Karlsson Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/1576759171-28550-10-git-send-email-magnus.karlsson@intel.com","drivers/net/ethernet/intel/i40e/i40e_xsk.c | 4 ++--; drivers/net/ethernet/intel/ice/ice_xsk.c | 4 ++--; drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c | 4 ++--; drivers/net/ethernet/mellanox/mlx5/core/en/xsk/rx.c | 2 +-; include/net/xdp_sock.h | 10 +++++-----; net/xdp/xsk.c | 4 ++--; 6 files changed, 14 insertions(+), 14 deletions(-)","Rename AF_XDP zero-copy driver functions to better reflect new queue manipulation naming conventions.","AF_XDP,drivers,rename","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.","It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.","[""It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here.""]" +"03896ef1f0cb23d2742ddf486c531c700a2da7d6","03896ef1f0cb23d2742ddf486c531c700a2da7d6","Magnus Karlsson","magnus.karlsson@intel.com","1576759167","Alexei Starovoitov","ast@kernel.org","1576886409","d1d460f61ce001d65f104df8fd8cd2a2b08dc486","c5ed924b54c892ee637d2e6889ef83341835a560","xsk: Change names of validation functions Change the names of the validation functions to better reflect what they are doing. The uppermost ones are reading entries from the rings and only the bottom ones validate entries. So xskq_cons_read_ is a better prefix name. Also change the xskq_cons_read_ functions to return a bool as the the descriptor or address is already returned by reference in the parameters. Everyone is using the return value as a bool anyway. Signed-off-by: Magnus Karlsson Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/1576759171-28550-9-git-send-email-magnus.karlsson@intel.com","include/net/xdp_sock.h | 4 ++--; net/xdp/xsk.c | 4 ++--; net/xdp/xsk_queue.h | 59 ++++++++++++++++++++++++++------------------------; 3 files changed, 35 insertions(+), 32 deletions(-)","Refactored xsk validation function names and return types to improve clarity and efficient boolean usage.","xsk,validation,function","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.']" +"c5ed924b54c892ee637d2e6889ef83341835a560","c5ed924b54c892ee637d2e6889ef83341835a560","Magnus Karlsson","magnus.karlsson@intel.com","1576759166","Alexei Starovoitov","ast@kernel.org","1576886409","344a4394b00e50605ff67be098e8ac856ac5647b","df0ae6f78a45e5696427779fc3379c5d75f5d4a5","xsk: Simplify the consumer ring access functions Simplify and refactor consumer ring functions. The consumer first ""peeks"" to find descriptors or addresses that are available to read from the ring, then reads them and finally ""releases"" these descriptors once it is done. The two local variables cons_tail and cons_head are turned into one single variable called cached_cons. cached_tail referred to the cached value of the global consumer pointer and will be stored in cached_cons. For cached_head, we just use cached_prod instead as it was not used for a consumer queue before. It also better reflects what it really is now: a cached copy of the producer pointer. The names of the functions are also renamed in the same manner as the producer functions. The new functions are called xskq_cons_ followed by what it does. Signed-off-by: Magnus Karlsson Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/1576759171-28550-8-git-send-email-magnus.karlsson@intel.com","net/xdp/xsk.c | 24 ++++++-------; net/xdp/xsk_queue.h | 102 ++++++++++++++++++++++++----------------------------; 2 files changed, 58 insertions(+), 68 deletions(-)","Refactor consumer ring functions in xsk to merge variables and align function naming with producer functions.","xsk, refactor, consumer","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.', 'Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"df0ae6f78a45e5696427779fc3379c5d75f5d4a5","df0ae6f78a45e5696427779fc3379c5d75f5d4a5","Magnus Karlsson","magnus.karlsson@intel.com","1576759165","Alexei Starovoitov","ast@kernel.org","1576886409","b9fb5ed45494976d052e46d5c461efc3189b7f73","4b638f13bab4dbfe8569c84e374e8201a427115c","xsk: Simplify xskq_nb_avail and xskq_nb_free At this point, there are no users of the functions xskq_nb_avail and xskq_nb_free that take any other number of entries argument than 1, so let us get rid of the second argument that takes the number of entries. Signed-off-by: Magnus Karlsson Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/1576759171-28550-7-git-send-email-magnus.karlsson@intel.com","net/xdp/xsk_queue.h | 24 +++++++++++++-----------; 1 file changed, 13 insertions(+), 11 deletions(-)","Simplify XDP socket functions by removing redundant arguments.","xsk,simplify,XDP","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.', 'Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"4b638f13bab4dbfe8569c84e374e8201a427115c","4b638f13bab4dbfe8569c84e374e8201a427115c","Magnus Karlsson","magnus.karlsson@intel.com","1576759164","Alexei Starovoitov","ast@kernel.org","1576886409","49b18b735e3810ca3dcd0f6375eb9f7dc4740982","59e35e552529b858f35b30bc5a803ea532ca17f1","xsk: Eliminate the RX batch size In the xsk consumer ring code there is a variable called RX_BATCH_SIZE that dictates the minimum number of entries that we try to grab from the fill and Tx rings. In fact, the code always try to grab the maximum amount of entries from these rings. The only thing this variable does is to throw an error if there is less than 16 (as it is defined) entries on the ring. There is no reason to do this and it will just lead to weird behavior from user space's point of view. So eliminate this variable. With this change, we will be able to simplify the xskq_nb_free and xskq_nb_avail code in the next commit. Signed-off-by: Magnus Karlsson Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/1576759171-28550-6-git-send-email-magnus.karlsson@intel.com","net/xdp/xsk_queue.h | 6 ++----; 1 file changed, 2 insertions(+), 4 deletions(-)","This commit eliminates the RX_BATCH_SIZE variable from xsk consumer ring to avoid errors and simplify future code.","RX, xsk, batch","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"59e35e552529b858f35b30bc5a803ea532ca17f1","59e35e552529b858f35b30bc5a803ea532ca17f1","Magnus Karlsson","magnus.karlsson@intel.com","1576759163","Alexei Starovoitov","ast@kernel.org","1576886409","bfb1cc330e07c1a4b544dc0dddeb6d735985b8ed","d7012f05e3ca5aba92770c370895092d4882e8c2","xsk: Standardize naming of producer ring access functions Adopt the naming of the producer ring access functions to have a similar naming convention as the functions in libbpf, but adapted to the kernel. You first reserve a number of entries that you later submit to the global state of the ring. This is much clearer, IMO, than the one that was in the kernel part. Once renamed, we also discover that two functions are actually the same, so remove one of them. Some of the primitive ring submission operations are also the same so break these out into __xskq_prod_submit that the upper level ring access functions can use. Signed-off-by: Magnus Karlsson Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/1576759171-28550-5-git-send-email-magnus.karlsson@intel.com","net/xdp/xsk.c | 20 +++++++++---------; net/xdp/xsk_queue.h | 58 +++++++++++++++++++++++++----------------------------; 2 files changed, 37 insertions(+), 41 deletions(-)","This commit refactors xsk producer ring access functions to standardize naming and improve clarity by removing redundancies.","xsk,naming,refactor","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.']" +"d7012f05e3ca5aba92770c370895092d4882e8c2","d7012f05e3ca5aba92770c370895092d4882e8c2","Magnus Karlsson","magnus.karlsson@intel.com","1576759162","Alexei Starovoitov","ast@kernel.org","1576886409","864e1def2e5a94e91cd47aa58ac4672223fa3683","11cc2d21499cabe7e7964389634ed1de3ee91d33","xsk: Consolidate to one single cached producer pointer Currently, the xsk ring code has two cached producer pointers: prod_head and prod_tail. This patch consolidates these two into a single one called cached_prod to make the code simpler and easier to maintain. This will be in line with the user space part of the the code found in libbpf, that only uses a single cached pointer. The Rx path only uses the two top level functions xskq_produce_batch_desc and xskq_produce_flush_desc and they both use prod_head and never prod_tail. So just move them over to cached_prod. The Tx XDP_DRV path uses xskq_produce_addr_lazy and xskq_produce_flush_addr_n and unnecessarily operates on both prod_tail and prod_head, so move them over to just use cached_prod by skipping the intermediate step of updating prod_tail. The Tx path in XDP_SKB mode uses xskq_reserve_addr and xskq_produce_addr. They currently use both cached pointers, but we can operate on the global producer pointer in xskq_produce_addr since it has to be updated anyway, thus eliminating the use of both cached pointers. We can also remove the xskq_nb_free in xskq_produce_addr since it is already called in xskq_reserve_addr. No need to do it twice. When there is only one cached producer pointer, we can also simplify xskq_nb_free by removing one argument. Signed-off-by: Magnus Karlsson Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/1576759171-28550-4-git-send-email-magnus.karlsson@intel.com","net/xdp/xsk_queue.h | 47 +++++++++++++++++++++--------------------------; 1 file changed, 21 insertions(+), 26 deletions(-)","Simplifies the xsk ring code by consolidating producer pointers into a single cached_prod for improved maintainability.","xsk,cached_prod,ring","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.', 'XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"11cc2d21499cabe7e7964389634ed1de3ee91d33","11cc2d21499cabe7e7964389634ed1de3ee91d33","Magnus Karlsson","magnus.karlsson@intel.com","1576759161","Alexei Starovoitov","ast@kernel.org","1576886408","3d23f71142bcafac720d438eb99feef14ed219f5","484b165306e18fd9a0d960e6ed2d6eff31665522","xsk: Simplify detection of empty and full rings In order to set the correct return flags for poll, the xsk code has to check if the Rx queue is empty and if the Tx queue is full. This code was unnecessarily large and complex as it used the functions that are used to update the local state from the global state (xskq_nb_free and xskq_nb_avail). Since we are not doing this nor updating any data dependent on this state, we can simplify the functions. Another benefit from this is that we can also simplify the xskq_nb_free and xskq_nb_avail functions in a later commit. Signed-off-by: Magnus Karlsson Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/1576759171-28550-3-git-send-email-magnus.karlsson@intel.com","net/xdp/xsk_queue.h | 7 +++++--; 1 file changed, 5 insertions(+), 2 deletions(-)","This commit refactors xsk code to simplify the detection of empty and full rings in the XDP socket implementation.","simplify,empty,full","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"484b165306e18fd9a0d960e6ed2d6eff31665522","484b165306e18fd9a0d960e6ed2d6eff31665522","Magnus Karlsson","magnus.karlsson@intel.com","1576759160","Alexei Starovoitov","ast@kernel.org","1576886408","cbbe2f1c2d13b417c914c3a0725843b36cd7966a","99cacdc6f661f50f44a0ef006a1a3db20c0577f6","xsk: Eliminate the lazy update threshold The lazy update threshold was introduced to keep the producer and consumer some distance apart in the completion ring. This was important in the beginning of the development of AF_XDP as the ring format as that point in time was very sensitive to the producer and consumer being on the same cache line. This is not the case anymore as the current ring format does not degrade in any noticeable way when this happens. Moreover, this threshold makes it impossible to run the system with rings that have less than 128 entries. So let us remove this threshold and just get one entry from the ring as in all other functions. This will enable us to remove this function in a later commit. Note that xskq_produce_addr_lazy followed by xskq_produce_flush_addr_n are still not the same function as xskq_produce_addr() as it operates on another cached pointer. Signed-off-by: Magnus Karlsson Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/1576759171-28550-2-git-send-email-magnus.karlsson@intel.com","net/xdp/xsk_queue.h | 3 +--; 1 file changed, 1 insertion(+), 2 deletions(-)","Remove the lazy update threshold from AF_XDP to support smaller ring sizes.","xsk lazy update","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"a75af86b6f344f99825cc894596804a91a2ee9cf","a75af86b6f344f99825cc894596804a91a2ee9cf","Arnaldo Carvalho de Melo","acme@redhat.com","1576693394","Arnaldo Carvalho de Melo","acme@redhat.com","1576878940","78c407a74b7f2a1cdccfc110e960b2866ebaf86d","0feba17bd7ee3b7e03d141f119049dcc23efa94e","perf map: Set kmap->kmaps backpointer for main kernel map chunks When a map is create to represent the main kernel area (vmlinux) with map__new2() we allocate an extra area to store a pointer to the 'struct maps' for the kernel maps, so that we can access that struct when loading ELF files or kallsyms, as we will need to split it in multiple maps, one per kernel module or ELF section (such as "".init.text""). So when map->dso->kernel is non-zero, it is expected that map__kmap(map)->kmaps to be set to the tree of kernel maps (modules, chunks of the main kernel, bpf progs put in place via PERF_RECORD_KSYMBOL, the main kernel). This was not the case when we were splitting the main kernel into chunks for its ELF sections, which ended up making 'perf report --children' processing a perf.data file with callchains to trip on __map__is_kernel(), when we press ENTER to see the popup menu for main histogram entries that starts at a symbol in the "".init.text"" ELF section, e.g.: - 8.83% 0.00% swapper [kernel.vmlinux].init.text [k] start_kernel start_kernel cpu_startup_entry do_idle cpuidle_enter cpuidle_enter_state intel_idle Fix it. Reviewed-by: Jiri Olsa Cc: Adrian Hunter Cc: Namhyung Kim Link: https://lore.kernel.org/lkml/20191218190120.GB13282@kernel.org/ Signed-off-by: Arnaldo Carvalho de Melo ","tools/perf/util/symbol-elf.c | 3 +++; 1 file changed, 3 insertions(+)","Fixes the backpointer setup in perf maps for kernel map chunks to properly handle ELF sections in 'perf report'.","perf,kernel,ELF","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.","It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.","[""It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.""]" +"99cacdc6f661f50f44a0ef006a1a3db20c0577f6","99cacdc6f661f50f44a0ef006a1a3db20c0577f6","Alexei Starovoitov","ast@kernel.org","1576819346","Alexei Starovoitov","ast@kernel.org","1576819420","18a302018c3a5b382a58f6c534d9b6ed651bf696","c92bbaa0fda587c6f2397dc7d31f7f3b7b49fa77 06ac0186bd242d44f5703ce64ee0077b317c86bb","Merge branch 'replace-cg_bpf-prog' Andrey Ignatov says: ==================== v3->v4: - use OPTS_VALID and OPTS_GET to handle bpf_prog_attach_opts. v2->v3: - rely on DECLARE_LIBBPF_OPTS from libbpf_common.h; - separate ""required"" and ""optional"" arguments in bpf_prog_attach_xattr; - convert test_cgroup_attach to prog_tests; - move the new selftest to prog_tests/cgroup_attach_multi. v1->v2: - move DECLARE_LIBBPF_OPTS from libbpf.h to bpf.h (patch 4); - switch new libbpf API to OPTS framework; - switch selftest to libbpf OPTS framework. This patch set adds support for replacing cgroup-bpf programs attached with BPF_F_ALLOW_MULTI flag so that any program in a list can be updated to a new version without service interruption and order of programs can be preserved. Please see patch 3 for details on the use-case and API changes. Other patches: Patch 1 is preliminary refactoring of __cgroup_bpf_attach to simplify it. Patch 2 is minor cleanup of hierarchy_allows_attach. Patch 4 extends libbpf API to support new set of attach attributes. Patch 5 converts test_cgroup_attach to prog_tests. Patch 6 adds selftest coverage for the new API. ==================== Signed-off-by: Alexei Starovoitov ","","The commit integrates updates for replacing cgroup-bpf programs with new libbpf API support and selftests.","cgroup-bpf,libbpf,merge","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","['cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups).']" +"06ac0186bd242d44f5703ce64ee0077b317c86bb","06ac0186bd242d44f5703ce64ee0077b317c86bb","Andrey Ignatov","rdna@fb.com","1576741478","Alexei Starovoitov","ast@kernel.org","1576819346","18a302018c3a5b382a58f6c534d9b6ed651bf696","257c88559f360ef40d251942f1f9f0c55f5f91ca","selftests/bpf: Test BPF_F_REPLACE in cgroup_attach_multi Test replacing a cgroup-bpf program attached with BPF_F_ALLOW_MULTI and possible failure modes: invalid combination of flags, invalid replace_bpf_fd, replacing a non-attachd to specified cgroup program. Example of program replacing: # gdb -q --args ./test_progs --name=cgroup_attach_multi ... Breakpoint 1, test_cgroup_attach_multi () at cgroup_attach_multi.c:227 (gdb) [1]+ Stopped gdb -q --args ./test_progs --name=cgroup_attach_multi # bpftool c s /mnt/cgroup2/cgroup-test-work-dir/cg1 ID AttachType AttachFlags Name 2133 egress multi 2134 egress multi # fg gdb -q --args ./test_progs --name=cgroup_attach_multi (gdb) c Continuing. Breakpoint 2, test_cgroup_attach_multi () at cgroup_attach_multi.c:233 (gdb) [1]+ Stopped gdb -q --args ./test_progs --name=cgroup_attach_multi # bpftool c s /mnt/cgroup2/cgroup-test-work-dir/cg1 ID AttachType AttachFlags Name 2139 egress multi 2134 egress multi Signed-off-by: Andrey Ignatov Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/7b9b83e8d5fb82e15b034341bd40b6fb2431eeba.1576741281.git.rdna@fb.com",".../selftests/bpf/prog_tests/cgroup_attach_multi.c | 53 ++++++++++++++++++++--; 1 file changed, 50 insertions(+), 3 deletions(-)","The commit enhances testing for replacing cgroup-bpf programs using BPF_F_REPLACE and handles specific failure modes.","BPF_F_REPLACE,test,cgroup-bpf","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups).']" +"257c88559f360ef40d251942f1f9f0c55f5f91ca","257c88559f360ef40d251942f1f9f0c55f5f91ca","Andrey Ignatov","rdna@fb.com","1576741477","Alexei Starovoitov","ast@kernel.org","1576819346","624427c1bb767f92dad9b7fc4166cc7d99a5c732","cdbee3839cd91a4577425c43cf064b9523926159","selftests/bpf: Convert test_cgroup_attach to prog_tests Convert test_cgroup_attach to prog_tests. This change does a lot of things but in many cases it's pretty expensive to separate them, so they go in one commit. Nevertheless the logic is ketp as is and changes made are just moving things around, simplifying them (w/o changing the meaning of the tests) and making prog_tests compatible: * split the 3 tests in the file into 3 separate files in prog_tests/; * rename the test functions to test_; * remove unused includes, constants, variables and functions from every test; * replace `if`-s with or `if (CHECK())` where additional context should be logged and with `if (CHECK_FAIL())` where line number is enough; * switch from `log_err()` to logging via `CHECK()`; * replace `assert`-s with `CHECK_FAIL()` to avoid crashing the whole test_progs if one assertion fails; * replace cgroup_helpers with test__join_cgroup() in cgroup_attach_override only, other tests need more fine-grained control for cgroup creation/deletion so cgroup_helpers are still used there; * simplify cgroup_attach_autodetach by switching to easiest possible program since this test doesn't really need such a complicated program as cgroup_attach_multi does; * remove test_cgroup_attach.c itself. Signed-off-by: Andrey Ignatov Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/0ff19cc64d2dc5cf404349f07131119480e10e32.1576741281.git.rdna@fb.com","tools/testing/selftests/bpf/.gitignore | 1 -; tools/testing/selftests/bpf/Makefile | 3 +-; .../bpf/prog_tests/cgroup_attach_autodetach.c | 111 ++++; .../selftests/bpf/prog_tests/cgroup_attach_multi.c | 238 +++++++++; .../bpf/prog_tests/cgroup_attach_override.c | 148 ++++++; tools/testing/selftests/bpf/test_cgroup_attach.c | 571 ---------------------; 6 files changed, 498 insertions(+), 574 deletions(-)","The commit refactors selftests by converting test_cgroup_attach into prog_tests and reorganizing related test files for better maintainability.","refactor,selftests,prog_tests","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups).']" +"cdbee3839cd91a4577425c43cf064b9523926159","cdbee3839cd91a4577425c43cf064b9523926159","Andrey Ignatov","rdna@fb.com","1576741476","Alexei Starovoitov","ast@kernel.org","1576819345","8125c9716ca2582a1251363a8cb2a5f4e709fd3d","7dd68b3279f1792103d12e69933db3128c6d416e","libbpf: Introduce bpf_prog_attach_xattr Introduce a new bpf_prog_attach_xattr function that, in addition to program fd, target fd and attach type, accepts an extendable struct bpf_prog_attach_opts. bpf_prog_attach_opts relies on DECLARE_LIBBPF_OPTS macro to maintain backward and forward compatibility and has the following ""optional"" attach attributes: * existing attach_flags, since it's not required when attaching in NONE mode. Even though it's quite often used in MULTI and OVERRIDE mode it seems to be a good idea to reduce number of arguments to bpf_prog_attach_xattr; * newly introduced attribute of BPF_PROG_ATTACH command: replace_prog_fd that is fd of previously attached cgroup-bpf program to replace if BPF_F_REPLACE flag is used. The new function is named to be consistent with other xattr-functions (bpf_prog_test_run_xattr, bpf_create_map_xattr, bpf_load_program_xattr). The struct bpf_prog_attach_opts is supposed to be used with DECLARE_LIBBPF_OPTS macro. Signed-off-by: Andrey Ignatov Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/bd6e0732303eb14e4b79cb128268d9e9ad6db208.1576741281.git.rdna@fb.com","tools/lib/bpf/bpf.c | 17 ++++++++++++++++-; tools/lib/bpf/bpf.h | 11 +++++++++++; tools/lib/bpf/libbpf.map | 1 +; 3 files changed, 28 insertions(+), 1 deletion(-)","This commit introduces a new bpf_prog_attach_xattr function to the libbpf library for program attachment with extended options.","bpf_prog_attach_xattr,libbpf,attach","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","['cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups).']" +"7dd68b3279f1792103d12e69933db3128c6d416e","7dd68b3279f1792103d12e69933db3128c6d416e","Andrey Ignatov","rdna@fb.com","1576741475","Alexei Starovoitov","ast@kernel.org","1576819345","a9473b19e9a591ce50e78ba62239286cb25446b3","9fab329d6a04c0a52a84d207b5e0d83aeb660aa0","bpf: Support replacing cgroup-bpf program in MULTI mode The common use-case in production is to have multiple cgroup-bpf programs per attach type that cover multiple use-cases. Such programs are attached with BPF_F_ALLOW_MULTI and can be maintained by different people. Order of programs usually matters, for example imagine two egress programs: the first one drops packets and the second one counts packets. If they're swapped the result of counting program will be different. It brings operational challenges with updating cgroup-bpf program(s) attached with BPF_F_ALLOW_MULTI since there is no way to replace a program: * One way to update is to detach all programs first and then attach the new version(s) again in the right order. This introduces an interruption in the work a program is doing and may not be acceptable (e.g. if it's egress firewall); * Another way is attach the new version of a program first and only then detach the old version. This introduces the time interval when two versions of same program are working, what may not be acceptable if a program is not idempotent. It also imposes additional burden on program developers to make sure that two versions of their program can co-exist. Solve the problem by introducing a ""replace"" mode in BPF_PROG_ATTACH command for cgroup-bpf programs being attached with BPF_F_ALLOW_MULTI flag. This mode is enabled by newly introduced BPF_F_REPLACE attach flag and bpf_attr.replace_bpf_fd attribute to pass fd of the old program to replace That way user can replace any program among those attached with BPF_F_ALLOW_MULTI flag without the problems described above. Details of the new API: * If BPF_F_REPLACE is set but replace_bpf_fd doesn't have valid descriptor of BPF program, BPF_PROG_ATTACH will return corresponding error (EINVAL or EBADF). * If replace_bpf_fd has valid descriptor of BPF program but such a program is not attached to specified cgroup, BPF_PROG_ATTACH will return ENOENT. BPF_F_REPLACE is introduced to make the user intent clear, since replace_bpf_fd alone can't be used for this (its default value, 0, is a valid fd). BPF_F_REPLACE also makes it possible to extend the API in the future (e.g. add BPF_F_BEFORE and BPF_F_AFTER if needed). Signed-off-by: Andrey Ignatov Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Acked-by: Andrii Narkyiko Link: https://lore.kernel.org/bpf/30cd850044a0057bdfcaaf154b7d2f39850ba813.1576741281.git.rdna@fb.com","include/linux/bpf-cgroup.h | 4 +++-; include/uapi/linux/bpf.h | 10 ++++++++++; kernel/bpf/cgroup.c | 30 ++++++++++++++++++++++++++----; kernel/bpf/syscall.c | 4 ++--; kernel/cgroup/cgroup.c | 5 +++--; tools/include/uapi/linux/bpf.h | 10 ++++++++++; 6 files changed, 54 insertions(+), 9 deletions(-)","Adds a replace mode for updating cgroup-bpf programs in MULTI mode to avoid program coexistence issues.","replace,cgroup,bpf","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The syscall interface. It changes the system calls through which user-space programs interact with eBPF.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","['cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups).']" +"9fab329d6a04c0a52a84d207b5e0d83aeb660aa0","9fab329d6a04c0a52a84d207b5e0d83aeb660aa0","Andrey Ignatov","rdna@fb.com","1576741474","Alexei Starovoitov","ast@kernel.org","1576819345","2a900b45ac2bb766aa58b589e9c2c6f2d8642f51","1020c1f24a946e7d5d8a67db741b20efcd2cefc5","bpf: Remove unused new_flags in hierarchy_allows_attach() new_flags is unused, remove it. Signed-off-by: Andrey Ignatov Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/2c49b30ab750f93cfef04a1e40b097d70c3a39a1.1576741281.git.rdna@fb.com","kernel/bpf/cgroup.c | 5 ++---; 1 file changed, 2 insertions(+), 3 deletions(-)","Removed the unused variable 'new_flags' from hierarchy_allows_attach function in cgroup.c.","bpf, unused, new_flags","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","['cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups).']" +"1020c1f24a946e7d5d8a67db741b20efcd2cefc5","1020c1f24a946e7d5d8a67db741b20efcd2cefc5","Andrey Ignatov","rdna@fb.com","1576741473","Alexei Starovoitov","ast@kernel.org","1576819345","1278ba8083c8e54bcabcda5647247221a53c9982","c92bbaa0fda587c6f2397dc7d31f7f3b7b49fa77","bpf: Simplify __cgroup_bpf_attach __cgroup_bpf_attach has a lot of identical code to handle two scenarios: BPF_F_ALLOW_MULTI is set and unset. Simplify it by splitting the two main steps: * First, the decision is made whether a new bpf_prog_list entry should be allocated or existing entry should be reused for the new program. This decision is saved in replace_pl pointer; * Next, replace_pl pointer is used to handle both possible states of BPF_F_ALLOW_MULTI flag (set / unset) instead of doing similar work for them separately. This splitting, in turn, allows to make further simplifications: * The check for attaching same program twice in BPF_F_ALLOW_MULTI mode can be done before allocating cgroup storage, so that if user tries to attach same program twice no alloc/free happens as it was before; * pl_was_allocated becomes redundant so it's removed. Signed-off-by: Andrey Ignatov Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/c6193db6fe630797110b0d3ff06c125d093b834c.1576741281.git.rdna@fb.com","kernel/bpf/cgroup.c | 62 ++++++++++++++++++++---------------------------------; 1 file changed, 23 insertions(+), 39 deletions(-)","The commit refactors the __cgroup_bpf_attach function by consolidating logic for handling BPF_F_ALLOW_MULTI flag scenarios.","refactor,cgroup,attach","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The syscall interface. It changes the system calls through which user-space programs interact with eBPF.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","['cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups).']" +"c92bbaa0fda587c6f2397dc7d31f7f3b7b49fa77","c92bbaa0fda587c6f2397dc7d31f7f3b7b49fa77","Alexei Starovoitov","ast@kernel.org","1576818584","Alexei Starovoitov","ast@kernel.org","1576818627","39d15968f69918489e4ade622fc4808575f8edbe","5bf2fc1f9c88397b125d5ec5f65b1ed9300ba59d 1170beaa3fa3c3381fd820e9d05b84d168fe1dab","Merge branch 'simplify-do_redirect' Björn Töpel says: ==================== This series aims to simplify the XDP maps and xdp_do_redirect_map()/xdp_do_flush_map(), and to crank out some more performance from XDP_REDIRECT scenarios. The first part of the series simplifies all XDP_REDIRECT capable maps, so that __XXX_flush_map() does not require the map parameter, by moving the flush list from the map to global scope. This results in that the map_to_flush member can be removed from struct bpf_redirect_info, and its corresponding logic. Simpler code, and more performance due to that checks/code per-packet is moved to flush. Pre-series performance: $ sudo taskset -c 22 ./xdpsock -i enp134s0f0 -q 20 -n 1 -r -z sock0@enp134s0f0:20 rxdrop xdp-drv pps pkts 1.00 rx 20,797,350 230,942,399 tx 0 0 $ sudo ./xdp_redirect_cpu --dev enp134s0f0 --cpu 22 xdp_cpu_map0 Running XDP/eBPF prog_name:xdp_cpu_map5_lb_hash_ip_pairs XDP-cpumap CPU:to pps drop-pps extra-info XDP-RX 20 7723038 0 0 XDP-RX total 7723038 0 cpumap_kthread total 0 0 0 redirect_err total 0 0 xdp_exception total 0 0 Post-series performance: $ sudo taskset -c 22 ./xdpsock -i enp134s0f0 -q 20 -n 1 -r -z sock0@enp134s0f0:20 rxdrop xdp-drv pps pkts 1.00 rx 21,524,979 86,835,327 tx 0 0 $ sudo ./xdp_redirect_cpu --dev enp134s0f0 --cpu 22 xdp_cpu_map0 Running XDP/eBPF prog_name:xdp_cpu_map5_lb_hash_ip_pairs XDP-cpumap CPU:to pps drop-pps extra-info XDP-RX 20 7840124 0 0 XDP-RX total 7840124 0 cpumap_kthread total 0 0 0 redirect_err total 0 0 xdp_exception total 0 0 Results: +3.5% and +1.5% for the ubenchmarks. v1->v2 [1]: * Removed 'unused-variable' compiler warning (Jakub) [1] https://lore.kernel.org/bpf/20191218105400.2895-1-bjorn.topel@gmail.com/ ==================== Signed-off-by: Alexei Starovoitov ","","This commit merges a branch that simplifies and optimizes XDP_REDIRECT scenarios for better performance.","XDP merge performance","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.']" +"1170beaa3fa3c3381fd820e9d05b84d168fe1dab","1170beaa3fa3c3381fd820e9d05b84d168fe1dab","Björn Töpel","bjorn.topel@intel.com","1576735806","Alexei Starovoitov","ast@kernel.org","1576818583","39d15968f69918489e4ade622fc4808575f8edbe","332f22a60e4c3492d4953cd6f7aaa4e8bd0bba97","xdp: Simplify __bpf_tx_xdp_map() The explicit error checking is not needed. Simply return the error instead. Signed-off-by: Björn Töpel Signed-off-by: Alexei Starovoitov Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/20191219061006.21980-9-bjorn.topel@gmail.com","net/core/filter.c | 33 +++++++--------------------------; 1 file changed, 7 insertions(+), 26 deletions(-)","The commit simplifies the __bpf_tx_xdp_map function by removing explicit error checking and directly returning the error.","simplify,error checking,__bpf_tx_xdp_map","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.']" +"332f22a60e4c3492d4953cd6f7aaa4e8bd0bba97","332f22a60e4c3492d4953cd6f7aaa4e8bd0bba97","Björn Töpel","bjorn.topel@intel.com","1576735805","Alexei Starovoitov","ast@kernel.org","1576818583","10a498f29010e5fcb2480100956a7128c18d3556","cdfafe98cabefeedbbc65af5c191c59745c03298","xdp: Remove map_to_flush and map swap detection Now that all XDP maps that can be used with bpf_redirect_map() tracks entries to be flushed in a global fashion, there is not need to track that the map has changed and flush from xdp_do_generic_map() anymore. All entries will be flushed in xdp_do_flush_map(). This means that the map_to_flush can be removed, and the corresponding checks. Moving the flush logic to one place, xdp_do_flush_map(), give a bulking behavior and performance boost. Signed-off-by: Björn Töpel Signed-off-by: Alexei Starovoitov Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/20191219061006.21980-8-bjorn.topel@gmail.com","include/linux/filter.h | 1 -; net/core/filter.c | 27 +++------------------------; 2 files changed, 3 insertions(+), 25 deletions(-)","The commit improves the XDP flush logic by centralizing it in xdp_do_flush_map and removing obsolete code for better performance.","xdp,flush,performance","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"cdfafe98cabefeedbbc65af5c191c59745c03298","cdfafe98cabefeedbbc65af5c191c59745c03298","Björn Töpel","bjorn.topel@intel.com","1576735804","Alexei Starovoitov","ast@kernel.org","1576818583","36cf6f6f90c5c1d3aeccbac41dc4f79b3881a060","96360004b8628541f5d05a845ea213267db0b1a2","xdp: Make cpumap flush_list common for all map instances The cpumap flush list is used to track entries that need to flushed from via the xdp_do_flush_map() function. This list used to be per-map, but there is really no reason for that. Instead make the flush list global for all devmaps, which simplifies __cpu_map_flush() and cpu_map_alloc(). Signed-off-by: Björn Töpel Signed-off-by: Alexei Starovoitov Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/20191219061006.21980-7-bjorn.topel@gmail.com","include/linux/bpf.h | 4 ++--; kernel/bpf/cpumap.c | 36 ++++++++++++++++++------------------; net/core/filter.c | 2 +-; 3 files changed, 21 insertions(+), 21 deletions(-)","The commit makes the cpumap flush list global for all map instances to simplify related functions.","cpumap, flush, global","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.']" +"96360004b8628541f5d05a845ea213267db0b1a2","96360004b8628541f5d05a845ea213267db0b1a2","Björn Töpel","bjorn.topel@intel.com","1576735803","Alexei Starovoitov","ast@kernel.org","1576818583","1a47c444945d3344e95374bc598bc02f6ff2f088","e312b9e706ed6d94f6cc9088fcd9fbd81de4525c","xdp: Make devmap flush_list common for all map instances The devmap flush list is used to track entries that need to flushed from via the xdp_do_flush_map() function. This list used to be per-map, but there is really no reason for that. Instead make the flush list global for all devmaps, which simplifies __dev_map_flush() and dev_map_init_map(). Signed-off-by: Björn Töpel Signed-off-by: Alexei Starovoitov Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/20191219061006.21980-6-bjorn.topel@gmail.com","include/linux/bpf.h | 4 ++--; kernel/bpf/devmap.c | 35 +++++++++++++----------------------; net/core/filter.c | 2 +-; 3 files changed, 16 insertions(+), 25 deletions(-)","The commit refactors the devmap flush list to be global across all map instances for XDP programs.","devmap, XDP, flushlist","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"e312b9e706ed6d94f6cc9088fcd9fbd81de4525c","e312b9e706ed6d94f6cc9088fcd9fbd81de4525c","Björn Töpel","bjorn.topel@intel.com","1576735802","Alexei Starovoitov","ast@kernel.org","1576818583","9e7eeaba755c57e74ed2c8707ddedfad909e91af","fb5aacdf3603ccbafe1da74eecd132eb4a31e53f","xsk: Make xskmap flush_list common for all map instances The xskmap flush list is used to track entries that need to flushed from via the xdp_do_flush_map() function. This list used to be per-map, but there is really no reason for that. Instead make the flush list global for all xskmaps, which simplifies __xsk_map_flush() and xsk_map_alloc(). Signed-off-by: Björn Töpel Signed-off-by: Alexei Starovoitov Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/20191219061006.21980-5-bjorn.topel@gmail.com","include/net/xdp_sock.h | 11 ++++-------; kernel/bpf/xskmap.c | 18 +++---------------; net/core/filter.c | 9 ++++-----; net/xdp/xsk.c | 17 +++++++++--------; 4 files changed, 20 insertions(+), 35 deletions(-)","The commit makes the xskmap flush list global for all map instances to simplify xsk_map_flush and allocation processes.","xskmap, flush, global","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"fb5aacdf3603ccbafe1da74eecd132eb4a31e53f","fb5aacdf3603ccbafe1da74eecd132eb4a31e53f","Björn Töpel","bjorn.topel@intel.com","1576735801","Alexei Starovoitov","ast@kernel.org","1576818583","6cb41beebe5bf256dee105d14f2ba9101858d19e","4bc188c7f23a5a308d7f15dda1b6a286d74e8954","xdp: Fix graze->grace type-o in cpumap comments Simple spelling fix. Signed-off-by: Björn Töpel Signed-off-by: Alexei Starovoitov Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/20191219061006.21980-4-bjorn.topel@gmail.com","kernel/bpf/cpumap.c | 6 +++---; 1 file changed, 3 insertions(+), 3 deletions(-)","Fixes a typographical error in xdp cpumap comments.","xdp,cpumap,typo","A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"4bc188c7f23a5a308d7f15dda1b6a286d74e8954","4bc188c7f23a5a308d7f15dda1b6a286d74e8954","Björn Töpel","bjorn.topel@intel.com","1576735800","Alexei Starovoitov","ast@kernel.org","1576818583","83c19b0d701bca3d878b02c99c693b7b6df9bb82","0536b85239b8440735cdd910aae0eb076ebbb439","xdp: Simplify cpumap cleanup After the RCU flavor consolidation [1], call_rcu() and synchronize_rcu() waits for preempt-disable regions (NAPI) in addition to the read-side critical sections. As a result of this, the cleanup code in cpumap can be simplified * There is no longer a need to flush in __cpu_map_entry_free, since we know that this has been done when the call_rcu() callback is triggered. * When freeing the map, there is no need to explicitly wait for a flush. It's guaranteed to be done after the synchronize_rcu() call in cpu_map_free(). [1] https://lwn.net/Articles/777036/ Signed-off-by: Björn Töpel Signed-off-by: Alexei Starovoitov Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/20191219061006.21980-3-bjorn.topel@gmail.com","kernel/bpf/cpumap.c | 34 +++++-----------------------------; 1 file changed, 5 insertions(+), 29 deletions(-)","The commit simplifies cpumap cleanup by removing unnecessary flushes due to recent RCU consolidation changes.","cpumap,cleanup,RCU","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.']" +"0536b85239b8440735cdd910aae0eb076ebbb439","0536b85239b8440735cdd910aae0eb076ebbb439","Björn Töpel","bjorn.topel@intel.com","1576735799","Alexei Starovoitov","ast@kernel.org","1576818583","fab5254d7ae58913aca58e39a04d856a016c913a","5bf2fc1f9c88397b125d5ec5f65b1ed9300ba59d","xdp: Simplify devmap cleanup After the RCU flavor consolidation [1], call_rcu() and synchronize_rcu() waits for preempt-disable regions (NAPI) in addition to the read-side critical sections. As a result of this, the cleanup code in devmap can be simplified * There is no longer a need to flush in __dev_map_entry_free, since we know that this has been done when the call_rcu() callback is triggered. * When freeing the map, there is no need to explicitly wait for a flush. It's guaranteed to be done after the synchronize_rcu() call in dev_map_free(). The rcu_barrier() is still needed, so that the map is not freed prior the elements. [1] https://lwn.net/Articles/777036/ Signed-off-by: Björn Töpel Signed-off-by: Alexei Starovoitov Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/20191219061006.21980-2-bjorn.topel@gmail.com","kernel/bpf/devmap.c | 43 +++++--------------------------------------; 1 file changed, 5 insertions(+), 38 deletions(-)","This commit simplifies the devmap cleanup code by removing the need for flushing in __dev_map_entry_free due to RCU improvements.","devmap, RCU, cleanup","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.']" +"0fd260056ef84ede8f444c66a3820811691fe884","0fd260056ef84ede8f444c66a3820811691fe884","David S. Miller","davem@davemloft.net","1576794047","David S. Miller","davem@davemloft.net","1576794047","0d0085f3791dc71f9aef31287c162a946229e01c","6fa9a115fe7ca507ef5618eb753706425741b285 3123d8018d4686cf193806c4e27a9853550ed895","Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf Daniel Borkmann says: ==================== pull-request: bpf 2019-12-19 The following pull-request contains BPF updates for your *net* tree. We've added 10 non-merge commits during the last 8 day(s) which contain a total of 21 files changed, 269 insertions(+), 108 deletions(-). The main changes are: 1) Fix lack of synchronization between xsk wakeup and destroying resources used by xsk wakeup, from Maxim Mikityanskiy. 2) Fix pruning with tail call patching, untrack programs in case of verifier error and fix a cgroup local storage tracking bug, from Daniel Borkmann. 3) Fix clearing skb->tstamp in bpf_redirect() when going from ingress to egress which otherwise cause issues e.g. on fq qdisc, from Lorenz Bauer. 4) Fix compile warning of unused proc_dointvec_minmax_bpf_restricted() when only cBPF is present, from Alexander Lobakin. ==================== Signed-off-by: David S. Miller ","","The commit merges a series of BPF updates into the net tree, including synchronization fixes and warning resolutions.","BPF, merge, updates","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"3123d8018d4686cf193806c4e27a9853550ed895","3123d8018d4686cf193806c4e27a9853550ed895","Daniel Borkmann","daniel@iogearbox.net","1576790391","Alexei Starovoitov","ast@kernel.org","1576791562","7995fcdf2db0c9bc3d6e5015b256b71c81537723","cc52d9140aa920d8d61c7f6de3fff5fea6692ea9","bpf: Add further test_verifier cases for record_func_key Expand dummy prog generation such that we can easily check on return codes and add few more test cases to make sure we keep on tracking pruning behavior. # ./test_verifier [...] #1066/p XDP pkt read, pkt_data <= pkt_meta', bad access 1 OK #1067/p XDP pkt read, pkt_data <= pkt_meta', bad access 2 OK Summary: 1580 PASSED, 0 SKIPPED, 0 FAILED Also verified that JIT dump of added test cases looks good. Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/df7200b6021444fd369376d227de917357285b65.1576789878.git.daniel@iogearbox.net","tools/testing/selftests/bpf/test_verifier.c | 43 +++---; .../testing/selftests/bpf/verifier/ref_tracking.c | 6 +-; tools/testing/selftests/bpf/verifier/runtime_jit.c | 151 +++++++++++++++++++++; 3 files changed, 176 insertions(+), 24 deletions(-)","Adds new test cases to verify pruning behavior and return codes in the BPF verifier.","test,verifier,pruning","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"cc52d9140aa920d8d61c7f6de3fff5fea6692ea9","cc52d9140aa920d8d61c7f6de3fff5fea6692ea9","Daniel Borkmann","daniel@iogearbox.net","1576790390","Alexei Starovoitov","ast@kernel.org","1576791562","9a2cd65e8f4dbe029fcb58884b4baad46352586f","1148f9adbe71415836a18a36c1b4ece999ab0973","bpf: Fix record_func_key to perform backtracking on r3 While testing Cilium with /unreleased/ Linus' tree under BPF-based NodePort implementation, I noticed a strange BPF SNAT engine behavior from time to time. In some cases it would do the correct SNAT/DNAT service translation, but at a random point in time it would just stop and perform an unexpected translation after SYN, SYN/ACK and stack would send a RST back. While initially assuming that there is some sort of a race condition in BPF code, adding trace_printk()s for debugging purposes at some point seemed to have resolved the issue auto-magically. Digging deeper on this Heisenbug and reducing the trace_printk() calls to an absolute minimum, it turns out that a single call would suffice to trigger / not trigger the seen RST issue, even though the logic of the program itself remains unchanged. Turns out the single call changed verifier pruning behavior to get everything to work. Reconstructing a minimal test case, the incorrect JIT dump looked as follows: # bpftool p d j i 11346 0xffffffffc0cba96c: [...] 21: movzbq 0x30(%rdi),%rax 26: cmp $0xd,%rax 2a: je 0x000000000000003a 2c: xor %edx,%edx 2e: movabs $0xffff89cc74e85800,%rsi 38: jmp 0x0000000000000049 3a: mov $0x2,%edx 3f: movabs $0xffff89cc74e85800,%rsi 49: mov -0x224(%rbp),%eax 4f: cmp $0x20,%eax 52: ja 0x0000000000000062 54: add $0x1,%eax 57: mov %eax,-0x224(%rbp) 5d: jmpq 0xffffffffffff6911 62: mov $0x1,%eax [...] Hence, unexpectedly, JIT emitted a direct jump even though retpoline based one would have been needed since in line 2c and 3a we have different slot keys in BPF reg r3. Verifier log of the test case reveals what happened: 0: (b7) r0 = 14 1: (73) *(u8 *)(r1 +48) = r0 2: (71) r0 = *(u8 *)(r1 +48) 3: (15) if r0 == 0xd goto pc+4 R0_w=inv(id=0,umax_value=255,var_off=(0x0; 0xff)) R1=ctx(id=0,off=0,imm=0) R10=fp0 4: (b7) r3 = 0 5: (18) r2 = 0xffff89cc74d54a00 7: (05) goto pc+3 11: (85) call bpf_tail_call#12 12: (b7) r0 = 1 13: (95) exit from 3 to 8: R0_w=inv13 R1=ctx(id=0,off=0,imm=0) R10=fp0 8: (b7) r3 = 2 9: (18) r2 = 0xffff89cc74d54a00 11: safe processed 13 insns (limit 1000000) [...] Second branch is pruned by verifier since considered safe, but issue is that record_func_key() couldn't have seen the index in line 3a and therefore decided that emitting a direct jump at this location was okay. Fix this by reusing our backtracking logic for precise scalar verification in order to prevent pruning on the slot key. This means verifier will track content of r3 all the way backwards and only prune if both scalars were unknown in state equivalence check and therefore poisoned in the first place in record_func_key(). The range is [x,x] in record_func_key() case since the slot always would have to be constant immediate. Correct verification after fix: 0: (b7) r0 = 14 1: (73) *(u8 *)(r1 +48) = r0 2: (71) r0 = *(u8 *)(r1 +48) 3: (15) if r0 == 0xd goto pc+4 R0_w=invP(id=0,umax_value=255,var_off=(0x0; 0xff)) R1=ctx(id=0,off=0,imm=0) R10=fp0 4: (b7) r3 = 0 5: (18) r2 = 0x0 7: (05) goto pc+3 11: (85) call bpf_tail_call#12 12: (b7) r0 = 1 13: (95) exit from 3 to 8: R0_w=invP13 R1=ctx(id=0,off=0,imm=0) R10=fp0 8: (b7) r3 = 2 9: (18) r2 = 0x0 11: (85) call bpf_tail_call#12 12: (b7) r0 = 1 13: (95) exit processed 15 insns (limit 1000000) [...] And correct corresponding JIT dump: # bpftool p d j i 11 0xffffffffc0dc34c4: [...] 21: movzbq 0x30(%rdi),%rax 26: cmp $0xd,%rax 2a: je 0x000000000000003a 2c: xor %edx,%edx 2e: movabs $0xffff9928b4c02200,%rsi 38: jmp 0x0000000000000049 3a: mov $0x2,%edx 3f: movabs $0xffff9928b4c02200,%rsi 49: cmp $0x4,%rdx 4d: jae 0x0000000000000093 4f: and $0x3,%edx 52: mov %edx,%edx 54: cmp %edx,0x24(%rsi) 57: jbe 0x0000000000000093 59: mov -0x224(%rbp),%eax 5f: cmp $0x20,%eax 62: ja 0x0000000000000093 64: add $0x1,%eax 67: mov %eax,-0x224(%rbp) 6d: mov 0x110(%rsi,%rdx,8),%rax 75: test %rax,%rax 78: je 0x0000000000000093 7a: mov 0x30(%rax),%rax 7e: add $0x19,%rax 82: callq 0x000000000000008e 87: pause 89: lfence 8c: jmp 0x0000000000000087 8e: mov %rax,(%rsp) 92: retq 93: mov $0x1,%eax [...] Also explicitly adding explicit env->allow_ptr_leaks to fixup_bpf_calls() since backtracking is enabled under former (direct jumps as well, but use different test). In case of only tracking different map pointers as in c93552c443eb (""bpf: properly enforce index mask to prevent out-of-bounds speculation""), pruning cannot make such short-cuts, neither if there are paths with scalar and non-scalar types as r3. mark_chain_precision() is only needed after we know that register_is_const(). If it was not the case, we already poison the key on first path and non-const key in later paths are not matching the scalar range in regsafe() either. Cilium NodePort testing passes fine as well now. Note, released kernels not affected. Fixes: d2e4c1e6c294 (""bpf: Constant map key tracking for prog array pokes"") Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/ac43ffdeb7386c5bd688761ed266f3722bb39823.1576789878.git.daniel@iogearbox.net","kernel/bpf/verifier.c | 8 +++++++-; 1 file changed, 7 insertions(+), 1 deletion(-)","The commit addresses a bug in the eBPF verifier to correct translation issues related to SNAT/DNAT in NodePort implementations.","bpf, verifier, JIT","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"5bf2fc1f9c88397b125d5ec5f65b1ed9300ba59d","5bf2fc1f9c88397b125d5ec5f65b1ed9300ba59d","Aditya Pakki","pakki001@umn.edu","1576778255","Daniel Borkmann","daniel@iogearbox.net","1576790655","f69fca17e381176879e936428734a9b2a8dc2214","7745ff9842617323adbe24e71c495d5ebd9aa352","bpf: Remove unnecessary assertion on fp_old The two callers of bpf_prog_realloc - bpf_patch_insn_single and bpf_migrate_filter dereference the struct fp_old, before passing it to the function. Thus assertion to check fp_old is unnecessary and can be removed. Signed-off-by: Aditya Pakki Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191219175735.19231-1-pakki001@umn.edu","kernel/bpf/core.c | 2 --; 1 file changed, 2 deletions(-)","The commit removes an unnecessary assertion in the bpf_prog_realloc function.","assertion, bpf_prog_realloc, fp_old","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"1148f9adbe71415836a18a36c1b4ece999ab0973","1148f9adbe71415836a18a36c1b4ece999ab0973","Alexander Lobakin","alobakin@dlink.ru","1576660701","Daniel Borkmann","daniel@iogearbox.net","1576772271","2213331ef48ba5c35c92f2c1194f3d198fda984f","ca8d0fa7cfb8abc4f623d49df210e0b81b32f626","net, sysctl: Fix compiler warning when only cBPF is present proc_dointvec_minmax_bpf_restricted() has been firstly introduced in commit 2e4a30983b0f (""bpf: restrict access to core bpf sysctls"") under CONFIG_HAVE_EBPF_JIT. Then, this ifdef has been removed in ede95a63b5e8 (""bpf: add bpf_jit_limit knob to restrict unpriv allocations""), because a new sysctl, bpf_jit_limit, made use of it. Finally, this parameter has become long instead of integer with fdadd04931c2 (""bpf: fix bpf_jit_limit knob for PAGE_SIZE >= 64K"") and thus, a new proc_dolongvec_minmax_bpf_restricted() has been added. With this last change, we got back to that proc_dointvec_minmax_bpf_restricted() is used only under CONFIG_HAVE_EBPF_JIT, but the corresponding ifdef has not been brought back. So, in configurations like CONFIG_BPF_JIT=y && CONFIG_HAVE_EBPF_JIT=n since v4.20 we have: CC net/core/sysctl_net_core.o net/core/sysctl_net_core.c:292:1: warning: ‘proc_dointvec_minmax_bpf_restricted’ defined but not used [-Wunused-function] 292 | proc_dointvec_minmax_bpf_restricted(struct ctl_table *table, int write, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Suppress this by guarding it with CONFIG_HAVE_EBPF_JIT again. Fixes: fdadd04931c2 (""bpf: fix bpf_jit_limit knob for PAGE_SIZE >= 64K"") Signed-off-by: Alexander Lobakin Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191218091821.7080-1-alobakin@dlink.ru","net/core/sysctl_net_core.c | 2 ++; 1 file changed, 2 insertions(+)","Fixes a compiler warning by reintroducing CONFIG_HAVE_EBPF_JIT conditional for proc_dointvec_minmax_bpf_restricted.","compiler,warning,CONFIG_HAVE_EBPF_JIT","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"7745ff9842617323adbe24e71c495d5ebd9aa352","7745ff9842617323adbe24e71c495d5ebd9aa352","Andrii Nakryiko","andriin@fb.com","1576732863","Daniel Borkmann","daniel@iogearbox.net","1576770476","9a00028c31cdbc78b4b8a6df2a8e4c7af9f1d725","b5c7d0d0f7d4a30ae96c1350df677cb849060b7c","libbpf: Fix another __u64 printf warning Fix yet another printf warning for %llu specifier on ppc64le. This time size_t casting won't work, so cast to verbose `unsigned long long`. Fixes: 166750bc1dd2 (""libbpf: Support libbpf-provided extern variables"") Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191219052103.3515-1-andriin@fb.com","tools/lib/bpf/libbpf.c | 4 ++--; 1 file changed, 2 insertions(+), 2 deletions(-)","This commit fixes a printf warning related to the %llu specifier on ppc64le in the libbpf.c file.","libbpf printf warning","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"b5c7d0d0f7d4a30ae96c1350df677cb849060b7c","b5c7d0d0f7d4a30ae96c1350df677cb849060b7c","Toke Høiland-Jørgensen","toke@redhat.com","1576746156","Daniel Borkmann","daniel@iogearbox.net","1576769152","975c0b1f3f3994d6d75065840ba80c6f52456efe","580205dd4fe800b1e95be8b6df9e2991f975a8ad","libbpf: Fix printing of ulimit value Naresh pointed out that libbpf builds fail on 32-bit architectures because rlimit.rlim_cur is defined as 'unsigned long long' on those architectures. Fix this by using %zu in printf and casting to size_t. Fixes: dc3a2d254782 (""libbpf: Print hint about ulimit when getting permission denied error"") Reported-by: Naresh Kamboju Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191219090236.905059-1-toke@redhat.com","tools/lib/bpf/libbpf.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","This commit fixes a build issue on 32-bit architectures in libbpf by adjusting the printf format for rlimit values.","libbpf,printf,ulimit","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"ca8d0fa7cfb8abc4f623d49df210e0b81b32f626","ca8d0fa7cfb8abc4f623d49df210e0b81b32f626","Daniel Borkmann","daniel@iogearbox.net","1576768849","Daniel Borkmann","daniel@iogearbox.net","1576768853","bc5d84b8543985f1b7c03f1ff1a2c6edc0306cdd","e47304232b373362228bf233f17bd12b11c9aafc c0fdccfd226a1424683d3000d9e08384391210a2","Merge branch 'bpf-fix-xsk-wakeup' Maxim Mikityanskiy says: ==================== This series addresses the issue described in the commit message of the first patch: lack of synchronization between XSK wakeup and destroying the resources used by XSK wakeup. The idea is similar to napi_synchronize. The series contains fixes for the drivers that implement XSK. v2 incorporates changes suggested by Björn: 1. Call synchronize_rcu in Intel drivers only if the XDP program is being unloaded. 2. Don't forget rcu_read_lock when wakeup is called from xsk_poll. 3. Use xs->zc as the condition to call ndo_xsk_wakeup. ==================== Signed-off-by: Daniel Borkmann ","","The commit merges a branch fixing XSK wakeup and synchronization issues with eBPF programs.","XSK,wakeup,synchronization","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"c0fdccfd226a1424683d3000d9e08384391210a2","c0fdccfd226a1424683d3000d9e08384391210a2","Maxim Mikityanskiy","maximmi@mellanox.com","1576599647","Daniel Borkmann","daniel@iogearbox.net","1576768849","bc5d84b8543985f1b7c03f1ff1a2c6edc0306cdd","b3873a5be757b44d51af542a50a6f2a3b6f95284","net/ixgbe: Fix concurrency issues between config flow and XSK Use synchronize_rcu to wait until the XSK wakeup function finishes before destroying the resources it uses: 1. ixgbe_down already calls synchronize_rcu after setting __IXGBE_DOWN. 2. After switching the XDP program, call synchronize_rcu to let ixgbe_xsk_wakeup exit before the XDP program is freed. 3. Changing the number of channels brings the interface down. 4. Disabling UMEM sets __IXGBE_TX_DISABLED before closing hardware resources and resetting xsk_umem. Check that bit in ixgbe_xsk_wakeup to avoid using the XDP ring when it's already destroyed. synchronize_rcu is called from ixgbe_txrx_ring_disable. Signed-off-by: Maxim Mikityanskiy Signed-off-by: Björn Töpel Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191217162023.16011-5-maximmi@mellanox.com","drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 7 ++++++-; drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c | 8 ++++++--; 2 files changed, 12 insertions(+), 3 deletions(-)","The commit fixes concurrency issues between configuration flow and XSK in ixgbe by using synchronize_rcu to manage resources properly.","concurrency,XSK,synchronize_rcu","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.']" +"b3873a5be757b44d51af542a50a6f2a3b6f95284","b3873a5be757b44d51af542a50a6f2a3b6f95284","Maxim Mikityanskiy","maximmi@mellanox.com","1576599645","Daniel Borkmann","daniel@iogearbox.net","1576768849","5881ff638c61189cea401718fdc953a795f331f4","9cf88808ad6a0f1e958e00abd9a081295fe6da0c","net/i40e: Fix concurrency issues between config flow and XSK Use synchronize_rcu to wait until the XSK wakeup function finishes before destroying the resources it uses: 1. i40e_down already calls synchronize_rcu. On i40e_down either __I40E_VSI_DOWN or __I40E_CONFIG_BUSY is set. Check the latter in i40e_xsk_wakeup (the former is already checked there). 2. After switching the XDP program, call synchronize_rcu to let i40e_xsk_wakeup exit before the XDP program is freed. 3. Changing the number of channels brings the interface down (see i40e_prep_for_reset and i40e_pf_quiesce_all_vsi). 4. Disabling UMEM sets __I40E_CONFIG_BUSY, too. Signed-off-by: Maxim Mikityanskiy Signed-off-by: Björn Töpel Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191217162023.16011-4-maximmi@mellanox.com","drivers/net/ethernet/intel/i40e/i40e.h | 2 +-; drivers/net/ethernet/intel/i40e/i40e_main.c | 10 +++++++---; drivers/net/ethernet/intel/i40e/i40e_xsk.c | 4 ++++; 3 files changed, 12 insertions(+), 4 deletions(-)","This commit addresses concurrency issues between configuration flow and XSK in the i40e driver using synchronize_rcu.","concurrency,XSK,i40e","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.","It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.","[""It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.""]" +"9cf88808ad6a0f1e958e00abd9a081295fe6da0c","9cf88808ad6a0f1e958e00abd9a081295fe6da0c","Maxim Mikityanskiy","maximmi@mellanox.com","1576599644","Daniel Borkmann","daniel@iogearbox.net","1576768849","ea8073ee0ed7c7d17b42708ac44d2a5c27936995","06870682087b58398671e8cdc896cd62314c4399","net/mlx5e: Fix concurrency issues between config flow and XSK After disabling resources necessary for XSK (the XDP program, channels, XSK queues), use synchronize_rcu to wait until the XSK wakeup function finishes, before freeing the resources. Suspend XSK wakeups during switching channels. If the XDP program is being removed, synchronize_rcu before closing the old channels to allow XSK wakeup to complete. Signed-off-by: Maxim Mikityanskiy Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191217162023.16011-3-maximmi@mellanox.com","drivers/net/ethernet/mellanox/mlx5/core/en.h | 2 +-; drivers/net/ethernet/mellanox/mlx5/core/en/xdp.h | 22 +++++++++-------------; .../net/ethernet/mellanox/mlx5/core/en/xsk/setup.c | 1 +; .../net/ethernet/mellanox/mlx5/core/en/xsk/tx.c | 2 +-; drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 19 +------------------; 5 files changed, 13 insertions(+), 33 deletions(-)","The commit resolves concurrency issues in the Mellanox driver between config flow and XSK using synchronize_rcu.","concurrency,XSK,synchronize_rcu","A bug fix. It primarily resolves a bug or issue in the code.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.']" +"06870682087b58398671e8cdc896cd62314c4399","06870682087b58398671e8cdc896cd62314c4399","Maxim Mikityanskiy","maximmi@mellanox.com","1576599642","Daniel Borkmann","daniel@iogearbox.net","1576768848","def06aab14ab1c53d12fe4fc7c9f77fec90d0ac7","e47304232b373362228bf233f17bd12b11c9aafc","xsk: Add rcu_read_lock around the XSK wakeup The XSK wakeup callback in drivers makes some sanity checks before triggering NAPI. However, some configuration changes may occur during this function that affect the result of those checks. For example, the interface can go down, and all the resources will be destroyed after the checks in the wakeup function, but before it attempts to use these resources. Wrap this callback in rcu_read_lock to allow driver to synchronize_rcu before actually destroying the resources. xsk_wakeup is a new function that encapsulates calling ndo_xsk_wakeup wrapped into the RCU lock. After this commit, xsk_poll starts using xsk_wakeup and checks xs->zc instead of ndo_xsk_wakeup != NULL to decide ndo_xsk_wakeup should be called. It also fixes a bug introduced with the need_wakeup feature: a non-zero-copy socket may be used with a driver supporting zero-copy, and in this case ndo_xsk_wakeup should not be called, so the xs->zc check is the correct one. Fixes: 77cd0d7b3f25 (""xsk: add support for need_wakeup flag in AF_XDP rings"") Signed-off-by: Maxim Mikityanskiy Signed-off-by: Björn Töpel Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191217162023.16011-2-maximmi@mellanox.com","net/xdp/xsk.c | 22 ++++++++++++++--------; 1 file changed, 14 insertions(+), 8 deletions(-)","The commit adds rcu_read_lock to encapsulate xsk_wakeup ensuring safe resource handling during configuration changes in XDP sockets.","RCU,XSK,wakeup","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.', ""It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here."", ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"580205dd4fe800b1e95be8b6df9e2991f975a8ad","580205dd4fe800b1e95be8b6df9e2991f975a8ad","Alexei Starovoitov","ast@kernel.org","1576721082","Daniel Borkmann","daniel@iogearbox.net","1576768448","839332253b6b6970c1f4f128b0a335c974fb7226","12dd14b230b3c742b80272ecb8a83cdf824625ca","selftests/bpf: Fix test_attach_probe Fix two issues in test_attach_probe: 1. it was not able to parse /proc/self/maps beyond the first line, since %s means parse string until white space. 2. offset has to be accounted for otherwise uprobed address is incorrect. Fixes: 1e8611bbdfc9 (""selftests/bpf: add kprobe/uprobe selftests"") Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20191219020442.1922617-1-ast@kernel.org","tools/testing/selftests/bpf/prog_tests/attach_probe.c | 7 ++++---; 1 file changed, 4 insertions(+), 3 deletions(-)","This commit fixes parsing and offset issues in test_attach_probe for eBPF selftests.","selftests,bpf,fix","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.', 'uprobe/usdt like type user-space dynamic probe programs. It impacts user-space probes for tracing user-space applications. It can be other user-space probes in perf-events.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"12dd14b230b3c742b80272ecb8a83cdf824625ca","12dd14b230b3c742b80272ecb8a83cdf824625ca","Toke Høiland-Jørgensen","toke@redhat.com","1576757234","Daniel Borkmann","daniel@iogearbox.net","1576768126","de0429f72dfcd6f7295d41c1e3affaeb55a51523","7800a3d54a7112e783453e24f5d96a8f230331fa","libbpf: Add missing newline in opts validation macro The error log output in the opts validation macro was missing a newline. Fixes: 2ce8450ef5a3 (""libbpf: add bpf_object__open_{file, mem} w/ extensible opts"") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191219120714.928380-1-toke@redhat.com","tools/lib/bpf/libbpf_internal.h | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","The commit fixes a missing newline in the libbpf error log output for option validation.","libbpf,newline,validation","A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"7800a3d54a7112e783453e24f5d96a8f230331fa","7800a3d54a7112e783453e24f5d96a8f230331fa","Daniel Borkmann","daniel@iogearbox.net","1576767811","Daniel Borkmann","daniel@iogearbox.net","1576767858","8488f7729afe17ede7099c3101d6b038e14e321d","a352a82496d17f210a88b4fe2de7904afdb92003 34bfc10a6e7e573563a700239d302ab5944b3397","Merge branch 'bpf-riscv-jit-improvements' Björn Töpel says: ==================== This series contain one non-critical fix, support for far jumps, and some optimizations for the BPF JIT. Previously, the JIT only supported 12b branch targets for conditional branches, and 21b for unconditional branches. Starting with this series, 32b branching is supported. As part of supporting far jumps, branch relaxation was introduced. The idea is to start with a pessimistic jump (e.g. auipc/jalr) and for each pass the JIT will have an opportunity to pick a better instruction (e.g. jal) and shrink the image. Instead of two passes, the JIT requires more passes. It typically converges after 3 passes. The optimizations mentioned in the subject are for calls and tail calls. In the tail call generation we can save one instruction by using the offset in jalr. Calls are optimized by doing (auipc)/jal(r) relative jumps instead of loading the entire absolute address and doing jalr. This required that the JIT image allocator was made RISC-V specific, so we can ensure that the JIT image and the kernel text are in range (32b). The last two patches of the series is not critical to the series, but are two UAPI build issues for BPF events. A closer look from the RV-folks would be much appreciated. The test_bpf.ko module, selftests/bpf/test_verifier and selftests/seccomp/seccomp_bpf pass all tests. RISC-V is still missing proper kprobe and tracepoint support, so a lot of BPF selftests cannot be run. v1->v2: [1] * Removed unused function parameter from emit_branch() * Added patch to support far branch in tail call emit [1] https://lore.kernel.org/bpf/20191209173136.29615-1-bjorn.topel@gmail.com/ ==================== Signed-off-by: Daniel Borkmann ","","This commit merges RISC-V BPF JIT improvements, adding far jumps and optimizations for call instructions.","RISC-V,BPF,optimizations","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"34bfc10a6e7e573563a700239d302ab5944b3397","34bfc10a6e7e573563a700239d302ab5944b3397","Björn Töpel","bjorn.topel@gmail.com","1576487623","Daniel Borkmann","daniel@iogearbox.net","1576767811","8488f7729afe17ede7099c3101d6b038e14e321d","eb9928bed003dd61a443d0ba51ae066429fbe735","riscv, perf: Add arch specific perf_arch_bpf_user_pt_regs RISC-V was missing a proper perf_arch_bpf_user_pt_regs macro for CONFIG_PERF_EVENT builds. Signed-off-by: Björn Töpel Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191216091343.23260-10-bjorn.topel@gmail.com","arch/riscv/include/asm/perf_event.h | 4 ++++; 1 file changed, 4 insertions(+)","Added architecture-specific perf_arch_bpf_user_pt_regs macro support for RISC-V in perf_event.","RISC-V, perf_event, macro","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Profile related type programs. It affects programs used for profiling system or application performance.', ""It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here."", ""I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear.""]" +"eb9928bed003dd61a443d0ba51ae066429fbe735","eb9928bed003dd61a443d0ba51ae066429fbe735","Björn Töpel","bjorn.topel@gmail.com","1576487622","Daniel Borkmann","daniel@iogearbox.net","1576767811","cc21056d94d0fc083bbac40ea1be996cb0d79572","e368b64f8b0c8066115ad1da71f83f20f7bb43af","riscv, bpf: Add missing uapi header for BPF_PROG_TYPE_PERF_EVENT programs Add missing uapi header the BPF_PROG_TYPE_PERF_EVENT programs by exporting struct user_regs_struct instead of struct pt_regs which is in-kernel only. Signed-off-by: Björn Töpel Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191216091343.23260-9-bjorn.topel@gmail.com","arch/riscv/include/uapi/asm/bpf_perf_event.h | 9 +++++++++; tools/include/uapi/asm/bpf_perf_event.h | 2 ++; 2 files changed, 11 insertions(+)","This commit adds a missing uapi header for BPF_PROG_TYPE_PERF_EVENT programs on RISC-V by exporting struct user_regs_struct.","uapi,RISC-V,BPF_PROG_TYPE_PERF_EVENT","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Profile related type programs. It affects programs used for profiling system or application performance.']" +"e368b64f8b0c8066115ad1da71f83f20f7bb43af","e368b64f8b0c8066115ad1da71f83f20f7bb43af","Björn Töpel","bjorn.topel@gmail.com","1576487621","Daniel Borkmann","daniel@iogearbox.net","1576767811","a66e883c91237ec8aaaec3fa98bf108db620f287","7f3631e88ee6fb13beac333a0e9e605d2414d17f","riscv, bpf: Optimize calls Instead of using emit_imm() and emit_jalr() which can expand to six instructions, start using jal or auipc+jalr. Signed-off-by: Björn Töpel Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191216091343.23260-8-bjorn.topel@gmail.com","arch/riscv/net/bpf_jit_comp.c | 101 ++++++++++++++++++++++++++----------------; 1 file changed, 64 insertions(+), 37 deletions(-)","Optimize RISC-V eBPF JIT by using jal or auipc+jalr for better performance.","RISC-V,JIT,optimization","A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"7f3631e88ee6fb13beac333a0e9e605d2414d17f","7f3631e88ee6fb13beac333a0e9e605d2414d17f","Björn Töpel","bjorn.topel@gmail.com","1576487620","Daniel Borkmann","daniel@iogearbox.net","1576767811","83de14e24c5f18b8d1197c815df60556471a37f6","fe8322b866d560a3b3535ed9aa49df59809decbe","riscv, bpf: Provide RISC-V specific JIT image alloc/free This commit makes sure that the JIT images is kept close to the kernel text, so BPF calls can use relative calling with auipc/jalr or jal instead of loading the full 64-bit address and jalr. The BPF JIT image region is 128 MB before the kernel text. Signed-off-by: Björn Töpel Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191216091343.23260-7-bjorn.topel@gmail.com","arch/riscv/include/asm/pgtable.h | 4 ++++; arch/riscv/net/bpf_jit_comp.c | 13 +++++++++++++; 2 files changed, 17 insertions(+)","The commit optimizes RISC-V BPF JIT compiler to use relative calls by placing JIT images near kernel text.","RISC-V,JIT,BPF","A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"fe8322b866d560a3b3535ed9aa49df59809decbe","fe8322b866d560a3b3535ed9aa49df59809decbe","Björn Töpel","bjorn.topel@gmail.com","1576487619","Daniel Borkmann","daniel@iogearbox.net","1576767811","0f6e0ca6d96aef84a3499b1a177a24d28f9e65f1","33203c02f2f8ae8e19d7dbbabf55cfd0025efede","riscv, bpf: Optimize BPF tail calls Remove one addi, and instead use the offset part of jalr. Signed-off-by: Björn Töpel Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191216091343.23260-6-bjorn.topel@gmail.com","arch/riscv/net/bpf_jit_comp.c | 13 +++++++------; 1 file changed, 7 insertions(+), 6 deletions(-)","Optimize BPF tail calls on RISC-V by using offset part of jalr to improve JIT compilation.","RISC-V, BPF, optimization","A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"33203c02f2f8ae8e19d7dbbabf55cfd0025efede","33203c02f2f8ae8e19d7dbbabf55cfd0025efede","Björn Töpel","bjorn.topel@gmail.com","1576487618","Daniel Borkmann","daniel@iogearbox.net","1576767810","c78d70bc3448490b030379dbc9b87826be37e30a","29d92edd9ee8b37bd8e9a0ba7fd549f874e0d069","riscv, bpf: Add support for far jumps and exits This commit add support for far (offset > 21b) jumps and exits. Signed-off-by: Björn Töpel Signed-off-by: Daniel Borkmann Reviewed-by: Luke Nelson Link: https://lore.kernel.org/bpf/20191216091343.23260-5-bjorn.topel@gmail.com","arch/riscv/net/bpf_jit_comp.c | 37 +++++++++++++++++--------------------; 1 file changed, 17 insertions(+), 20 deletions(-)","This commit enhances the RISC-V eBPF JIT compiler to support far jumps and exits.","RISC-V,far jumps,exits","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"29d92edd9ee8b37bd8e9a0ba7fd549f874e0d069","29d92edd9ee8b37bd8e9a0ba7fd549f874e0d069","Björn Töpel","bjorn.topel@gmail.com","1576487617","Daniel Borkmann","daniel@iogearbox.net","1576767810","fe654fdcbe43e8f5ec7f7ca5825b66bcf4614b33","7d1ef13fea2b66bb466592a7855b33181c85ec5f","riscv, bpf: Add support for far branching when emitting tail call Start use the emit_branch() function in the tail call emitter in order to support far branching. Signed-off-by: Björn Töpel Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191216091343.23260-4-bjorn.topel@gmail.com","arch/riscv/net/bpf_jit_comp.c | 22 +++-------------------; 1 file changed, 3 insertions(+), 19 deletions(-)","This commit adds support for far branching in RISC-V eBPF JIT using the emit_branch function.","far branching,RISC-V,emit_branch","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"7d1ef13fea2b66bb466592a7855b33181c85ec5f","7d1ef13fea2b66bb466592a7855b33181c85ec5f","Björn Töpel","bjorn.topel@gmail.com","1576487616","Daniel Borkmann","daniel@iogearbox.net","1576767810","3f9ede09afc50ed161f939f27bab5e54a607779e","f1003b787c00fbaa4b11619c6b23a885bfce8f07","riscv, bpf: Add support for far branching This commit adds branch relaxation to the BPF JIT, and with that support for far (offset greater than 12b) branching. The branch relaxation requires more than two passes to converge. For most programs it is three passes, but for larger programs it can be more. Signed-off-by: Björn Töpel Signed-off-by: Daniel Borkmann Reviewed-by: Luke Nelson Link: https://lore.kernel.org/bpf/20191216091343.23260-3-bjorn.topel@gmail.com","arch/riscv/net/bpf_jit_comp.c | 352 ++++++++++++++++++++++--------------------; 1 file changed, 188 insertions(+), 164 deletions(-)","The commit adds support for far branching by implementing branch relaxation in the BPF JIT for RISC-V architecture.","far branching,RISC-V,JIT","A new feature. It adds a new capability or feature that was not previously present.","Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"f1003b787c00fbaa4b11619c6b23a885bfce8f07","f1003b787c00fbaa4b11619c6b23a885bfce8f07","Björn Töpel","bjorn.topel@gmail.com","1576487615","Daniel Borkmann","daniel@iogearbox.net","1576767810","b64650e3842ab2900795dde3cd95ac6c487c0c63","a352a82496d17f210a88b4fe2de7904afdb92003","riscv, bpf: Fix broken BPF tail calls The BPF JIT incorrectly clobbered the a0 register, and did not flag usage of s5 register when BPF stack was being used. Fixes: 2353ecc6f91f (""bpf, riscv: add BPF JIT for RV64G"") Signed-off-by: Björn Töpel Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191216091343.23260-2-bjorn.topel@gmail.com","arch/riscv/net/bpf_jit_comp.c | 13 +++++++++++--; 1 file changed, 11 insertions(+), 2 deletions(-)","Fixes a BPF JIT issue on RISC-V by correcting register handling for tail calls.","BPF JIT, RISC-V, registers","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"a352a82496d17f210a88b4fe2de7904afdb92003","a352a82496d17f210a88b4fe2de7904afdb92003","Alexei Starovoitov","ast@kernel.org","1576719217","Alexei Starovoitov","ast@kernel.org","1576719232","3b5e3706df1729956cdd345108858418713ee117","d69587062c347314a019cf6ee27f2e4b494868e1 630628cb7dc39780660d8fcedc66e0298a82f9da","Merge branch 'libbpf-extern-followups' Andrii Nakryiko says: ==================== Based on latest feedback and discussions, this patch set implements the following changes: - Kconfig-provided externs have to be in .kconfig section, for which bpf_helpers.h provides convenient __kconfig macro (Daniel); - instead of allowing to override Kconfig file path, switch this to ability to extend and override system Kconfig with user-provided custom values (Alexei); - BTF is required when externs are used. ==================== Signed-off-by: Alexei Starovoitov ","","The commit merges changes related to configuring externs in libbpf with updates involving Kconfig sections and BTF requirements.","libbpf,Kconfig,BTF","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"630628cb7dc39780660d8fcedc66e0298a82f9da","630628cb7dc39780660d8fcedc66e0298a82f9da","Andrii Nakryiko","andriin@fb.com","1576715316","Alexei Starovoitov","ast@kernel.org","1576719216","3b5e3706df1729956cdd345108858418713ee117","8601fd422148a8f7ff5f7eaf75b6703d5166332c","libbpf: BTF is required when externs are present BTF is required to get type information about extern variables. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191219002837.3074619-4-andriin@fb.com","tools/lib/bpf/libbpf.c | 3 ++-; 1 file changed, 2 insertions(+), 1 deletion(-)","The commit enforces BTF requirement for extern variables in libbpf to access their type information.","BTF,libbpf,externs","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"8601fd422148a8f7ff5f7eaf75b6703d5166332c","8601fd422148a8f7ff5f7eaf75b6703d5166332c","Andrii Nakryiko","andriin@fb.com","1576715315","Alexei Starovoitov","ast@kernel.org","1576719216","b490138fcfb50121dbef61121adccbe6d546172b","81bfdd087bf31a87c5ff25cc7004d5308954a35c","libbpf: Allow to augment system Kconfig through extra optional config Instead of all or nothing approach of overriding Kconfig file location, allow to extend it with extra values and override chosen subset of values though optional user-provided extra config, passed as a string through open options' .kconfig option. If same config key is present in both user-supplied config and Kconfig, user-supplied one wins. This allows applications to more easily test various conditions despite host kernel's real configuration. If all of BPF object's __kconfig externs are satisfied from user-supplied config, system Kconfig won't be read at all. Simplify selftests by not needing to create temporary Kconfig files. Suggested-by: Alexei Starovoitov Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191219002837.3074619-3-andriin@fb.com","tools/lib/bpf/libbpf.c | 204 +++++++++++++--------; tools/lib/bpf/libbpf.h | 8 +-; .../testing/selftests/bpf/prog_tests/core_extern.c | 32 +---; 3 files changed, 132 insertions(+), 112 deletions(-)","This commit allows libbpf to extend Kconfig with user-provided configurations improving testing flexibility.","libbpf,Kconfig,configuration","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"81bfdd087bf31a87c5ff25cc7004d5308954a35c","81bfdd087bf31a87c5ff25cc7004d5308954a35c","Andrii Nakryiko","andriin@fb.com","1576715314","Alexei Starovoitov","ast@kernel.org","1576719216","364a9d81d8f7bd736c22c12e5e7795be1fd50dd6","d69587062c347314a019cf6ee27f2e4b494868e1","libbpf: Put Kconfig externs into .kconfig section Move Kconfig-provided externs into custom .kconfig section. Add __kconfig into bpf_helpers.h for user convenience. Update selftests accordingly. Suggested-by: Daniel Borkmann Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191219002837.3074619-2-andriin@fb.com","tools/bpf/bpftool/gen.c | 8 +--; tools/lib/bpf/bpf_helpers.h | 2 +; tools/lib/bpf/libbpf.c | 58 +++++++++++++---------; tools/testing/selftests/bpf/prog_tests/skeleton.c | 16 +++---; .../testing/selftests/bpf/progs/test_core_extern.c | 20 ++++----; tools/testing/selftests/bpf/progs/test_skeleton.c | 4 +-; 6 files changed, 60 insertions(+), 48 deletions(-)","The commit refactors libbpf by relocating Kconfig externs to a .kconfig section and updating associated selftests.","Kconfig, libbpf, refactor","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"d69587062c347314a019cf6ee27f2e4b494868e1","d69587062c347314a019cf6ee27f2e4b494868e1","Andrii Nakryiko","andriin@fb.com","1576709439","Alexei Starovoitov","ast@kernel.org","1576718267","c399059a6df18b80651de4df41a206deece5360a","6de6c1f840c051017f2308503858ff19344c56b3","libbpf: Add bpf_link__disconnect() API to preserve underlying BPF resource There are cases in which BPF resource (program, map, etc) has to outlive userspace program that ""installed"" it in the system in the first place. When BPF program is attached, libbpf returns bpf_link object, which is supposed to be destroyed after no longer necessary through bpf_link__destroy() API. Currently, bpf_link destruction causes both automatic detachment and frees up any resources allocated to for bpf_link in-memory representation. This is inconvenient for the case described above because of coupling of detachment and resource freeing. This patch introduces bpf_link__disconnect() API call, which marks bpf_link as disconnected from its underlying BPF resouces. This means that when bpf_link is destroyed later, all its memory resources will be freed, but BPF resource itself won't be detached. This design allows to follow strict and resource-leak-free design by default, while giving easy and straightforward way for user code to opt for keeping BPF resource attached beyond lifetime of a bpf_link. For some BPF programs (i.e., FS-based tracepoints, kprobes, raw tracepoint, etc), user has to make sure to pin BPF program to prevent kernel to automatically detach it on process exit. This should typically be achived by pinning BPF program (or map in some cases) in BPF FS. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191218225039.2668205-1-andriin@fb.com","tools/lib/bpf/libbpf.c | 40 ++++++++++++++++++++++++++++++----------; tools/lib/bpf/libbpf.h | 1 +; tools/lib/bpf/libbpf.map | 1 +; 3 files changed, 32 insertions(+), 10 deletions(-)","This commit introduces the bpf_link__disconnect API to manage resource cleanup separately from detachment in libbpf.","bpf_link, API, disconnect","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"6de6c1f840c051017f2308503858ff19344c56b3","6de6c1f840c051017f2308503858ff19344c56b3","Nikita V. Shirokov","tehnerd@tehnerd.com","1576702667","Alexei Starovoitov","ast@kernel.org","1576717558","7a2e27cb5f4e23ab53555c247f4fe25d972c4a83","dacce6412e09b5dce19514e2c4e2a8aab0eb217f","bpf: Allow to change skb mark in test_run allow to pass skb's mark field into bpf_prog_test_run ctx for BPF_PROG_TYPE_SCHED_CLS prog type. that would allow to test bpf programs which are doing decision based on this field Signed-off-by: Nikita V. Shirokov Signed-off-by: Alexei Starovoitov ","net/bpf/test_run.c | 10 +++++++++-; tools/testing/selftests/bpf/prog_tests/skb_ctx.c | 5 +++++; tools/testing/selftests/bpf/progs/test_skb_ctx.c | 1 +; 3 files changed, 15 insertions(+), 1 deletion(-)","This commit allows skb's mark field to be tested in eBPF programs for SCHED_CLS type using bpf_prog_test_run context.","skb,mark,test_run","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['tc related type programs. It affects programs managing traffic control (tc) for queuing or prioritizing network traffic.']" +"dacce6412e09b5dce19514e2c4e2a8aab0eb217f","dacce6412e09b5dce19514e2c4e2a8aab0eb217f","Andrii Nakryiko","andriin@fb.com","1576707427","Alexei Starovoitov","ast@kernel.org","1576717432","fb10d14d7a49877e5518b923f579405abe7fd960","7c43e0d6a526e7734eb854fe242886f52ccd06ac","bpftool: Work-around rst2man conversion bug Work-around what appears to be a bug in rst2man convertion tool, used to create man pages out of reStructureText-formatted documents. If text line starts with dot, rst2man will put it in resulting man file verbatim. This seems to cause man tool to interpret it as a directive/command (e.g., `.bs`), and subsequently not render entire line because it's unrecognized one. Enclose '.xxx' words in extra formatting to work around. Fixes: cb21ac588546 (""bpftool: Add gen subcommand manpage"") Reported-by: Alexei Starovoitov Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20191218214314.2403729-1-andriin@fb.com","tools/bpf/bpftool/gen.c | 4 ++--; 1 file changed, 2 insertions(+), 2 deletions(-)","The commit simplifies the format string in bpftool to ensure compatibility with all libc versions.","bpftool,format,libc","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"f596cf0d8062cb5d0a4513a8b3afca318c13be10","f596cf0d8062cb5d0a4513a8b3afca318c13be10","Alexander Lobakin","alobakin@dlink.ru","1575619661","Paul Burton","paulburton@kernel.org","1576710904","6f74bba6b347b6382056030705a1ebdc4a0de319","f8fffebdea752a25757b906f3dffecf1a59a6194","MIPS: BPF: eBPF JIT: check for MIPS ISA compliance in Kconfig It is completely wrong to check for compile-time MIPS ISA revision in the body of bpf_int_jit_compile() as it may lead to get MIPS JIT fully omitted by the CC while the rest system will think that the JIT is actually present and works [1]. We can check if the selected CPU really supports MIPS eBPF JIT at configure time and avoid such situations when kernel can be built without both JIT and interpreter, but with CONFIG_BPF_SYSCALL=y. [1] https://lore.kernel.org/linux-mips/09d713a59665d745e21d021deeaebe0a@dlink.ru/ Fixes: 716850ab104d (""MIPS: eBPF: Initial eBPF support for MIPS32 architecture."") Cc: # v5.2+ Signed-off-by: Alexander Lobakin Signed-off-by: Paul Burton Cc: Ralf Baechle Cc: James Hogan Cc: Hassan Naveed Cc: Alexei Starovoitov Cc: Daniel Borkmann Cc: Martin KaFai Lau Cc: Song Liu Cc: Yonghong Song Cc: Andrii Nakryiko Cc: linux-mips@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: netdev@vger.kernel.org Cc: bpf@vger.kernel.org","arch/mips/Kconfig | 2 +-; arch/mips/net/ebpf_jit.c | 2 +-; 2 files changed, 2 insertions(+), 2 deletions(-)","The commit modifies eBPF JIT configuration checks for MIPS ISA compliance at compile time to prevent system misconfiguration.","MIPS,JIT,compliance","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"f8fffebdea752a25757b906f3dffecf1a59a6194","f8fffebdea752a25757b906f3dffecf1a59a6194","Paul Burton","paulburton@kernel.org","1575570198","Paul Burton","paulburton@kernel.org","1576710903","b9e528a9aa9470013ba87f3aabc4ab319acf6bf5","a4a3893114a41e365274d5fab5d9ff5acc235ff0","MIPS: BPF: Disable MIPS32 eBPF JIT Commit 716850ab104d (""MIPS: eBPF: Initial eBPF support for MIPS32 architecture."") enabled our eBPF JIT for MIPS32 kernels, whereas it has previously only been availailable for MIPS64. It was my understanding at the time that the BPF test suite was passing & JITing a comparable number of tests to our cBPF JIT [1], but it turns out that was not the case. The eBPF JIT has a number of problems on MIPS32: - Most notably various code paths still result in emission of MIPS64 instructions which will cause reserved instruction exceptions & kernel panics when run on MIPS32 CPUs. - The eBPF JIT doesn't account for differences between the O32 ABI used by MIPS32 kernels versus the N64 ABI used by MIPS64 kernels. Notably arguments beyond the first 4 are passed on the stack in O32, and this is entirely unhandled when JITing a BPF_CALL instruction. Stack space must be reserved for arguments even if they all fit in registers, and the callee is free to assume that stack space has been reserved for its use - with the eBPF JIT this is not the case, so calling any function can result in clobbering values on the stack & unpredictable behaviour. Function arguments in eBPF are always 64-bit values which is also entirely unhandled - the JIT still uses a single (32-bit) register per argument. As a result all function arguments are always passed incorrectly when JITing a BPF_CALL instruction, leading to kernel crashes or strange behavior. - The JIT attempts to bail our on use of ALU64 instructions or 64-bit memory access instructions. The code doing this at the start of build_one_insn() incorrectly checks whether BPF_OP() equals BPF_DW, when it should really be checking BPF_SIZE() & only doing so when BPF_CLASS() is one of BPF_{LD,LDX,ST,STX}. This results in false positives that cause more bailouts than intended, and that in turns hides some of the problems described above. - The kernel's cBPF->eBPF translation makes heavy use of 64-bit eBPF instructions that the MIPS32 eBPF JIT bails out on, leading to most cBPF programs not being JITed at all. Until these problems are resolved, revert the enabling of the eBPF JIT on MIPS32 done by commit 716850ab104d (""MIPS: eBPF: Initial eBPF support for MIPS32 architecture.""). Note that this does not undo the changes made to the eBPF JIT by that commit, since they are a useful starting point to providing MIPS32 support - they're just not nearly complete. [1] https://lore.kernel.org/linux-mips/MWHPR2201MB13583388481F01A422CE7D66D4410@MWHPR2201MB1358.namprd22.prod.outlook.com/ Signed-off-by: Paul Burton Fixes: 716850ab104d (""MIPS: eBPF: Initial eBPF support for MIPS32 architecture."") Cc: Daniel Borkmann Cc: Hassan Naveed Cc: Tony Ambardar Cc: bpf@vger.kernel.org Cc: netdev@vger.kernel.org Cc: # v5.2+ Cc: linux-mips@vger.kernel.org Cc: linux-kernel@vger.kernel.org","arch/mips/Kconfig | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","This commit disables eBPF JIT for MIPS32 due to multiple issues related to instruction emission and argument handling.","MIPS32,JIT,issues","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"58d8dc2a98f50d4741a49e047bd7b322d7692d0b","58d8dc2a98f50d4741a49e047bd7b322d7692d0b","Alexei Starovoitov","ast@kernel.org","1576649796","Alexei Starovoitov","ast@kernel.org","1576649800","2b0baea8a420a4e6949b3ce8f7e9e374a549d186","4a3d6c6a6e4d652808729e7a2a8c3774a5a5c814 cb21ac58854605e6c15fd7da2c619823967b3140","Merge branch 'skel-fixes' Andrii Nakryiko says: ==================== Simplify skeleton usage by embedding source BPF object file inside skeleton itself. This allows to keep skeleton and object file in sync at all times with no chance of confusion. Also, add bpftool-gen.rst manpage, explaining concepts and ideas behind skeleton. In examples section it also includes a complete small BPF application utilizing skeleton, as a demonstration of API. Patch #2 also removes BPF_EMBED_OBJ, as there is currently no use of it. v2->v3: - (void) in no-args function (Alexei); - bpftool-gen.rst code block formatting fix (Alexei); - simplified xxx__create_skeleton to fill in obj and return error code; v1->v2: - remove whitespace from empty lines in code blocks (Yonghong). ==================== Signed-off-by: Alexei Starovoitov ","","This commit merges a branch simplifying the skeleton by embedding the BPF object file and updating its documentation.","merge,skeleton,bpf","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"cb21ac58854605e6c15fd7da2c619823967b3140","cb21ac58854605e6c15fd7da2c619823967b3140","Andrii Nakryiko","andriin@fb.com","1576646752","Alexei Starovoitov","ast@kernel.org","1576649796","2b0baea8a420a4e6949b3ce8f7e9e374a549d186","3bf3c79b772f4155312c000310abab700aba2200","bpftool: Add gen subcommand manpage Add bpftool-gen.rst describing skeleton on the high level. Also include a small, but complete, example BPF app (BPF side, userspace side, generated skeleton) in example section to demonstrate skeleton API and its usage. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20191218052552.2915188-4-andriin@fb.com","tools/bpf/bpftool/Documentation/bpftool-gen.rst | 304 ++++++++++++++++++++++++; tools/bpf/bpftool/Documentation/bpftool.rst | 3 +-; 2 files changed, 306 insertions(+), 1 deletion(-)","The commit adds detailed documentation for the bpftool gen subcommand, including examples of BPF applications.","bpftool, documentation, example","A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"3bf3c79b772f4155312c000310abab700aba2200","3bf3c79b772f4155312c000310abab700aba2200","Andrii Nakryiko","andriin@fb.com","1576646751","Alexei Starovoitov","ast@kernel.org","1576649796","dbac66d5f1291814f9093b7b9d71867e1ce4108c","5dc7a8b2114479fd945956ece9875f747a996a8e","libbpf: Remove BPF_EMBED_OBJ macro from libbpf.h Drop BPF_EMBED_OBJ and struct bpf_embed_data now that skeleton automatically embeds contents of its source object file. While BPF_EMBED_OBJ is useful independently of skeleton, we are currently don't have any use cases utilizing it, so let's remove them until/if we need it. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20191218052552.2915188-3-andriin@fb.com","tools/lib/bpf/libbpf.h | 35 -----------------------------------; 1 file changed, 35 deletions(-)","The commit removes the BPF_EMBED_OBJ macro and related struct from libbpf.h due to lack of utilization.","libbpf, macro, removal","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"5dc7a8b2114479fd945956ece9875f747a996a8e","5dc7a8b2114479fd945956ece9875f747a996a8e","Andrii Nakryiko","andriin@fb.com","1576646750","Alexei Starovoitov","ast@kernel.org","1576649795","1fcb389abfbd012fe1156511a48152f20248b35f","4a3d6c6a6e4d652808729e7a2a8c3774a5a5c814","bpftool, selftests/bpf: Embed object file inside skeleton Embed contents of BPF object file used for BPF skeleton generation inside skeleton itself. This allows to keep BPF object file and its skeleton in sync at all times, and simpifies skeleton instantiation. Also switch existing selftests to not require BPF_EMBED_OBJ anymore. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20191218052552.2915188-2-andriin@fb.com","tools/bpf/bpftool/gen.c | 232 +++++++++++++--------; .../selftests/bpf/prog_tests/attach_probe.c | 4 +-; .../testing/selftests/bpf/prog_tests/core_extern.c | 4 +-; .../selftests/bpf/prog_tests/fentry_fexit.c | 10 +-; .../testing/selftests/bpf/prog_tests/fentry_test.c | 7 +-; tools/testing/selftests/bpf/prog_tests/mmap.c | 4 +-; tools/testing/selftests/bpf/prog_tests/skeleton.c | 4 +-; .../selftests/bpf/prog_tests/stacktrace_build_id.c | 4 +-; .../bpf/prog_tests/stacktrace_build_id_nmi.c | 4 +-; 9 files changed, 154 insertions(+), 119 deletions(-)","Embed BPF object files directly into skeletons to simplify instantiation and maintain synchronization.","bpftool,skeleton,selftests","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"4a3d6c6a6e4d652808729e7a2a8c3774a5a5c814","4a3d6c6a6e4d652808729e7a2a8c3774a5a5c814","Andrii Nakryiko","andriin@fb.com","1576626148","Alexei Starovoitov","ast@kernel.org","1576636715","74110c488b0a1de4b852821d3d75b7294d347d97","fb9a98e160f10555936e1c7041d4efda4954d1df","libbpf: Reduce log level for custom section names Libbpf is trying to recognize BPF program type based on its section name during bpf_object__open() phase. This is not strictly enforced and user code has ability to specify/override correct BPF program type after open. But if BPF program is using custom section name, libbpf will still emit warnings, which can be quite annoying to users. This patch reduces log level of information messages emitted by libbpf if section name is not canonical. User can still get a list of all supported section names as debug-level message. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191217234228.1739308-1-andriin@fb.com","tools/lib/bpf/libbpf.c | 6 +++---; 1 file changed, 3 insertions(+), 3 deletions(-)","The commit reduces log level for non-canonical section names in libbpf to avoid annoying warnings.","libbpf,log level,section","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"fb9a98e160f10555936e1c7041d4efda4954d1df","fb9a98e160f10555936e1c7041d4efda4954d1df","Toke Høiland-Jørgensen","toke@redhat.com","1576582090","Daniel Borkmann","daniel@iogearbox.net","1576624771","37388cee7767d2c3ec34a0004c35319b5075d477","92f7440ecc9331aa1e274273d4a3cb5c58b69706","libbpf: Fix libbpf_common.h when installing libbpf through 'make install' This fixes two issues with the newly introduced libbpf_common.h file: - The header failed to include for the definition of memset() - The new file was not included in the install_headers rule in the Makefile Both of these issues cause breakage when installing libbpf with 'make install' and trying to use it in applications. Fixes: 544402d4b493 (""libbpf: Extract common user-facing helpers"") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20191217112810.768078-1-toke@redhat.com","tools/lib/bpf/Makefile | 1 +; tools/lib/bpf/libbpf_common.h | 2 ++; 2 files changed, 3 insertions(+)","The commit fixes header inclusion and installation issues in libbpf_common.h for libbpf.","libbpf,header,fix","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"92f7440ecc9331aa1e274273d4a3cb5c58b69706","92f7440ecc9331aa1e274273d4a3cb5c58b69706","Andrii Nakryiko","andriin@fb.com","1576563265","Daniel Borkmann","daniel@iogearbox.net","1576624460","2f4f0ff120b290032cf17fa72f56d7c6541c0c27","dbd8f6bae6f4a98aa517aeda6e5276ed4a20f571","selftests/bpf: More succinct Makefile output Similarly to bpftool/libbpf output, make selftests/bpf output succinct per-item output line. Output is roughly as follows: $ make ... CLANG-LLC [test_maps] pyperf600.o CLANG-LLC [test_maps] strobemeta.o CLANG-LLC [test_maps] pyperf100.o EXTRA-OBJ [test_progs] cgroup_helpers.o EXTRA-OBJ [test_progs] trace_helpers.o BINARY test_align BINARY test_verifier_log GEN-SKEL [test_progs] fexit_bpf2bpf.skel.h GEN-SKEL [test_progs] test_global_data.skel.h GEN-SKEL [test_progs] sendmsg6_prog.skel.h ... To see the actual command invocation, verbose mode can be turned on with V=1 argument: $ make V=1 ... very verbose output ... Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20191217061425.2346359-1-andriin@fb.com","tools/testing/selftests/bpf/Makefile | 36 ++++++++++++++++++++++++++++++++++++; 1 file changed, 36 insertions(+)","This commit modifies the Makefile for selftests/bpf to produce more succinct output, similar to bpftool/libbpf.","Makefile,selftests,succinct","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"e47304232b373362228bf233f17bd12b11c9aafc","e47304232b373362228bf233f17bd12b11c9aafc","Daniel Borkmann","daniel@iogearbox.net","1576585696","Alexei Starovoitov","ast@kernel.org","1576601882","b08fea42367c08dec3f9190689f0a6c84dd84068","a2ea07465c8d7984cc6b8b1f0b3324f9b138094a","bpf: Fix cgroup local storage prog tracking Recently noticed that we're tracking programs related to local storage maps through their prog pointer. This is a wrong assumption since the prog pointer can still change throughout the verification process, for example, whenever bpf_patch_insn_single() is called. Therefore, the prog pointer that was assigned via bpf_cgroup_storage_assign() is not guaranteed to be the same as we pass in bpf_cgroup_storage_release() and the map would therefore remain in busy state forever. Fix this by using the prog's aux pointer which is stable throughout verification and beyond. Fixes: de9cbbaadba5 (""bpf: introduce cgroup storage maps"") Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Cc: Roman Gushchin Cc: Martin KaFai Lau Link: https://lore.kernel.org/bpf/1471c69eca3022218666f909bc927a92388fd09e.1576580332.git.daniel@iogearbox.net","include/linux/bpf-cgroup.h | 8 ++++----; kernel/bpf/core.c | 3 +--; kernel/bpf/local_storage.c | 24 ++++++++++++------------; kernel/bpf/verifier.c | 2 +-; 4 files changed, 18 insertions(+), 19 deletions(-)","The commit fixes the handling of cgroup local storage maps by using a stable prog's aux pointer instead of the prog pointer.","cgroup,local,storage","A bug fix. It primarily resolves a bug or issue in the code.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","['cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups).']" +"dbd8f6bae6f4a98aa517aeda6e5276ed4a20f571","dbd8f6bae6f4a98aa517aeda6e5276ed4a20f571","Andrii Nakryiko","andriin@fb.com","1576521509","Alexei Starovoitov","ast@kernel.org","1576536929","33bd45a17977965a56d4d4d5cda180a6b56f5c07","dc3a2d254782dea8e23a55f46129105ecfe787fb","libbpf: Add zlib as a dependency in pkg-config template List zlib as another dependency of libbpf in pkg-config template. Verified it is correctly resolved to proper -lz flag: $ make DESTDIR=/tmp/libbpf-install install $ pkg-config --libs /tmp/libbpf-install/usr/local/lib64/pkgconfig/libbpf.pc -L/usr/local/lib64 -lbpf $ pkg-config --libs --static /tmp/libbpf-install/usr/local/lib64/pkgconfig/libbpf.pc -L/usr/local/lib64 -lbpf -lelf -lz Fixes: 166750bc1dd2 (""libbpf: Support libbpf-provided extern variables"") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Cc: Luca Boccassi Link: https://lore.kernel.org/bpf/20191216183830.3972964-1-andriin@fb.com","tools/lib/bpf/libbpf.pc.template | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","The commit adds zlib dependency to libbpf's pkg-config template for correct flag resolution.","zlib,libbpf,pkg-config","A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"dc3a2d254782dea8e23a55f46129105ecfe787fb","dc3a2d254782dea8e23a55f46129105ecfe787fb","Toke Høiland-Jørgensen","toke@redhat.com","1576519924","Alexei Starovoitov","ast@kernel.org","1576536754","88c4ce73c2fcd58091deac7c297084bdd64a1d81","d50ecc46d18fa19ccf06e0c4d2ee8a050c665e3d","libbpf: Print hint about ulimit when getting permission denied error Probably the single most common error newcomers to XDP are stumped by is the 'permission denied' error they get when trying to load their program and 'ulimit -l' is set too low. For examples, see [0], [1]. Since the error code is UAPI, we can't change that. Instead, this patch adds a few heuristics in libbpf and outputs an additional hint if they are met: If an EPERM is returned on map create or program load, and geteuid() shows we are root, and the current RLIMIT_MEMLOCK is not infinity, we output a hint about raising 'ulimit -l' as an additional log line. [0] https://marc.info/?l=xdp-newbies&m=157043612505624&w=2 [1] https://github.com/xdp-project/xdp-tutorial/issues/86 Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Acked-by: Jesper Dangaard Brouer Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20191216181204.724953-1-toke@redhat.com","tools/lib/bpf/libbpf.c | 29 +++++++++++++++++++++++++++++; 1 file changed, 29 insertions(+)","The commit updates libbpf to provide hints on 'ulimit -l' setting when EPERM errors occur during XDP program load.","libbpf,ulimit,XDP","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.']" +"a2ea07465c8d7984cc6b8b1f0b3324f9b138094a","a2ea07465c8d7984cc6b8b1f0b3324f9b138094a","Daniel Borkmann","daniel@iogearbox.net","1576514940","Alexei Starovoitov","ast@kernel.org","1576522769","ffc04818616b047ecbd2b64f1ae3d9c33108a727","5133498f4ad1123a5ffd4c08df6431dab882cc32","bpf: Fix missing prog untrack in release_maps Commit da765a2f5993 (""bpf: Add poke dependency tracking for prog array maps"") wrongly assumed that in case of prog load errors, we're cleaning up all program tracking via bpf_free_used_maps(). However, it can happen that we're still at the point where we didn't copy map pointers into the prog's aux section such that env->prog->aux->used_maps is still zero, running into a UAF. In such case, the verifier has similar release_maps() helper that drops references to used maps from its env. Consolidate the release code into __bpf_free_used_maps() and call it from all sides to fix it. Fixes: da765a2f5993 (""bpf: Add poke dependency tracking for prog array maps"") Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/1c2909484ca524ae9f55109b06f22b6213e76376.1576514756.git.daniel@iogearbox.net","include/linux/bpf.h | 2 ++; kernel/bpf/core.c | 14 ++++++++++----; kernel/bpf/verifier.c | 14 ++------------; 3 files changed, 14 insertions(+), 16 deletions(-)","Fixes a missing program untrack issue causing use-after-free by consolidating release code for map references in eBPF.","prog,untrack,release","A bug fix. It primarily resolves a bug or issue in the code.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"d50ecc46d18fa19ccf06e0c4d2ee8a050c665e3d","d50ecc46d18fa19ccf06e0c4d2ee8a050c665e3d","Toke Høiland-Jørgensen","toke@redhat.com","1576494462","Alexei Starovoitov","ast@kernel.org","1576508738","b60ffa2c725d450b8f336af5283ddc733ba8da21","450278977acbf494a20367c22fbb38729772d1fc","samples/bpf: Attach XDP programs in driver mode by default When attaching XDP programs, userspace can set flags to request the attach mode (generic/SKB mode, driver mode or hw offloaded mode). If no such flags are requested, the kernel will attempt to attach in driver mode, and then silently fall back to SKB mode if this fails. The silent fallback is a major source of user confusion, as users will try to load a program on a device without XDP support, and instead of an error they will get the silent fallback behaviour, not notice, and then wonder why performance is not what they were expecting. In an attempt to combat this, let's switch all the samples to default to explicitly requesting driver-mode attach. As part of this, ensure that all the userspace utilities have a switch to enable SKB mode. For those that have a switch to request driver mode, keep it but turn it into a no-op. Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Acked-by: Jesper Dangaard Brouer Acked-by: David Ahern Link: https://lore.kernel.org/bpf/20191216110742.364456-1-toke@redhat.com","samples/bpf/xdp1_user.c | 5 ++++-; samples/bpf/xdp_adjust_tail_user.c | 5 ++++-; samples/bpf/xdp_fwd_user.c | 17 ++++++++++++++---; samples/bpf/xdp_redirect_cpu_user.c | 4 ++++; samples/bpf/xdp_redirect_map_user.c | 5 ++++-; samples/bpf/xdp_redirect_user.c | 5 ++++-; samples/bpf/xdp_router_ipv4_user.c | 3 +++; samples/bpf/xdp_rxq_info_user.c | 4 ++++; samples/bpf/xdp_sample_pkts_user.c | 12 +++++++++---; samples/bpf/xdp_tx_iptunnel_user.c | 5 ++++-; samples/bpf/xdpsock_user.c | 5 ++++-; 11 files changed, 58 insertions(+), 12 deletions(-)","The commit modifies eBPF samples to default to driver-mode XDP program attachment to avoid silent fallback confusion.","XDP,driver mode,samples","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"450278977acbf494a20367c22fbb38729772d1fc","450278977acbf494a20367c22fbb38729772d1fc","Toke Høiland-Jørgensen","toke@redhat.com","1576492699","Alexei Starovoitov","ast@kernel.org","1576508592","2102b52a97c2a2ad6d167a3269ed394df385826a","5615ed472dc04e38a1affca69059f17c1178f770","samples/bpf: Set -fno-stack-protector when building BPF programs It seems Clang can in some cases turn on stack protection by default, which doesn't work with BPF. This was reported once before[0], but it seems the flag to explicitly turn off the stack protector wasn't added to the Makefile, so do that now. The symptom of this is compile errors like the following: error: :0:0: in function bpf_prog1 i32 (%struct.__sk_buff*): A call to built-in function '__stack_chk_fail' is not supported. [0] https://www.spinics.net/lists/netdev/msg556400.html Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191216103819.359535-1-toke@redhat.com","samples/bpf/Makefile | 1 +; 1 file changed, 1 insertion(+)","Added -fno-stack-protector flag to the Makefile for building BPF programs to prevent Clang from using unsupported stack protection.","stack-protector,Makefile,Clang","A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"5615ed472dc04e38a1affca69059f17c1178f770","5615ed472dc04e38a1affca69059f17c1178f770","Toke Høiland-Jørgensen","toke@redhat.com","1576491845","Alexei Starovoitov","ast@kernel.org","1576508290","f120a89d2e6bd09c04b1910ab9d47c9c03352c46","5984dc6cb5aa6cce342a44f01f984fde09ed05b1","samples/bpf: Add missing -lz to TPROGS_LDLIBS Since libbpf now links against zlib, this needs to be included in the linker invocation for the userspace programs in samples/bpf that link statically against libbpf. Fixes: 166750bc1dd2 (""libbpf: Support libbpf-provided extern variables"") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Tested-by: Björn Töpel Link: https://lore.kernel.org/bpf/20191216102405.353834-1-toke@redhat.com","samples/bpf/Makefile | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","The commit adds zlib linking to userspace program makefile for static linking with libbpf in samples/bpf.","zlib, libbpf, linker","A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"5984dc6cb5aa6cce342a44f01f984fde09ed05b1","5984dc6cb5aa6cce342a44f01f984fde09ed05b1","Prashant Bhole","prashantbhole.linux@gmail.com","1576480579","Alexei Starovoitov","ast@kernel.org","1576508130","cc43aee99fd5a6bfb59c1bba6b0550a42c82416f","159ecc002b5f55f9c58de533551a2ee552861185","samples/bpf: Reintroduce missed build targets Add xdp_redirect and per_socket_stats_example in build targets. They got removed from build targets in Makefile reorganization. Fixes: 1d97c6c2511f (""samples/bpf: Base target programs rules on Makefile.target"") Signed-off-by: Prashant Bhole Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191216071619.25479-1-prashantbhole.linux@gmail.com","samples/bpf/Makefile | 2 ++; 1 file changed, 2 insertions(+)","The commit adds xdp_redirect and per_socket_stats_example back to the build targets in the samples/bpf Makefile.","build,Makefile,samples","A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"159ecc002b5f55f9c58de533551a2ee552861185","159ecc002b5f55f9c58de533551a2ee552861185","Paul Chaignon","paul.chaignon@orange.com","1576495653","Daniel Borkmann","daniel@iogearbox.net","1576502328","8b7bbbb5764c570fe18d994638fca827b51cd67e","a79ac2d1036a824abba982c33e938b717d1b659f","bpftool: Fix compilation warning on shadowed variable The ident variable has already been declared at the top of the function and doesn't need to be re-declared. Fixes: 985ead416df39 (""bpftool: Add skeleton codegen command"") Signed-off-by: Paul Chaignon Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191216112733.GA28366@Omicron","tools/bpf/bpftool/gen.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","The commit fixes a shadowed variable compilation warning in bpftool by adjusting the variable declaration.","compilation,shadowed,variable","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"a79ac2d1036a824abba982c33e938b717d1b659f","a79ac2d1036a824abba982c33e938b717d1b659f","Prashant Bhole","prashantbhole.linux@gmail.com","1576484858","Daniel Borkmann","daniel@iogearbox.net","1576502056","3a44f2f32c0aacb17577c1b4884cf6076a4c33d2","0849e1028088fb9e3f1de577106b89a513ba986e","libbpf: Fix build by renaming variables In btf__align_of() variable name 't' is shadowed by inner block declaration of another variable with same name. Patch renames variables in order to fix it. CC sharedobjs/btf.o btf.c: In function ‘btf__align_of’: btf.c:303:21: error: declaration of ‘t’ shadows a previous local [-Werror=shadow] 303 | int i, align = 1, t; | ^ btf.c:283:25: note: shadowed declaration is here 283 | const struct btf_type *t = btf__type_by_id(btf, id); | Fixes: 3d208f4ca111 (""libbpf: Expose btf__align_of() API"") Signed-off-by: Prashant Bhole Signed-off-by: Daniel Borkmann Tested-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/20191216082738.28421-1-prashantbhole.linux@gmail.com","tools/lib/bpf/btf.c | 12 ++++++------; 1 file changed, 6 insertions(+), 6 deletions(-)","This commit resolves a variable shadowing issue in the btf__align_of function within libbpf.","libbpf,shadowing,btf","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"0849e1028088fb9e3f1de577106b89a513ba986e","0849e1028088fb9e3f1de577106b89a513ba986e","Alexei Starovoitov","ast@kernel.org","1576457631","Alexei Starovoitov","ast@kernel.org","1576457635","d4caafe2b8a17549f4b088f75beb8044761d7579","01c6f7aaacf982fd80d5e855f0c6187d8155ffed 5f2eeceffb92a0d799b141df7af3d1ac77337dc4","Merge branch 'support-flex-arrays' Andrii Nakryiko says: ==================== Add support for flexible array accesses in a relocatable manner in BPF CO-RE. It's a typical pattern in C, and kernel in particular, to provide a fixed-length struct with zero-sized or dimensionless array at the end. In such cases variable-sized array contents follows immediately after the end of a struct. This patch set adds support for such access pattern by allowing accesses to such arrays. Patch #1 adds libbpf support. Patch #2 adds few test cases for validation. ==================== Signed-off-by: Alexei Starovoitov ","","This commit merges support for flexible array accesses in BPF CO-RE by enhancing libbpf and adding test cases.","flexible, array, libbpf","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"5f2eeceffb92a0d799b141df7af3d1ac77337dc4","5f2eeceffb92a0d799b141df7af3d1ac77337dc4","Andrii Nakryiko","andriin@fb.com","1576393724","Alexei Starovoitov","ast@kernel.org","1576457631","d4caafe2b8a17549f4b088f75beb8044761d7579","1b484b301cec404e8a329f05edf848fc0a5875c0","selftests/bpf: Add flexible array relocation tests Add few tests validation CO-RE relocation handling of flexible array accesses. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191215070844.1014385-3-andriin@fb.com",".../testing/selftests/bpf/prog_tests/core_reloc.c | 4 +++; .../btf__core_reloc_arrays___equiv_zero_sz_arr.c | 3 ++; .../btf__core_reloc_arrays___err_bad_zero_sz_arr.c | 3 ++; .../bpf/progs/btf__core_reloc_arrays___fixed_arr.c | 3 ++; .../testing/selftests/bpf/progs/core_reloc_types.h | 39 ++++++++++++++++++++++; .../selftests/bpf/progs/test_core_reloc_arrays.c | 8 ++---; 6 files changed, 56 insertions(+), 4 deletions(-)","The commit adds tests to validate CO-RE relocation handling of flexible array accesses in BPF selftests.","tests, CO-RE, relocation","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"1b484b301cec404e8a329f05edf848fc0a5875c0","1b484b301cec404e8a329f05edf848fc0a5875c0","Andrii Nakryiko","andriin@fb.com","1576393723","Alexei Starovoitov","ast@kernel.org","1576457630","0841268af64cfe610cc4bad434f6dd7d43ebb3a9","01c6f7aaacf982fd80d5e855f0c6187d8155ffed","libbpf: Support flexible arrays in CO-RE Some data stuctures in kernel are defined with either zero-sized array or flexible (dimensionless) array at the end of a struct. Actual data of such array follows in memory immediately after the end of that struct, forming its variable-sized ""body"" of elements. Support such access pattern in CO-RE relocation handling. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191215070844.1014385-2-andriin@fb.com","tools/lib/bpf/libbpf.c | 34 +++++++++++++++++++++++++++++-----; 1 file changed, 29 insertions(+), 5 deletions(-)","Adds support for flexible arrays in CO-RE relocation handling within libbpf.","flexible, CO-RE, relocation","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"01c6f7aaacf982fd80d5e855f0c6187d8155ffed","01c6f7aaacf982fd80d5e855f0c6187d8155ffed","Alexei Starovoitov","ast@kernel.org","1576456873","Alexei Starovoitov","ast@kernel.org","1576457062","7f0220e2dd38b8f7c99c9b4780c97cd6513be982","f7c0bbf27ec699ec6462751f5e5450c38be4c980 330a73a7b6ca93a415de1b7da68d7a0698fe4937","Merge branch 'extern-var-support' Andrii Nakryiko says: ==================== It's often important for BPF program to know kernel version or some specific config values (e.g., CONFIG_HZ to convert jiffies to seconds) and change or adjust program logic based on their values. As of today, any such need has to be resolved by recompiling BPF program for specific kernel and kernel configuration. In practice this is usually achieved by using BCC and its embedded LLVM/Clang. With such set up #ifdef CONFIG_XXX and similar compile-time constructs allow to deal with kernel varieties. With CO-RE (Compile Once – Run Everywhere) approach, this is not an option, unfortunately. All such logic variations have to be done as a normal C language constructs (i.e., if/else, variables, etc), not a preprocessor directives. This patch series add support for such advanced scenarios through C extern variables. These extern variables will be recognized by libbpf and supplied through extra .extern internal map, similarly to global data. This .extern map is read-only, which allows BPF verifier to track its content precisely as constants. That gives an opportunity to have pre-compiled BPF program, which can potentially use BPF functionality (e.g., BPF helpers) or kernel features (types, fields, etc), that are available only on a subset of targeted kernels, while effectively eleminating (through verifier's dead code detection) such unsupported functionality for other kernels (typically, older versions). Patch #3 explicitly tests a scenario of using unsupported BPF helper, to validate the approach. This patch set heavily relies on BTF type information emitted by compiler for each extern variable declaration. Based on specific types, libbpf does strict checks of config data values correctness. See patch #1 for details. Outline of the patch set: - patch #1 does a small clean up of internal map names contants; - patch #2 adds all of the libbpf internal machinery for externs support, including setting up BTF information for .extern data section; - patch #3 adds support for .extern into BPF skeleton; - patch #4 adds externs selftests, as well as enhances test_skeleton.c test to validate mmap()-ed .extern datasection functionality. v3->v4: - clean up copyrights and rebase onto latest skeleton patches (Alexei); v2->v3: - truncate too long strings (Alexei); - clean ups, adding comments (Alexei); v1->v2: - use BTF type information for externs (Alexei); - add strings support; - add BPF skeleton support for .extern. ==================== Signed-off-by: Alexei Starovoitov ","","The commit merges 'extern-var-support' branch, enabling BPF programs to use extern variables for kernel configuration adaptation using libbpf and BTF.","extern variables libbpf BTF","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"330a73a7b6ca93a415de1b7da68d7a0698fe4937","330a73a7b6ca93a415de1b7da68d7a0698fe4937","Andrii Nakryiko","andriin@fb.com","1576288030","Alexei Starovoitov","ast@kernel.org","1576456872","7f0220e2dd38b8f7c99c9b4780c97cd6513be982","2ad97d473db57ab866f0756806bb94515f7f2551","selftests/bpf: Add tests for libbpf-provided externs Add a set of tests validating libbpf-provided extern variables. One crucial feature that's tested is dead code elimination together with using invalid BPF helper. CONFIG_MISSING is not supposed to exist and should always be specified by libbpf as zero, which allows BPF verifier to correctly do branch pruning and not fail validation, when invalid BPF helper is called from dead if branch. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191214014710.3449601-5-andriin@fb.com",".../testing/selftests/bpf/prog_tests/core_extern.c | 195 +++++++++++++++++++++; tools/testing/selftests/bpf/prog_tests/skeleton.c | 18 +-; .../testing/selftests/bpf/progs/test_core_extern.c | 62 +++++++; tools/testing/selftests/bpf/progs/test_skeleton.c | 9 +; 4 files changed, 283 insertions(+), 1 deletion(-)","This commit introduces tests for libbpf extern variables focusing on dead code elimination and invalid BPF helper handling.","tests, libbpf, externs","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"2ad97d473db57ab866f0756806bb94515f7f2551","2ad97d473db57ab866f0756806bb94515f7f2551","Andrii Nakryiko","andriin@fb.com","1576288029","Alexei Starovoitov","ast@kernel.org","1576456872","6823aff4884341d6aa088f33cc1504375a6d2504","166750bc1dd256b2184b22588fb9fe6d3fbb93ae","bpftool: Generate externs datasec in BPF skeleton Add support for generation of mmap()-ed read-only view of libbpf-provided extern variables. As externs are not supposed to be provided by user code (that's what .data, .bss, and .rodata is for), don't mmap() it initially. Only after skeleton load is performed, map .extern contents as read-only memory. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191214014710.3449601-4-andriin@fb.com","tools/bpf/bpftool/gen.c | 4 ++++; tools/lib/bpf/libbpf.c | 10 +++++-----; 2 files changed, 9 insertions(+), 5 deletions(-)","The commit adds support for generating externs section in BPF skeletons with read-only mmap in bpftool and libbpf.","bpftool, externs, libbpf","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"166750bc1dd256b2184b22588fb9fe6d3fbb93ae","166750bc1dd256b2184b22588fb9fe6d3fbb93ae","Andrii Nakryiko","andriin@fb.com","1576288028","Alexei Starovoitov","ast@kernel.org","1576456872","a91093a7fda21e8d3ef27542f9682e5c6b9490f3","ac9d1389631a4bee0df47e50d6bee8b94230759d","libbpf: Support libbpf-provided extern variables Add support for extern variables, provided to BPF program by libbpf. Currently the following extern variables are supported: - LINUX_KERNEL_VERSION; version of a kernel in which BPF program is executing, follows KERNEL_VERSION() macro convention, can be 4- and 8-byte long; - CONFIG_xxx values; a set of values of actual kernel config. Tristate, boolean, strings, and integer values are supported. Set of possible values is determined by declared type of extern variable. Supported types of variables are: - Tristate values. Are represented as `enum libbpf_tristate`. Accepted values are **strictly** 'y', 'n', or 'm', which are represented as TRI_YES, TRI_NO, or TRI_MODULE, respectively. - Boolean values. Are represented as bool (_Bool) types. Accepted values are 'y' and 'n' only, turning into true/false values, respectively. - Single-character values. Can be used both as a substritute for bool/tristate, or as a small-range integer: - 'y'/'n'/'m' are represented as is, as characters 'y', 'n', or 'm'; - integers in a range [-128, 127] or [0, 255] (depending on signedness of char in target architecture) are recognized and represented with respective values of char type. - Strings. String values are declared as fixed-length char arrays. String of up to that length will be accepted and put in first N bytes of char array, with the rest of bytes zeroed out. If config string value is longer than space alloted, it will be truncated and warning message emitted. Char array is always zero terminated. String literals in config have to be enclosed in double quotes, just like C-style string literals. - Integers. 8-, 16-, 32-, and 64-bit integers are supported, both signed and unsigned variants. Libbpf enforces parsed config value to be in the supported range of corresponding integer type. Integers values in config can be: - decimal integers, with optional + and - signs; - hexadecimal integers, prefixed with 0x or 0X; - octal integers, starting with 0. Config file itself is searched in /boot/config-$(uname -r) location with fallback to /proc/config.gz, unless config path is specified explicitly through bpf_object_open_opts' kernel_config_path option. Both gzipped and plain text formats are supported. Libbpf adds explicit dependency on zlib because of this, but this shouldn't be a problem, given libelf already depends on zlib. All detected extern variables, are put into a separate .extern internal map. It, similarly to .rodata map, is marked as read-only from BPF program side, as well as is frozen on load. This allows BPF verifier to track extern values as constants and perform enhanced branch prediction and dead code elimination. This can be relied upon for doing kernel version/feature detection and using potentially unsupported field relocations or BPF helpers in a CO-RE-based BPF program, while still having a single version of BPF program running on old and new kernels. Selftests are validating this explicitly for unexisting BPF helper. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191214014710.3449601-3-andriin@fb.com","include/uapi/linux/btf.h | 3 +-; tools/include/uapi/linux/btf.h | 7 +-; tools/lib/bpf/Makefile | 15 +-; tools/lib/bpf/bpf_helpers.h | 9 +; tools/lib/bpf/btf.c | 9 +-; tools/lib/bpf/libbpf.c | 738 ++++++++++++++++++++++++++++++++---; tools/lib/bpf/libbpf.h | 12 +-; tools/testing/selftests/bpf/Makefile | 2 +-; 8 files changed, 729 insertions(+), 66 deletions(-)","This commit adds support for extern variables in BPF programs, improving kernel version and configuration compatibility.","libbpf,extern,kernel","A new feature. It adds a new capability or feature that was not previously present.","Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"ac9d1389631a4bee0df47e50d6bee8b94230759d","ac9d1389631a4bee0df47e50d6bee8b94230759d","Andrii Nakryiko","andriin@fb.com","1576288027","Alexei Starovoitov","ast@kernel.org","1576456872","e2b99905083d68668279be7f4bfc94e711708d04","f7c0bbf27ec699ec6462751f5e5450c38be4c980","libbpf: Extract internal map names into constants Instead of duplicating string literals, keep them in one place and consistent. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191214014710.3449601-2-andriin@fb.com","tools/lib/bpf/libbpf.c | 23 ++++++++++++++---------; 1 file changed, 14 insertions(+), 9 deletions(-)","The commit refactors libbpf by extracting internal map names into constants for consistency.","libbpf,constants,refactor","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"f7c0bbf27ec699ec6462751f5e5450c38be4c980","f7c0bbf27ec699ec6462751f5e5450c38be4c980","Alexei Starovoitov","ast@kernel.org","1576454286","Alexei Starovoitov","ast@kernel.org","1576455378","043cb5b03d9de79c156a338750e434077f147e1e","aa915931ac3e53ccf371308e6750da510e3591dd d9c00c3b1639a3c8f46663cc042a3768d222021f","Merge branch 'bpf-obj-skel' Andrii Nakryiko says: ==================== This patch set introduces an alternative and complimentary to existing libbpf API interface for working with BPF objects, maps, programs, and global data from userspace side. This approach is relying on code generation. bpftool produces a struct (a.k.a. skeleton) tailored and specific to provided BPF object file. It includes hard-coded fields and data structures for every map, program, link, and global data present. Altogether this approach significantly reduces amount of userspace boilerplate code required to open, load, attach, and work with BPF objects. It improves attach/detach story, by providing pre-allocated space for bpf_links, and ensuring they are properly detached on shutdown. It allows to do away with by name/title lookups of maps and programs, because libbpf's skeleton API, in conjunction with generated code from bpftool, is filling in hard-coded fields with actual pointers to corresponding struct bpf_map/bpf_program/bpf_link. Also, thanks to BPF array mmap() support, working with global data (variables) from userspace is now as natural as it is from BPF side: each variable is just a struct field inside skeleton struct. Furthermore, this allows to have a natural way for userspace to pre-initialize global data (including previously impossible to initialize .rodata) by just assigning values to the same per-variable fields. Libbpf will carefully take into account this initialization image, will use it to pre-populate BPF maps at creation time, and will re-mmap() BPF map's contents at exactly the same userspace memory address such that it can continue working with all the same pointers without any interruptions. If kernel doesn't support mmap(), global data will still be successfully initialized, but after map creation global data structures inside skeleton will be NULL-ed out. This allows userspace application to gracefully handle lack of mmap() support, if necessary. A bunch of selftests are also converted to using skeletons, demonstrating significant simplification of userspace part of test and reduction in amount of code necessary. v3->v4: - add OPTS_VALID check to btf_dump__emit_type_decl (Alexei); - expose skeleton as LIBBPF_API functions (Alexei); - copyright clean up, update internal map init refactor (Alexei); v2->v3: - make skeleton part of public API; - expose btf_dump__emit_type_decl and btf__align_of APIs; - move LIBBPF_API and DECLARE_LIBBPF_OPTS into libbpf_common.h for reuse; v1->v2: - checkpatch.pl and reverse Christmas tree styling (Jakub); - sanitize variable names to accomodate in-function static vars; rfc->v1: - runqslower moved out into separate patch set waiting for vmlinux.h improvements; - skeleton generation code deals with unknown internal maps more gracefully. ==================== Signed-off-by: Alexei Starovoitov ","","This commit merges changes to introduce libbpf's skeleton API for easier BPF object handling in userspace.","libbpf,skeleton,userspace","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"d9c00c3b1639a3c8f46663cc042a3768d222021f","d9c00c3b1639a3c8f46663cc042a3768d222021f","Andrii Nakryiko","andriin@fb.com","1576287821","Alexei Starovoitov","ast@kernel.org","1576454286","043cb5b03d9de79c156a338750e434077f147e1e","197448eaac1ab330fb485769bccb62346ba1f458","bpftool: Add `gen skeleton` BASH completions Add BASH completions for gen sub-command. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Cc: Quentin Monnet Link: https://lore.kernel.org/bpf/20191214014341.3442258-18-andriin@fb.com","tools/bpf/bpftool/bash-completion/bpftool | 11 +++++++++++; 1 file changed, 11 insertions(+)","The commit adds BASH completions for the 'gen skeleton' sub-command in bpftool, enhancing user interaction utility.","BASH completions,gen skeleton,bpftool","A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"197448eaac1ab330fb485769bccb62346ba1f458","197448eaac1ab330fb485769bccb62346ba1f458","Andrii Nakryiko","andriin@fb.com","1576287820","Alexei Starovoitov","ast@kernel.org","1576454285","90562fef4f4ea13469bed6d53d52fc021014b6a6","dde53c1b763b5038545efa5d812758ce589654e1","selftests/bpf: Add test validating data section to struct convertion layout Add a simple selftests validating datasection-to-struct layour dumping. Global variables are constructed in such a way as to cause both natural and artificial padding (through custom alignment requirement). Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191214014341.3442258-17-andriin@fb.com","tools/testing/selftests/bpf/prog_tests/skeleton.c | 51 +++++++++++++++++++++++; tools/testing/selftests/bpf/progs/test_skeleton.c | 37 ++++++++++++++++; 2 files changed, 88 insertions(+)","The commit adds self-tests for validating data section to struct conversion layout in eBPF self-testing suite.","selftests,bpf,datasection","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"dde53c1b763b5038545efa5d812758ce589654e1","dde53c1b763b5038545efa5d812758ce589654e1","Andrii Nakryiko","andriin@fb.com","1576287819","Alexei Starovoitov","ast@kernel.org","1576454285","be190359c13a29fbb65e4939e992cb3d8ccef3e7","f3c926a4df2cddf6230c3f56b1f43e439552cdad","selftests/bpf: Convert few more selftest to skeletons Convert few more selftests to use generated BPF skeletons as a demonstration on how to use it. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191214014341.3442258-16-andriin@fb.com",".../selftests/bpf/prog_tests/fentry_fexit.c | 105 ++++++++-------------; .../testing/selftests/bpf/prog_tests/fentry_test.c | 72 ++++++--------; tools/testing/selftests/bpf/prog_tests/mmap.c | 58 +++++-------; .../selftests/bpf/prog_tests/stacktrace_build_id.c | 79 ++++++----------; .../bpf/prog_tests/stacktrace_build_id_nmi.c | 84 +++++++----------; 5 files changed, 149 insertions(+), 249 deletions(-)","Converted several selftests to use generated BPF skeletons for demonstration purposes.","selftests,skeletons,convert","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"f3c926a4df2cddf6230c3f56b1f43e439552cdad","f3c926a4df2cddf6230c3f56b1f43e439552cdad","Andrii Nakryiko","andriin@fb.com","1576287818","Alexei Starovoitov","ast@kernel.org","1576454285","492f1d140854b785860b9e126219522c4b30474a","985ead416df39d6fe8e89580cc1db6aa273e0175","selftests/bpf: Add BPF skeletons selftests and convert attach_probe.c Add BPF skeleton generation to selftest/bpf's Makefile. Convert attach_probe.c to use skeleton. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191214014341.3442258-15-andriin@fb.com","tools/testing/selftests/bpf/.gitignore | 2 +; tools/testing/selftests/bpf/Makefile | 36 ++++--; .../selftests/bpf/prog_tests/attach_probe.c | 135 +++++----------------; .../selftests/bpf/progs/test_attach_probe.c | 34 ++----; 4 files changed, 74 insertions(+), 133 deletions(-)","This commit adds BPF skeletons selftests and converts attach_probe.c to BPF skeleton usage within the selftest/bpf directory.","BPF,skeleton,selftests","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"985ead416df39d6fe8e89580cc1db6aa273e0175","985ead416df39d6fe8e89580cc1db6aa273e0175","Andrii Nakryiko","andriin@fb.com","1576287817","Alexei Starovoitov","ast@kernel.org","1576454285","7a03309f571ac4d60d97e432721dd2f2dc20aee7","d66562fba1ce66975bd61b0786fb8b1810f33caa","bpftool: Add skeleton codegen command Add `bpftool gen skeleton` command, which takes in compiled BPF .o object file and dumps a BPF skeleton struct and related code to work with that skeleton. Skeleton itself is tailored to a specific structure of provided BPF object file, containing accessors (just plain struct fields) for every map and program, as well as dedicated space for bpf_links. If BPF program is using global variables, corresponding structure definitions of compatible memory layout are emitted as well, making it possible to initialize and subsequently read/update global variables values using simple and clear C syntax for accessing fields. This skeleton majorly improves usability of opening/loading/attaching of BPF object, as well as interacting with it throughout the lifetime of loaded BPF object. Generated skeleton struct has the following structure: struct { /* used by libbpf's skeleton API */ struct bpf_object_skeleton *skeleton; /* bpf_object for libbpf APIs */ struct bpf_object *obj; struct { /* for every defined map in BPF object: */ struct bpf_map *; } maps; struct { /* for every program in BPF object: */ struct bpf_program *; } progs; struct { /* for every program in BPF object: */ struct bpf_link *; } links; /* for every present global data section: */ struct __ { /* memory layout of corresponding data section, * with every defined variable represented as a struct field * with exactly the same type, but without const/volatile * modifiers, e.g.: */ int *my_var_1; ... } *; }; This provides great usability improvements: - no need to look up maps and programs by name, instead just my_obj->maps.my_map or my_obj->progs.my_prog would give necessary bpf_map/bpf_program pointers, which user can pass to existing libbpf APIs; - pre-defined places for bpf_links, which will be automatically populated for program types that libbpf knows how to attach automatically (currently tracepoints, kprobe/kretprobe, raw tracepoint and tracing programs). On tearing down skeleton, all active bpf_links will be destroyed (meaning BPF programs will be detached, if they are attached). For cases in which libbpf doesn't know how to auto-attach BPF program, user can manually create link after loading skeleton and they will be auto-detached on skeleton destruction: my_obj->links.my_fancy_prog = bpf_program__attach_cgroup_whatever( my_obj->progs.my_fancy_prog, rodata->my_var = 123; my_obj__load(skel); /* 123 will be initialization value for my_var */ After load, if kernel supports mmap() for BPF arrays, user can still read (and write for .bss and .data) variables values, but at that point it will be directly mmap()-ed to BPF array, backing global variables. This allows to seamlessly exchange data with BPF side. From userspace program's POV, all the pointers and memory contents stay the same, but mapped kernel memory changes to point to created map. If kernel doesn't yet support mmap() for BPF arrays, it's still possible to use those data section structs to pre-initialize .bss, .data, and .rodata, but after load their pointers will be reset to NULL, allowing user code to gracefully handle this condition, if necessary. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191214014341.3442258-14-andriin@fb.com","tools/bpf/bpftool/gen.c | 551 +++++++++++++++++++++++++++++++++++++++++++++++; tools/bpf/bpftool/main.c | 3 +-; tools/bpf/bpftool/main.h | 1 +; 3 files changed, 554 insertions(+), 1 deletion(-)","Added a new command to bpftool for generating BPF skeletons to improve usability of BPF object handling.","bpftool,skeleton,command","A new feature. It adds a new capability or feature that was not previously present.","Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"d66562fba1ce66975bd61b0786fb8b1810f33caa","d66562fba1ce66975bd61b0786fb8b1810f33caa","Andrii Nakryiko","andriin@fb.com","1576287816","Alexei Starovoitov","ast@kernel.org","1576454285","1c5a88f4a60ce1d654c48e764de023be0ba678d1","3f51935314b8c0e0f45f28bed2e7a023b2c7627c","libbpf: Add BPF object skeleton support Add new set of APIs, allowing to open/load/attach BPF object through BPF object skeleton, generated by bpftool for a specific BPF object file. All the xxx_skeleton() APIs wrap up corresponding bpf_object_xxx() APIs, but additionally also automate map/program lookups by name, global data initialization and mmap()-ing, etc. All this greatly improves and simplifies userspace usability of working with BPF programs. See follow up patches for examples. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191214014341.3442258-13-andriin@fb.com","tools/lib/bpf/libbpf.c | 162 +++++++++++++++++++++++++++++++++++++++++++++++; tools/lib/bpf/libbpf.h | 38 +++++++++++; tools/lib/bpf/libbpf.map | 5 ++; 3 files changed, 205 insertions(+)","This commit adds BPF object skeleton support in libbpf to enhance userspace interaction with BPF programs.","BPF, libbpf, skeleton","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"3f51935314b8c0e0f45f28bed2e7a023b2c7627c","3f51935314b8c0e0f45f28bed2e7a023b2c7627c","Andrii Nakryiko","andriin@fb.com","1576287815","Alexei Starovoitov","ast@kernel.org","1576454285","089af87388f50b919c56113e808ea3fd7f584ae0","13acb508ae203075134327551a6705e6e8f23d48","libbpf: Reduce log level of supported section names dump It's quite spammy. And now that bpf_object__open() is trying to determine program type from its section name, we are getting these verbose messages all the time. Reduce their log level to DEBUG. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191214014341.3442258-12-andriin@fb.com","tools/lib/bpf/libbpf.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","This commit reduces the verbosity of section name logs in libbpf by setting the log level to DEBUG.","log level, libbpf, debug","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"13acb508ae203075134327551a6705e6e8f23d48","13acb508ae203075134327551a6705e6e8f23d48","Andrii Nakryiko","andriin@fb.com","1576287814","Alexei Starovoitov","ast@kernel.org","1576454285","b5d2652e558a09630556f350f706a714088e98c7","eba9c5f498a11a8558e099d14692c24f2fea27e3","libbpf: Postpone BTF ID finding for TRACING programs to load phase Move BTF ID determination for BPF_PROG_TYPE_TRACING programs to a load phase. Performing it at open step is inconvenient, because it prevents BPF skeleton generation on older host kernel, which doesn't contain BTF_KIND_FUNCs information in vmlinux BTF. This is a common set up, though, when, e.g., selftests are compiled on older host kernel, but the test program itself is executed in qemu VM with bleeding edge kernel. Having this BTF searching performed at load time allows to successfully use bpf_object__open() for codegen and inspection of BPF object file. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191214014341.3442258-11-andriin@fb.com","tools/lib/bpf/libbpf.c | 37 ++++++++++++++++++-------------------; 1 file changed, 18 insertions(+), 19 deletions(-)","Postpones BTF ID finding for TRACING programs to the load phase in libbpf for improved compatibility on older kernels.","BTF ID, TRACING, libbpf","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.']" +"eba9c5f498a11a8558e099d14692c24f2fea27e3","eba9c5f498a11a8558e099d14692c24f2fea27e3","Andrii Nakryiko","andriin@fb.com","1576287813","Alexei Starovoitov","ast@kernel.org","1576454285","3fc0077c3d890005efcc5e456f19780376991c54","01af3bf06755dc5cda7050fe5d898998e5775e63","libbpf: Refactor global data map initialization Refactor global data map initialization to use anonymous mmap()-ed memory instead of malloc()-ed one. This allows to do a transparent re-mmap()-ing of already existing memory address to point to BPF map's memory after bpf_object__load() step (done in follow up patch). This choreographed setup allows to have a nice and unsurprising way to pre-initialize read-only (and r/w as well) maps by user and after BPF map creation keep working with mmap()-ed contents of this map. All in a way that doesn't require user code to update any pointers: the illusion of working with memory contents is preserved before and after actual BPF map instantiation. Selftests and runqslower example demonstrate this feature in follow up patches. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191214014341.3442258-10-andriin@fb.com","tools/lib/bpf/libbpf.c | 97 ++++++++++++++++++++++++++++++--------------------; 1 file changed, 59 insertions(+), 38 deletions(-)","The commit refactors global data map initialization in libbpf to use mmap() instead of malloc for efficient memory management.","libbpf,map,mmap","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"01af3bf06755dc5cda7050fe5d898998e5775e63","01af3bf06755dc5cda7050fe5d898998e5775e63","Andrii Nakryiko","andriin@fb.com","1576287812","Alexei Starovoitov","ast@kernel.org","1576454285","fbfacf758d2ebf276a6ed08123ada06e8ae28f5e","9f81654eebe8de7e0db15534816d8f6c84b2e1e5","libbpf: Expose BPF program's function name Add APIs to get BPF program function name, as opposed to bpf_program__title(), which returns BPF program function's section name. Function name has a benefit of being a valid C identifier and uniquely identifies a specific BPF program, while section name can be duplicated across multiple independent BPF programs. Add also bpf_object__find_program_by_name(), similar to bpf_object__find_program_by_title(), to facilitate looking up BPF programs by their C function names. Convert one of selftests to new API for look up. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191214014341.3442258-9-andriin@fb.com","tools/lib/bpf/libbpf.c | 28 ++++++++++++++++++----; tools/lib/bpf/libbpf.h | 9 +++++--; tools/lib/bpf/libbpf.map | 2 ++; .../testing/selftests/bpf/prog_tests/rdonly_maps.c | 11 ++++-----; 4 files changed, 36 insertions(+), 14 deletions(-)","The commit introduces new APIs for accessing BPF program function names by C identifiers and updates tests to use these APIs.","libbpf,APIs,function name","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"9f81654eebe8de7e0db15534816d8f6c84b2e1e5","9f81654eebe8de7e0db15534816d8f6c84b2e1e5","Andrii Nakryiko","andriin@fb.com","1576287811","Alexei Starovoitov","ast@kernel.org","1576454285","f3ec70c140ca6c5711ade0e0e81d12b9a4c9ac5e","3d208f4ca111a614903f49d5a77b93ddc6de294e","libbpf: Expose BTF-to-C type declaration emitting API Expose API that allows to emit type declaration and field/variable definition (if optional field name is specified) in valid C syntax for any provided BTF type. This is going to be used by bpftool when emitting data section layout as a struct. As part of making this API useful in a stand-alone fashion, move initialization of some of the internal btf_dump state to earlier phase. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191214014341.3442258-8-andriin@fb.com","tools/lib/bpf/btf.h | 22 ++++++++++++++++; tools/lib/bpf/btf_dump.c | 68 ++++++++++++++++++++++++++++++------------------; tools/lib/bpf/libbpf.map | 1 +; 3 files changed, 65 insertions(+), 26 deletions(-)","The commit exposes an API for emitting BTF-to-C type declarations in libbpf, aiding bpftool's data section layout generation.","libbpf,BTF-to-C,API","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"3d208f4ca111a614903f49d5a77b93ddc6de294e","3d208f4ca111a614903f49d5a77b93ddc6de294e","Andrii Nakryiko","andriin@fb.com","1576287810","Alexei Starovoitov","ast@kernel.org","1576454285","f698fa181502b4cacb53743a79fcfbfac6a88960","544402d4b49332a4a9b2b8fff20f9d9f5ef86559","libbpf: Expose btf__align_of() API Expose BTF API that calculates type alignment requirements. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191214014341.3442258-7-andriin@fb.com","tools/lib/bpf/btf.c | 39 +++++++++++++++++++++++++++++++++++++++; tools/lib/bpf/btf.h | 1 +; tools/lib/bpf/btf_dump.c | 47 ++++++-----------------------------------------; tools/lib/bpf/libbpf.map | 1 +; 4 files changed, 47 insertions(+), 41 deletions(-)","The commit introduces a new BTF API function to determine type alignment in the libbpf library.","API, libbpf, alignment","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"544402d4b49332a4a9b2b8fff20f9d9f5ef86559","544402d4b49332a4a9b2b8fff20f9d9f5ef86559","Andrii Nakryiko","andriin@fb.com","1576287809","Alexei Starovoitov","ast@kernel.org","1576454285","aea0437dbae1de2c6db8bc2bf4fd50ad6bc7a191","917f6b7b07a46e53fa73e112d23c97d1b201a877","libbpf: Extract common user-facing helpers LIBBPF_API and DECLARE_LIBBPF_OPTS are needed in many public libbpf API headers. Extract them into libbpf_common.h to avoid unnecessary interdependency between btf.h, libbpf.h, and bpf.h or code duplication. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191214014341.3442258-6-andriin@fb.com","tools/lib/bpf/bpf.h | 6 ++----; tools/lib/bpf/btf.h | 6 ++----; tools/lib/bpf/libbpf.h | 28 ++--------------------------; tools/lib/bpf/libbpf_common.h | 38 ++++++++++++++++++++++++++++++++++++++; 4 files changed, 44 insertions(+), 34 deletions(-)","Refactor libbpf by extracting common macros into libbpf_common.h to reduce header interdependencies and code duplication.","libbpf, macros, interdependency","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"917f6b7b07a46e53fa73e112d23c97d1b201a877","917f6b7b07a46e53fa73e112d23c97d1b201a877","Andrii Nakryiko","andriin@fb.com","1576287808","Alexei Starovoitov","ast@kernel.org","1576454284","75e7c2bb4a79b1849b9cb2fe1d4f93bbb9ca9562","612d05be250aa8804d3baba7a12445a267a580d3","libbpf: Add BPF_EMBED_OBJ macro for embedding BPF .o files Add a convenience macro BPF_EMBED_OBJ, which allows to embed other files (typically used to embed BPF .o files) into a hosting userspace programs. To C program it is exposed as struct bpf_embed_data, containing a pointer to raw data and its size in bytes. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191214014341.3442258-5-andriin@fb.com","tools/lib/bpf/libbpf.h | 35 ++++++++++++++++++++++; .../selftests/bpf/prog_tests/attach_probe.c | 23 ++------------; 2 files changed, 38 insertions(+), 20 deletions(-)","The commit introduces a macro to embed BPF .o files into userspace programs in libbpf.","BPF_EMBED_OBJ,libbpf,macro","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"612d05be250aa8804d3baba7a12445a267a580d3","612d05be250aa8804d3baba7a12445a267a580d3","Andrii Nakryiko","andriin@fb.com","1576287807","Alexei Starovoitov","ast@kernel.org","1576454284","1db52e5cad03e579ed65ba76ca39bd58388d222f","d7a18ea7e8b612669acd0131fd075e5c735c1ce5","libbpf: Move non-public APIs from libbpf.h to libbpf_internal.h Few libbpf APIs are not public but currently exposed through libbpf.h to be used by bpftool. Move them to libbpf_internal.h, where intent of being non-stable and non-public is much more obvious. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191214014341.3442258-4-andriin@fb.com","tools/bpf/bpftool/net.c | 1 +; tools/lib/bpf/libbpf.h | 17 -----------------; tools/lib/bpf/libbpf_internal.h | 17 +++++++++++++++++; 3 files changed, 18 insertions(+), 17 deletions(-)","Non-public libbpf APIs were moved to libbpf_internal.h for improved clarity on their non-public status.","libbpf, internal, APIs","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"d7a18ea7e8b612669acd0131fd075e5c735c1ce5","d7a18ea7e8b612669acd0131fd075e5c735c1ce5","Andrii Nakryiko","andriin@fb.com","1576287806","Alexei Starovoitov","ast@kernel.org","1576454284","7f7ebd5bd4dfb74c107270cd775ce7ec23e28a7a","0d13bfce023ac7cef4d0a50b83750254ce31c479","libbpf: Add generic bpf_program__attach() Generalize BPF program attaching and allow libbpf to auto-detect type (and extra parameters, where applicable) and attach supported BPF program types based on program sections. Currently this is supported for: - kprobe/kretprobe; - tracepoint; - raw tracepoint; - tracing programs (typed raw TP/fentry/fexit). More types support can be trivially added within this framework. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191214014341.3442258-3-andriin@fb.com","tools/lib/bpf/libbpf.c | 181 +++++++++++++++++----; tools/lib/bpf/libbpf.h | 2 +; tools/lib/bpf/libbpf.map | 2 +; .../testing/selftests/bpf/prog_tests/probe_user.c | 6 +-; 4 files changed, 153 insertions(+), 38 deletions(-)","The commit enhances libbpf by adding bpf_program__attach() to generalize BPF program attachment across multiple program types and sections.","libbpf,attach,generalize","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.', 'Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"0d13bfce023ac7cef4d0a50b83750254ce31c479","0d13bfce023ac7cef4d0a50b83750254ce31c479","Andrii Nakryiko","andriin@fb.com","1576287805","Alexei Starovoitov","ast@kernel.org","1576454284","2a0b25e703e11009c64ec522b6e00eef85ac701c","aa915931ac3e53ccf371308e6750da510e3591dd","libbpf: Don't require root for bpf_object__open() Reorganize bpf_object__open and bpf_object__load steps such that bpf_object__open doesn't need root access. This was previously done for feature probing and BTF sanitization. This doesn't have to happen on open, though, so move all those steps into the load phase. This is important, because it makes it possible for tools like bpftool, to just open BPF object file and inspect their contents: programs, maps, BTF, etc. For such operations it is prohibitive to require root access. On the other hand, there is a lot of custom libbpf logic in those steps, so its best avoided for tools to reimplement all that on their own. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191214014341.3442258-2-andriin@fb.com","tools/lib/bpf/libbpf.c | 83 +++++++++++++++++++++++++-------------------------; 1 file changed, 41 insertions(+), 42 deletions(-)","Reorganize libbpf to allow non-root access for inspecting BPF object files by deferring certain actions to the load phase.","libbpf,non-root,inspection","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"aa915931ac3e53ccf371308e6750da510e3591dd","aa915931ac3e53ccf371308e6750da510e3591dd","Thadeu Lima de Souza Cascardo","cascardo@canonical.com","1576231874","Alexei Starovoitov","ast@kernel.org","1576431658","c644355aabba6755693d068e605a90267b6c301b","a06ae6acc14b7f8c07ce9d9685e7b90fcba5b52f","libbpf: Fix readelf output parsing for Fedora Fedora binutils has been patched to show ""other info"" for a symbol at the end of the line. This was done in order to support unmaintained scripts that would break with the extra info. [1] [1] https://src.fedoraproject.org/rpms/binutils/c/b8265c46f7ddae23a792ee8306fbaaeacba83bf8 This in turn has been done to fix the build of ruby, because of checksec. [2] Thanks Michael Ellerman for the pointer. [2] https://bugzilla.redhat.com/show_bug.cgi?id=1479302 As libbpf Makefile is not unmaintained, we can simply deal with either output format, by just removing the ""other info"" field, as it always comes inside brackets. Fixes: 3464afdf11f9 (libbpf: Fix readelf output parsing on powerpc with recent binutils) Reported-by: Justin Forbes Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Cc: Aurelien Jarno Link: https://lore.kernel.org/bpf/20191213101114.GA3986@calabresa","tools/lib/bpf/Makefile | 2 ++; 1 file changed, 2 insertions(+)","This commit fixes libbpf's readelf output parsing to handle Fedora binutils format changes.","libbpf, readelf, Fedora","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"a06ae6acc14b7f8c07ce9d9685e7b90fcba5b52f","a06ae6acc14b7f8c07ce9d9685e7b90fcba5b52f","Alexei Starovoitov","ast@kernel.org","1576429399","Alexei Starovoitov","ast@kernel.org","1576431141","2f81f80c00f4927221ed3ffe7ca1da7162079902","a06bf42f5a95ff462401d59d0c08cf4620213647 99f9863a0c45f4e87cb99593015090fdc9f44398","Merge branch 'bpftool-match-by-name' Paul Chaignon says: ==================== When working with frequently modified BPF programs, both the ID and the tag may change. bpftool currently doesn't provide a ""stable"" way to match such programs. This patchset allows bpftool to match programs and maps by name. When given a tag that matches several programs, bpftool currently only considers the first match. The first patch changes that behavior to either process all matching programs (for the show and dump commands) or error out. The second patch implements program lookup by name, with the same behavior as for tags in case of ambiguity. The last patch implements map lookup by name. Changelogs: Changes in v2: - Fix buffer overflow after realloc. - Add example output to commit message. - Properly close JSON arrays on errors. - Fix style errors (line breaks, for loops, exit labels, type for tagname). - Move do_show code for argc == 2 to do_show_subset functions. - Rebase. ==================== Signed-off-by: Alexei Starovoitov ","","This commit merges a branch to enable bpftool to match BPF programs and maps by name.","bpftool,programs,merge","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"99f9863a0c45f4e87cb99593015090fdc9f44398","99f9863a0c45f4e87cb99593015090fdc9f44398","Paul Chaignon","paul.chaignon@orange.com","1576264237","Alexei Starovoitov","ast@kernel.org","1576429398","2f81f80c00f4927221ed3ffe7ca1da7162079902","a7d22ca2a483d6c69c0791954447464297315ffa","bpftool: Match maps by name This patch implements lookup by name for maps and changes the behavior of lookups by tag to be consistent with prog subcommands. Similarly to program subcommands, the show and dump commands will return all maps with the given name (or tag), whereas other commands will error out if several maps have the same name (resp. tag). When a map has BTF info, it is dumped in JSON with available BTF info. This patch requires that all matched maps have BTF info before switching the output format to JSON. Signed-off-by: Paul Chaignon Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/8de1c9f273860b3ea1680502928f4da2336b853e.1576263640.git.paul.chaignon@gmail.com","tools/bpf/bpftool/Documentation/bpftool-map.rst | 10 +-; tools/bpf/bpftool/bash-completion/bpftool | 131 +++++++-; tools/bpf/bpftool/main.h | 2 +-; tools/bpf/bpftool/map.c | 384 +++++++++++++++++++-----; 4 files changed, 439 insertions(+), 88 deletions(-)","The commit implements name-based lookup for eBPF maps in bpftool and updates the behavior of tag-based lookups for consistency.","bpftool, maps, lookup","A new feature. It adds a new capability or feature that was not previously present.","Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"a7d22ca2a483d6c69c0791954447464297315ffa","a7d22ca2a483d6c69c0791954447464297315ffa","Paul Chaignon","paul.chaignon@orange.com","1576264217","Alexei Starovoitov","ast@kernel.org","1576429398","6d8abf29900bda20bfda5946945ec18156573ea1","ec2025095cf6acda3233a4301809596938b47da5","bpftool: Match programs by name When working with frequently modified BPF programs, both the ID and the tag may change. bpftool currently doesn't provide a ""stable"" way to match such programs. This patch implements lookup by name for programs. The show and dump commands will return all programs with the given name, whereas other commands will error out if several programs have the same name. Signed-off-by: Paul Chaignon Signed-off-by: Alexei Starovoitov Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/b5fc1a5dcfaeb5f16fc80295cdaa606dd2d91534.1576263640.git.paul.chaignon@gmail.com","tools/bpf/bpftool/Documentation/bpftool-map.rst | 2 +-; tools/bpf/bpftool/Documentation/bpftool-prog.rst | 12 ++++++------; tools/bpf/bpftool/bash-completion/bpftool | 22 ++++++++++++++++------; tools/bpf/bpftool/main.h | 2 +-; tools/bpf/bpftool/prog.c | 22 ++++++++++++++++++----; 5 files changed, 42 insertions(+), 18 deletions(-)","This commit enables bpftool to match eBPF programs by name for better stability when IDs and tags change frequently.","bpftool, match, programs","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"ec2025095cf6acda3233a4301809596938b47da5","ec2025095cf6acda3233a4301809596938b47da5","Paul Chaignon","paul.chaignon@orange.com","1576264204","Alexei Starovoitov","ast@kernel.org","1576429398","7354b6b1655f0873b3eb9ee80d47cab4127adce0","a06bf42f5a95ff462401d59d0c08cf4620213647","bpftool: Match several programs with same tag When several BPF programs have the same tag, bpftool matches only the first (in ID order). This patch changes that behavior such that dump and show commands return all matched programs. Commands that require a single program (e.g., pin and attach) will error out if given a tag that matches several. bpftool prog dump will also error out if file or visual are given and several programs have the given tag. In the case of the dump command, a program header is added before each dump only if the tag matches several programs; this patch doesn't change the output if a single program matches. The output when several programs match thus looks as follows. $ ./bpftool prog dump xlated tag 6deef7357e7b4530 3: cgroup_skb tag 6deef7357e7b4530 gpl 0: (bf) r6 = r1 [...] 7: (95) exit 4: cgroup_skb tag 6deef7357e7b4530 gpl 0: (bf) r6 = r1 [...] 7: (95) exit Signed-off-by: Paul Chaignon Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/fb1fe943202659a69cd21dd5b907c205af1e1e22.1576263640.git.paul.chaignon@gmail.com","tools/bpf/bpftool/Documentation/bpftool-prog.rst | 16 +-; tools/bpf/bpftool/prog.c | 372 ++++++++++++++++-------; 2 files changed, 268 insertions(+), 120 deletions(-)","This commit modifies bpftool to correctly handle multiple BPF programs sharing the same tag during dumps and shows.","bpftool, multiple, tag","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"a06bf42f5a95ff462401d59d0c08cf4620213647","a06bf42f5a95ff462401d59d0c08cf4620213647","Stanislav Fomichev","sdf@google.com","1576276228","Alexei Starovoitov","ast@kernel.org","1576279613","d36902bf1ad4a97c511b6b5ae6a383341824291e","850a88cc4096fe1df407452ba2e4d28cf5b3eee9","selftests/bpf: Test wire_len/gso_segs in BPF_PROG_TEST_RUN Make sure we can pass arbitrary data in wire_len/gso_segs. Signed-off-by: Stanislav Fomichev Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191213223028.161282-2-sdf@google.com","tools/testing/selftests/bpf/prog_tests/skb_ctx.c | 2 ++; tools/testing/selftests/bpf/progs/test_skb_ctx.c | 5 +++++; 2 files changed, 7 insertions(+)","The commit adds test cases to validate passing arbitrary data in wire_len and gso_segs for BPF_PROG_TEST_RUN.","selftests,bpf,wire_len","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"850a88cc4096fe1df407452ba2e4d28cf5b3eee9","850a88cc4096fe1df407452ba2e4d28cf5b3eee9","Stanislav Fomichev","sdf@google.com","1576276227","Alexei Starovoitov","ast@kernel.org","1576279613","45fde0333440ad15a1f6e682009cda3fe8892ebe","02620d9e629d217330a1e2a55f9c1e15a1af1519","bpf: Expose __sk_buff wire_len/gso_segs to BPF_PROG_TEST_RUN wire_len should not be less than real len and is capped by GSO_MAX_SIZE. gso_segs is capped by GSO_MAX_SEGS. v2: * set wire_len to skb->len when passed wire_len is 0 (Alexei Starovoitov) Signed-off-by: Stanislav Fomichev Signed-off-by: Alexei Starovoitov Cc: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191213223028.161282-1-sdf@google.com","net/bpf/test_run.c | 19 ++++++++++++++++++-; 1 file changed, 18 insertions(+), 1 deletion(-)","Expose wire_len and gso_segs fields to BPF_PROG_TEST_RUN for improved testing coverage.","wire_len,gso_segs,BPF_PROG_TEST_RUN","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"5133498f4ad1123a5ffd4c08df6431dab882cc32","5133498f4ad1123a5ffd4c08df6431dab882cc32","Lorenz Bauer","lmb@cloudflare.com","1576260497","Alexei Starovoitov","ast@kernel.org","1576279308","b0e929d19f4151527a372183668f42662bd72390","0af67e49b018e7280a4227bfe7b6005bc9d3e442","bpf: Clear skb->tstamp in bpf_redirect when necessary Redirecting a packet from ingress to egress by using bpf_redirect breaks if the egress interface has an fq qdisc installed. This is the same problem as fixed in 'commit 8203e2d844d3 (""net: clear skb->tstamp in forwarding paths"") Clear skb->tstamp when redirecting into the egress path. Fixes: 80b14dee2bea (""net: Add a new socket option for a future transmit time."") Fixes: fb420d5d91c1 (""tcp/fq: move back to CLOCK_MONOTONIC"") Signed-off-by: Lorenz Bauer Signed-off-by: Alexei Starovoitov Reviewed-by: Eric Dumazet Link: https://lore.kernel.org/bpf/20191213180817.2510-1-lmb@cloudflare.com","net/core/filter.c | 1 +; 1 file changed, 1 insertion(+)","This commit clears skb->tstamp during bpf_redirect to resolve queuing issues with fq qdisc on egress interfaces.","bpf_redirect, skb_tstamp, egress","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['tc related type programs. It affects programs managing traffic control (tc) for queuing or prioritizing network traffic.', ""I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear."", ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"02620d9e629d217330a1e2a55f9c1e15a1af1519","02620d9e629d217330a1e2a55f9c1e15a1af1519","Alexei Starovoitov","ast@kernel.org","1576271373","Alexei Starovoitov","ast@kernel.org","1576271740","607fdc7c30ce8dd968619afb8b90e2a980ae14ab","91cbdf740a476cf2c744169bf407de2e3ac1f3cf 116eb788f57c9c35c40b29cfaa2607020de99a84","Merge branch 'bpf-dispatcher' Björn Töpel says: ==================== Overview ======== This is the 6th iteration of the series that introduces the BPF dispatcher, which is a mechanism to avoid indirect calls. The BPF dispatcher is a multi-way branch code generator, targeted for BPF programs. E.g. when an XDP program is executed via the bpf_prog_run_xdp(), it is invoked via an indirect call. With retpolines enabled, the indirect call has a substantial performance impact. The dispatcher is a mechanism that transform indirect calls to direct calls, and therefore avoids the retpoline. The dispatcher is generated using the BPF JIT, and relies on text poking provided by bpf_arch_text_poke(). The dispatcher hijacks a trampoline function it via the __fentry__ nop of the trampoline. One dispatcher instance currently supports up to 48 dispatch points. This can be extended in the future. In this series, only one dispatcher instance is supported, and the only user is XDP. The dispatcher is updated when an XDP program is attached/detached to/from a netdev. An alternative to this could have been to update the dispatcher at program load point, but as there are usually more XDP programs loaded than attached, so the latter was picked. The XDP dispatcher is always enabled, if available, because it helps even when retpolines are disabled. Please refer to the ""Performance"" section below. The first patch refactors the image allocation from the BPF trampoline code. Patch two introduces the dispatcher, and patch three adds a dispatcher for XDP, and wires up the XDP control-/ fast-path. Patch four adds the dispatcher to BPF_TEST_RUN. Patch five adds a simple selftest, and the last adds alignment to jump targets. I have rebased the series on commit 679152d3a32e (""libbpf: Fix printf compilation warnings on ppc64le arch""). Generated code, x86-64 ====================== The dispatcher currently has a maximum of 48 entries, where one entry is a unique BPF program. Multiple users of a dispatcher instance using the same BPF program will share that entry. The program/slot lookup is performed by a binary search, O(log n). Let's have a look at the generated code. The trampoline function has the following signature: unsigned int tramp(const void *ctx, const struct bpf_insn *insnsi, unsigned int (*bpf_func)(const void *, const struct bpf_insn *)) On Intel x86-64 this means that rdx will contain the bpf_func. To, make it easier to read, I've let the BPF programs have the following range: 0xffffffffffffffff (-1) to 0xfffffffffffffff0 (-16). 0xffffffff81c00f10 is the retpoline thunk, in this case __x86_indirect_thunk_rdx. If retpolines are disabled the thunk will be a regular indirect call. The minimal dispatcher will then look like this: ffffffffc0002000: cmp rdx,0xffffffffffffffff ffffffffc0002007: je 0xffffffffffffffff ; -1 ffffffffc000200d: jmp 0xffffffff81c00f10 A 16 entry dispatcher looks like this: ffffffffc0020000: cmp rdx,0xfffffffffffffff7 ; -9 ffffffffc0020007: jg 0xffffffffc0020130 ffffffffc002000d: cmp rdx,0xfffffffffffffff3 ; -13 ffffffffc0020014: jg 0xffffffffc00200a0 ffffffffc002001a: cmp rdx,0xfffffffffffffff1 ; -15 ffffffffc0020021: jg 0xffffffffc0020060 ffffffffc0020023: cmp rdx,0xfffffffffffffff0 ; -16 ffffffffc002002a: jg 0xffffffffc0020040 ffffffffc002002c: cmp rdx,0xfffffffffffffff0 ; -16 ffffffffc0020033: je 0xfffffffffffffff0 ; -16 ffffffffc0020039: jmp 0xffffffff81c00f10 ffffffffc002003e: xchg ax,ax ffffffffc0020040: cmp rdx,0xfffffffffffffff1 ; -15 ffffffffc0020047: je 0xfffffffffffffff1 ; -15 ffffffffc002004d: jmp 0xffffffff81c00f10 ffffffffc0020052: nop DWORD PTR [rax+rax*1+0x0] ffffffffc002005a: nop WORD PTR [rax+rax*1+0x0] ffffffffc0020060: cmp rdx,0xfffffffffffffff2 ; -14 ffffffffc0020067: jg 0xffffffffc0020080 ffffffffc0020069: cmp rdx,0xfffffffffffffff2 ; -14 ffffffffc0020070: je 0xfffffffffffffff2 ; -14 ffffffffc0020076: jmp 0xffffffff81c00f10 ffffffffc002007b: nop DWORD PTR [rax+rax*1+0x0] ffffffffc0020080: cmp rdx,0xfffffffffffffff3 ; -13 ffffffffc0020087: je 0xfffffffffffffff3 ; -13 ffffffffc002008d: jmp 0xffffffff81c00f10 ffffffffc0020092: nop DWORD PTR [rax+rax*1+0x0] ffffffffc002009a: nop WORD PTR [rax+rax*1+0x0] ffffffffc00200a0: cmp rdx,0xfffffffffffffff5 ; -11 ffffffffc00200a7: jg 0xffffffffc00200f0 ffffffffc00200a9: cmp rdx,0xfffffffffffffff4 ; -12 ffffffffc00200b0: jg 0xffffffffc00200d0 ffffffffc00200b2: cmp rdx,0xfffffffffffffff4 ; -12 ffffffffc00200b9: je 0xfffffffffffffff4 ; -12 ffffffffc00200bf: jmp 0xffffffff81c00f10 ffffffffc00200c4: nop DWORD PTR [rax+rax*1+0x0] ffffffffc00200cc: nop DWORD PTR [rax+0x0] ffffffffc00200d0: cmp rdx,0xfffffffffffffff5 ; -11 ffffffffc00200d7: je 0xfffffffffffffff5 ; -11 ffffffffc00200dd: jmp 0xffffffff81c00f10 ffffffffc00200e2: nop DWORD PTR [rax+rax*1+0x0] ffffffffc00200ea: nop WORD PTR [rax+rax*1+0x0] ffffffffc00200f0: cmp rdx,0xfffffffffffffff6 ; -10 ffffffffc00200f7: jg 0xffffffffc0020110 ffffffffc00200f9: cmp rdx,0xfffffffffffffff6 ; -10 ffffffffc0020100: je 0xfffffffffffffff6 ; -10 ffffffffc0020106: jmp 0xffffffff81c00f10 ffffffffc002010b: nop DWORD PTR [rax+rax*1+0x0] ffffffffc0020110: cmp rdx,0xfffffffffffffff7 ; -9 ffffffffc0020117: je 0xfffffffffffffff7 ; -9 ffffffffc002011d: jmp 0xffffffff81c00f10 ffffffffc0020122: nop DWORD PTR [rax+rax*1+0x0] ffffffffc002012a: nop WORD PTR [rax+rax*1+0x0] ffffffffc0020130: cmp rdx,0xfffffffffffffffb ; -5 ffffffffc0020137: jg 0xffffffffc00201d0 ffffffffc002013d: cmp rdx,0xfffffffffffffff9 ; -7 ffffffffc0020144: jg 0xffffffffc0020190 ffffffffc0020146: cmp rdx,0xfffffffffffffff8 ; -8 ffffffffc002014d: jg 0xffffffffc0020170 ffffffffc002014f: cmp rdx,0xfffffffffffffff8 ; -8 ffffffffc0020156: je 0xfffffffffffffff8 ; -8 ffffffffc002015c: jmp 0xffffffff81c00f10 ffffffffc0020161: nop DWORD PTR [rax+rax*1+0x0] ffffffffc0020169: nop DWORD PTR [rax+0x0] ffffffffc0020170: cmp rdx,0xfffffffffffffff9 ; -7 ffffffffc0020177: je 0xfffffffffffffff9 ; -7 ffffffffc002017d: jmp 0xffffffff81c00f10 ffffffffc0020182: nop DWORD PTR [rax+rax*1+0x0] ffffffffc002018a: nop WORD PTR [rax+rax*1+0x0] ffffffffc0020190: cmp rdx,0xfffffffffffffffa ; -6 ffffffffc0020197: jg 0xffffffffc00201b0 ffffffffc0020199: cmp rdx,0xfffffffffffffffa ; -6 ffffffffc00201a0: je 0xfffffffffffffffa ; -6 ffffffffc00201a6: jmp 0xffffffff81c00f10 ffffffffc00201ab: nop DWORD PTR [rax+rax*1+0x0] ffffffffc00201b0: cmp rdx,0xfffffffffffffffb ; -5 ffffffffc00201b7: je 0xfffffffffffffffb ; -5 ffffffffc00201bd: jmp 0xffffffff81c00f10 ffffffffc00201c2: nop DWORD PTR [rax+rax*1+0x0] ffffffffc00201ca: nop WORD PTR [rax+rax*1+0x0] ffffffffc00201d0: cmp rdx,0xfffffffffffffffd ; -3 ffffffffc00201d7: jg 0xffffffffc0020220 ffffffffc00201d9: cmp rdx,0xfffffffffffffffc ; -4 ffffffffc00201e0: jg 0xffffffffc0020200 ffffffffc00201e2: cmp rdx,0xfffffffffffffffc ; -4 ffffffffc00201e9: je 0xfffffffffffffffc ; -4 ffffffffc00201ef: jmp 0xffffffff81c00f10 ffffffffc00201f4: nop DWORD PTR [rax+rax*1+0x0] ffffffffc00201fc: nop DWORD PTR [rax+0x0] ffffffffc0020200: cmp rdx,0xfffffffffffffffd ; -3 ffffffffc0020207: je 0xfffffffffffffffd ; -3 ffffffffc002020d: jmp 0xffffffff81c00f10 ffffffffc0020212: nop DWORD PTR [rax+rax*1+0x0] ffffffffc002021a: nop WORD PTR [rax+rax*1+0x0] ffffffffc0020220: cmp rdx,0xfffffffffffffffe ; -2 ffffffffc0020227: jg 0xffffffffc0020240 ffffffffc0020229: cmp rdx,0xfffffffffffffffe ; -2 ffffffffc0020230: je 0xfffffffffffffffe ; -2 ffffffffc0020236: jmp 0xffffffff81c00f10 ffffffffc002023b: nop DWORD PTR [rax+rax*1+0x0] ffffffffc0020240: cmp rdx,0xffffffffffffffff ; -1 ffffffffc0020247: je 0xffffffffffffffff ; -1 ffffffffc002024d: jmp 0xffffffff81c00f10 The nops are there to align jump targets to 16 B. Performance =========== The tests were performed using the xdp_rxq_info sample program with the following command-line: 1. XDP_DRV: # xdp_rxq_info --dev eth0 --action XDP_DROP 2. XDP_SKB: # xdp_rxq_info --dev eth0 -S --action XDP_DROP 3. xdp-perf, from selftests/bpf: # test_progs -v -t xdp_perf Run with mitigations=auto ------------------------- Baseline: 1. 21.7 Mpps (21736190) 2. 3.8 Mpps (3837582) 3. 15 ns Dispatcher: 1. 30.2 Mpps (30176320) 2. 4.0 Mpps (4015579) 3. 5 ns Dispatcher (full; walk all entries, and fallback): 1. 22.0 Mpps (21986704) 2. 3.8 Mpps (3831298) 3. 17 ns Run with mitigations=off ------------------------ Baseline: 1. 29.9 Mpps (29875135) 2. 4.1 Mpps (4100179) 3. 4 ns Dispatcher: 1. 30.4 Mpps (30439241) 2. 4.1 Mpps (4109350) 1. 4 ns Dispatcher (full; walk all entries, and fallback): 1. 28.9 Mpps (28903269) 2. 4.1 Mpps (4080078) 3. 5 ns xdp-perf runs, aliged vs non-aligned jump targets ------------------------------------------------- In this test dispatchers of different sizes, with and without jump target alignment, were exercised. As outlined above the function lookup is performed via binary search. This means that depending on the pointer value of the function, it can reside in the upper or lower part of the search table. The performed tests were: 1. aligned, mititations=auto, function entry < other entries 2. aligned, mititations=auto, function entry > other entries 3. non-aligned, mititations=auto, function entry < other entries 4. non-aligned, mititations=auto, function entry > other entries 5. aligned, mititations=off, function entry < other entries 6. aligned, mititations=off, function entry > other entries 7. non-aligned, mititations=off, function entry < other entries 8. non-aligned, mititations=off, function entry > other entries The micro benchmarks showed that alignment of jump target has some positive impact. A reply to this cover letter will contain complete data for all runs. Multiple xdp-perf baseline with mitigations=auto ------------------------------------------------ Performance counter stats for './test_progs -v -t xdp_perf' (1024 runs): 16.69 msec task-clock # 0.984 CPUs utilized ( +- 0.08% ) 2 context-switches # 0.123 K/sec ( +- 1.11% ) 0 cpu-migrations # 0.000 K/sec ( +- 70.68% ) 97 page-faults # 0.006 M/sec ( +- 0.05% ) 49,254,635 cycles # 2.951 GHz ( +- 0.09% ) (12.28%) 42,138,558 instructions # 0.86 insn per cycle ( +- 0.02% ) (36.15%) 7,315,291 branches # 438.300 M/sec ( +- 0.01% ) (59.43%) 1,011,201 branch-misses # 13.82% of all branches ( +- 0.01% ) (83.31%) 15,440,788 L1-dcache-loads # 925.143 M/sec ( +- 0.00% ) (99.40%) 39,067 L1-dcache-load-misses # 0.25% of all L1-dcache hits ( +- 0.04% ) 6,531 LLC-loads # 0.391 M/sec ( +- 0.05% ) 442 LLC-load-misses # 6.76% of all LL-cache hits ( +- 0.77% ) L1-icache-loads 57,964 L1-icache-load-misses ( +- 0.06% ) 15,442,496 dTLB-loads # 925.246 M/sec ( +- 0.00% ) 514 dTLB-load-misses # 0.00% of all dTLB cache hits ( +- 0.73% ) (40.57%) 130 iTLB-loads # 0.008 M/sec ( +- 2.75% ) (16.69%) iTLB-load-misses ( +- 8.71% ) (0.60%) L1-dcache-prefetches L1-dcache-prefetch-misses 0.0169558 +- 0.0000127 seconds time elapsed ( +- 0.07% ) Multiple xdp-perf dispatcher with mitigations=auto -------------------------------------------------- Note that this includes generating the dispatcher. Performance counter stats for './test_progs -v -t xdp_perf' (1024 runs): 4.80 msec task-clock # 0.953 CPUs utilized ( +- 0.06% ) 1 context-switches # 0.258 K/sec ( +- 1.57% ) 0 cpu-migrations # 0.000 K/sec 97 page-faults # 0.020 M/sec ( +- 0.05% ) 14,185,861 cycles # 2.955 GHz ( +- 0.17% ) (50.49%) 45,691,935 instructions # 3.22 insn per cycle ( +- 0.01% ) (99.19%) 8,346,008 branches # 1738.709 M/sec ( +- 0.00% ) 13,046 branch-misses # 0.16% of all branches ( +- 0.10% ) 15,443,735 L1-dcache-loads # 3217.365 M/sec ( +- 0.00% ) 39,585 L1-dcache-load-misses # 0.26% of all L1-dcache hits ( +- 0.05% ) 7,138 LLC-loads # 1.487 M/sec ( +- 0.06% ) 671 LLC-load-misses # 9.40% of all LL-cache hits ( +- 0.73% ) L1-icache-loads 56,213 L1-icache-load-misses ( +- 0.08% ) 15,443,735 dTLB-loads # 3217.365 M/sec ( +- 0.00% ) dTLB-load-misses (0.00%) iTLB-loads (0.00%) iTLB-load-misses (0.00%) L1-dcache-prefetches L1-dcache-prefetch-misses 0.00503705 +- 0.00000546 seconds time elapsed ( +- 0.11% ) Revisions ========= v4->v5: [1] * Fixed s/xdp_ctx/ctx/ type-o (Toke) * Marked dispatcher trampoline with noinline attribute (Alexei) v3->v4: [2] * Moved away from doing dispatcher lookup based on the trampoline function, to a model where the dispatcher instance is explicitly passed to the bpf_dispatcher_change_prog() (Alexei) v2->v3: [3] * Removed xdp_call, and instead make the dispatcher available to all XDP users via bpf_prog_run_xdp() and dev_xdp_install(). (Toke) * Always enable the dispatcher, if available (Alexei) * Reuse BPF trampoline image allocator (Alexei) * Make sure the dispatcher is exercised in selftests (Alexei) * Only allow one dispatcher, and wire it to XDP v1->v2: [4] * Fixed i386 build warning (kbuild robot) * Made bpf_dispatcher_lookup() static (kbuild robot) * Make sure xdp_call.h is only enabled for builtins * Add xdp_call() to ixgbe, mlx4, and mlx5 RFC->v1: [5] * Improved error handling (Edward and Andrii) * Explicit cleanup (Andrii) * Use 32B with sext cmp (Alexei) * Align jump targets to 16B (Alexei) * 4 to 16 entries (Toke) * Added stats to xdp_call_run() [1] https://lore.kernel.org/bpf/20191211123017.13212-1-bjorn.topel@gmail.com/ [2] https://lore.kernel.org/bpf/20191209135522.16576-1-bjorn.topel@gmail.com/ [3] https://lore.kernel.org/bpf/20191123071226.6501-1-bjorn.topel@gmail.com/ [4] https://lore.kernel.org/bpf/20191119160757.27714-1-bjorn.topel@gmail.com/ [5] https://lore.kernel.org/bpf/20191113204737.31623-1-bjorn.topel@gmail.com/ ==================== Signed-off-by: Alexei Starovoitov ","","The commit merges the 'bpf-dispatcher' branch, optimizing XDP program execution by converting indirect calls to direct calls using a BPF dispatcher mechanism.","dispatcher,XDP,merge","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime."", ""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"116eb788f57c9c35c40b29cfaa2607020de99a84","116eb788f57c9c35c40b29cfaa2607020de99a84","Björn Töpel","bjorn.topel@intel.com","1576259472","Alexei Starovoitov","ast@kernel.org","1576271372","607fdc7c30ce8dd968619afb8b90e2a980ae14ab","e754f5a6e36b63d6732f52adcbe4c447fd66896f","bpf, x86: Align dispatcher branch targets to 16B >From Intel 64 and IA-32 Architectures Optimization Reference Manual, 3.4.1.4 Code Alignment, Assembly/Compiler Coding Rule 11: All branch targets should be 16-byte aligned. This commits aligns branch targets according to the Intel manual. The nops used to align branch targets make the dispatcher larger, and therefore the number of supported dispatch points/programs are descreased from 64 to 48. Signed-off-by: Björn Töpel Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191213175112.30208-7-bjorn.topel@gmail.com","arch/x86/net/bpf_jit_comp.c | 30 +++++++++++++++++++++++++++++-; include/linux/bpf.h | 2 +-; 2 files changed, 30 insertions(+), 2 deletions(-)","This commit aligns x86 dispatcher branch targets to 16 bytes to optimize performance based on Intel's architecture manual, reducing dispatch points.","alignment,dispatcher,Intel","A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"e754f5a6e36b63d6732f52adcbe4c447fd66896f","e754f5a6e36b63d6732f52adcbe4c447fd66896f","Björn Töpel","bjorn.topel@intel.com","1576259471","Alexei Starovoitov","ast@kernel.org","1576271372","07880954b0a153c950a1d0f12e12fdf426675754","f23c4b3924d2e9382820ee677b68d42d5dd7b08b","selftests: bpf: Add xdp_perf test The xdp_perf is a dummy XDP test, only used to measure the the cost of jumping into a naive XDP program one million times. To build and run the program: $ cd tools/testing/selftests/bpf $ make $ ./test_progs -v -t xdp_perf Signed-off-by: Björn Töpel Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191213175112.30208-6-bjorn.topel@gmail.com","tools/testing/selftests/bpf/prog_tests/xdp_perf.c | 25 +++++++++++++++++++++++; 1 file changed, 25 insertions(+)","The commit introduces a test to measure the cost of repeatedly executing a basic XDP program.","xdp_perf,selftests,XDP","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.']" +"f23c4b3924d2e9382820ee677b68d42d5dd7b08b","f23c4b3924d2e9382820ee677b68d42d5dd7b08b","Björn Töpel","bjorn.topel@intel.com","1576259470","Alexei Starovoitov","ast@kernel.org","1576271372","e0d46c0448b1a61d1c468bbabdfdbfd0e4bc7e35","7e6897f95935973c3253fd756135b5ea58043dc8","bpf: Start using the BPF dispatcher in BPF_TEST_RUN In order to properly exercise the BPF dispatcher, this commit adds BPF dispatcher usage to BPF_TEST_RUN when executing XDP programs. Signed-off-by: Björn Töpel Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191213175112.30208-5-bjorn.topel@gmail.com","net/bpf/test_run.c | 15 ++++++++++-----; 1 file changed, 10 insertions(+), 5 deletions(-)","This commit incorporates BPF dispatcher usage in BPF_TEST_RUN for executing XDP programs.","BPF dispatcher,XDP programs,BPF_TEST_RUN","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"7e6897f95935973c3253fd756135b5ea58043dc8","7e6897f95935973c3253fd756135b5ea58043dc8","Björn Töpel","bjorn.topel@intel.com","1576259469","Alexei Starovoitov","ast@kernel.org","1576271372","b51f503250727273df277698fac760b6cdc26393","75ccbef6369e94ecac696a152a998a978d41376b","bpf, xdp: Start using the BPF dispatcher for XDP This commit adds a BPF dispatcher for XDP. The dispatcher is updated from the XDP control-path, dev_xdp_install(), and used when an XDP program is run via bpf_prog_run_xdp(). Signed-off-by: Björn Töpel Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191213175112.30208-4-bjorn.topel@gmail.com","include/linux/bpf.h | 15 +++++++++++++++; include/linux/filter.h | 40 ++++++++++++++++++++++++----------------; kernel/bpf/syscall.c | 26 ++++++++++++++++++--------; net/core/dev.c | 19 ++++++++++++++++++-; net/core/filter.c | 8 ++++++++; 5 files changed, 83 insertions(+), 25 deletions(-)","This commit implements a BPF dispatcher for XDP to optimize program execution via the control path in the Linux networking stack.","BPF dispatcher XDP","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.']" +"75ccbef6369e94ecac696a152a998a978d41376b","75ccbef6369e94ecac696a152a998a978d41376b","Björn Töpel","bjorn.topel@intel.com","1576259468","Alexei Starovoitov","ast@kernel.org","1576271372","c1d92822ed470de368dfe5a102af694ffb1ee7e3","98e8627efcada18ac043a77b9101b4b4c768090b","bpf: Introduce BPF dispatcher The BPF dispatcher is a multi-way branch code generator, mainly targeted for XDP programs. When an XDP program is executed via the bpf_prog_run_xdp(), it is invoked via an indirect call. The indirect call has a substantial performance impact, when retpolines are enabled. The dispatcher transform indirect calls to direct calls, and therefore avoids the retpoline. The dispatcher is generated using the BPF JIT, and relies on text poking provided by bpf_arch_text_poke(). The dispatcher hijacks a trampoline function it via the __fentry__ nop of the trampoline. One dispatcher instance currently supports up to 64 dispatch points. A user creates a dispatcher with its corresponding trampoline with the DEFINE_BPF_DISPATCHER macro. Signed-off-by: Björn Töpel Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191213175112.30208-3-bjorn.topel@gmail.com","arch/x86/net/bpf_jit_comp.c | 122 ++++++++++++++++++++++++++++++++++; include/linux/bpf.h | 56 ++++++++++++++++; kernel/bpf/Makefile | 1 +; kernel/bpf/dispatcher.c | 158 ++++++++++++++++++++++++++++++++++++++++++++; 4 files changed, 337 insertions(+)","This commit introduces a BPF dispatcher to enhance performance by converting indirect to direct calls for XDP programs.","BPF,dispatcher,XDP","A new feature. It adds a new capability or feature that was not previously present.","Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"98e8627efcada18ac043a77b9101b4b4c768090b","98e8627efcada18ac043a77b9101b4b4c768090b","Björn Töpel","bjorn.topel@intel.com","1576259467","Alexei Starovoitov","ast@kernel.org","1576271372","78bddd4e10be8b09a0a0703129ff112e8ee012f4","91cbdf740a476cf2c744169bf407de2e3ac1f3cf","bpf: Move trampoline JIT image allocation to a function Refactor the image allocation in the BPF trampoline code into a separate function, so it can be shared with the BPF dispatcher in upcoming commits. Signed-off-by: Björn Töpel Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191213175112.30208-2-bjorn.topel@gmail.com","include/linux/bpf.h | 1 +; kernel/bpf/trampoline.c | 24 +++++++++++++++++-------; 2 files changed, 18 insertions(+), 7 deletions(-)","Refactor BPF trampoline image allocation into a function for use in the dispatcher.","trampoline,image,allocation","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"91cbdf740a476cf2c744169bf407de2e3ac1f3cf","91cbdf740a476cf2c744169bf407de2e3ac1f3cf","Andrii Nakryiko","andriin@fb.com","1576114580","Alexei Starovoitov","ast@kernel.org","1576270825","ac2f6150849247d5be1c2af64d323b2a8b660b53","783b8f01f5942a786998f5577bd9ff3992f22a1a","selftests/bpf: Fix perf_buffer test on systems w/ offline CPUs Fix up perf_buffer.c selftest to take into account offline/missing CPUs. Fixes: ee5cf82ce04a (""selftests/bpf: test perf buffer API"") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191212013621.1691858-1-andriin@fb.com",".../testing/selftests/bpf/prog_tests/perf_buffer.c | 29 ++++++++++++++++++----; 1 file changed, 24 insertions(+), 5 deletions(-)","The commit fixes the perf_buffer selftest to handle offline CPUs in the BPF subsystem.","selftests,perf_buffer,CPUs","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.']" +"783b8f01f5942a786998f5577bd9ff3992f22a1a","783b8f01f5942a786998f5577bd9ff3992f22a1a","Andrii Nakryiko","andriin@fb.com","1576114569","Alexei Starovoitov","ast@kernel.org","1576270809","0015cd8dd301c2b5fb8d1224713a4c3c97b42017","65bc4c4063ae36223375a920b7d116e54d7def34","libbpf: Don't attach perf_buffer to offline/missing CPUs It's quite common on some systems to have more CPUs enlisted as ""possible"", than there are (and could ever be) present/online CPUs. In such cases, perf_buffer creationg will fail due to inability to create perf event on missing CPU with error like this: libbpf: failed to open perf buffer event on cpu #16: No such device This patch fixes the logic of perf_buffer__new() to ignore CPUs that are missing or currently offline. In rare cases where user explicitly listed specific CPUs to connect to, behavior is unchanged: libbpf will try to open perf event buffer on specified CPU(s) anyways. Fixes: fb84b8224655 (""libbpf: add perf buffer API"") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191212013609.1691168-1-andriin@fb.com","tools/lib/bpf/libbpf.c | 32 +++++++++++++++++++++++++-------; 1 file changed, 25 insertions(+), 7 deletions(-)","The commit fixes libbpf to avoid attaching perf_buffer to offline or missing CPUs.","libbpf, perf_buffer, CPUs","A bug fix. It primarily resolves a bug or issue in the code.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.']" +"65bc4c4063ae36223375a920b7d116e54d7def34","65bc4c4063ae36223375a920b7d116e54d7def34","Andrii Nakryiko","andriin@fb.com","1576114558","Alexei Starovoitov","ast@kernel.org","1576270795","172eca8e18c216e5bdab2dcc44ebab00649d977e","6803ee25f0ead1e836808acb14396bb9a9849113","selftests/bpf: Add CPU mask parsing tests Add a bunch of test validating CPU mask parsing logic and error handling. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191212013559.1690898-1-andriin@fb.com","tools/testing/selftests/bpf/prog_tests/cpu_mask.c | 78 +++++++++++++++++++++++; 1 file changed, 78 insertions(+)","This commit adds tests to validate CPU mask parsing logic and error handling in the eBPF selftests.","selftests, CPU mask, parsing","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"6803ee25f0ead1e836808acb14396bb9a9849113","6803ee25f0ead1e836808acb14396bb9a9849113","Andrii Nakryiko","andriin@fb.com","1576114548","Alexei Starovoitov","ast@kernel.org","1576270731","b2e7b3306d10c300d91b150867eeb0d57877ae08","7708bd430d88309333b0d0eb7783cddd0874dd14","libbpf: Extract and generalize CPU mask parsing logic This logic is re-used for parsing a set of online CPUs. Having it as an isolated piece of code working with input string makes it conveninent to test this logic as well. While refactoring, also improve the robustness of original implementation. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191212013548.1690564-1-andriin@fb.com","tools/lib/bpf/libbpf.c | 125 +++++++++++++++++++++++++++-------------; tools/lib/bpf/libbpf_internal.h | 2 +; 2 files changed, 86 insertions(+), 41 deletions(-)","This commit refactors CPU mask parsing logic in libbpf for enhanced reusability and robustness.","CPU mask,libbpf,robustness","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"7708bd430d88309333b0d0eb7783cddd0874dd14","7708bd430d88309333b0d0eb7783cddd0874dd14","Alexei Starovoitov","ast@kernel.org","1576269481","Alexei Starovoitov","ast@kernel.org","1576269484","dcffd59561310d2c01b382f5aa54234e2eae0e35","679152d3a32e305c213f83160c328c37566ae8bc 7ee0d4e97b889c0478af9c1a6e5af658b181423f","Merge branch 'reuseport_to_test_progs' Jakub Sitnicki says: ==================== This change has been suggested by Martin Lau [0] during a review of a related patch set that extends reuseport tests [1]. Patches 1 & 2 address a warning due to unrecognized section name from libbpf when running reuseport tests. We don't want to carry this warning into test_progs. Patches 3-8 massage the reuseport tests to ease the switch to test_progs framework. The intention here is to show the work. Happy to squash these, if needed. Patches 9-10 do the actual move and conversion to test_progs. Output from a test_progs run after changes pasted below. Thanks, Jakub [0] https://lore.kernel.org/bpf/20191123110751.6729-1-jakub@cloudflare.com/T/#m607d822caeb1eb5db101172821a78cc3896ff1c3 [1] https://lore.kernel.org/bpf/20191123110751.6729-1-jakub@cloudflare.com/T/#m55881bae9fb6e34837d07a0c0a7ffbc138f8d06f ==================== Acked-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov ","","This commit merges reuseport tests into the test_progs framework addressing warnings and enhancing test integration.","reuseport,test,framework","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"7ee0d4e97b889c0478af9c1a6e5af658b181423f","7ee0d4e97b889c0478af9c1a6e5af658b181423f","Jakub Sitnicki","jakub@cloudflare.com","1576146179","Alexei Starovoitov","ast@kernel.org","1576269480","dcffd59561310d2c01b382f5aa54234e2eae0e35","415bb4e125b68a3aaccb8381baaa4a06dd1dcb27","selftests/bpf: Switch reuseport tests for test_progs framework The tests were originally written in abort-on-error style. With the switch to test_progs we can no longer do that. So at the risk of not cleaning up some resource on failure, we now return to the caller on error. That said, failure inside one test should not affect others because we run setup/cleanup before/after every test. Signed-off-by: Jakub Sitnicki Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191212102259.418536-11-jakub@cloudflare.com",".../selftests/bpf/prog_tests/select_reuseport.c | 267 ++++++++++-----------; 1 file changed, 131 insertions(+), 136 deletions(-)","The commit updates selftests for reuseport to use the test_progs framework instead of abort-on-error style.","reuseport,test_progs,selftests","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime."", ""It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here.""]" +"415bb4e125b68a3aaccb8381baaa4a06dd1dcb27","415bb4e125b68a3aaccb8381baaa4a06dd1dcb27","Jakub Sitnicki","jakub@cloudflare.com","1576146178","Alexei Starovoitov","ast@kernel.org","1576269480","b598ce9c124f8646c470a74b842cd349796b1b88","250a91d48ae7616672a34b58388620a554a00180","selftests/bpf: Move reuseport tests under prog_tests/ Do a pure move the show the actual work needed to adapt the tests in subsequent patch at the cost of breaking test_progs build for the moment. Signed-off-by: Jakub Sitnicki Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191212102259.418536-10-jakub@cloudflare.com","tools/testing/selftests/bpf/Makefile | 2 +-; .../selftests/bpf/prog_tests/select_reuseport.c | 811 +++++++++++++++++++++; .../testing/selftests/bpf/test_select_reuseport.c | 811 ---------------------; 3 files changed, 812 insertions(+), 812 deletions(-)","Moved reuseport tests to the prog_tests directory to organize tests, temporarily breaking build.","selftests,bpf,reuseport","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime."", ""It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here.""]" +"250a91d48ae7616672a34b58388620a554a00180","250a91d48ae7616672a34b58388620a554a00180","Jakub Sitnicki","jakub@cloudflare.com","1576146177","Alexei Starovoitov","ast@kernel.org","1576269480","8f03f0e26a8878075f27519db939424cfe509316","9af6c84435d0252e532c7f8bb70f1ed64a22ae2a","selftests/bpf: Pull up printing the test name into test runner Again, prepare for switching reuseport tests to test_progs framework. test_progs framework will print the subtest name for us if we set it. Signed-off-by: Jakub Sitnicki Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191212102259.418536-9-jakub@cloudflare.com",".../testing/selftests/bpf/test_select_reuseport.c | 27 ++++++++++------------; 1 file changed, 12 insertions(+), 15 deletions(-)","The commit updates test code to use the test_progs framework for printing test names in BPF selftests.","selftests,printing,test_progs","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"9af6c84435d0252e532c7f8bb70f1ed64a22ae2a","9af6c84435d0252e532c7f8bb70f1ed64a22ae2a","Jakub Sitnicki","jakub@cloudflare.com","1576146176","Alexei Starovoitov","ast@kernel.org","1576269480","80d6da11a91d5b19255943674f31bda7c68fd619","ce7cb5f3921cdf0f65ab877764265c6c0be34c3c","selftests/bpf: Propagate errors during setup for reuseport tests Prepare for switching reuseport tests to test_progs framework, where we don't have the luxury to terminate the process on failure. Modify setup helpers to signal failure via the return value with the help of a macro similar to the one currently in use by the tests. Signed-off-by: Jakub Sitnicki Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191212102259.418536-8-jakub@cloudflare.com",".../testing/selftests/bpf/test_select_reuseport.c | 136 +++++++++++++--------; 1 file changed, 85 insertions(+), 51 deletions(-)","This commit modifies reuseport test setup to propagate errors through return values for integration with the test_progs framework.","selftests,reuseport,errors","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"ce7cb5f3921cdf0f65ab877764265c6c0be34c3c","ce7cb5f3921cdf0f65ab877764265c6c0be34c3c","Jakub Sitnicki","jakub@cloudflare.com","1576146175","Alexei Starovoitov","ast@kernel.org","1576269480","1d5b83e4ee38e4bd7bb5113f43712d5b0cbb1e60","9936338258308aa008387dc4f9fd3f5fec6c046a","selftests/bpf: Run reuseport tests in a loop Prepare for switching reuseport tests to test_progs framework. Loop over the tests and perform setup/cleanup for each test separately, remembering that with test_progs we can select tests to run. Signed-off-by: Jakub Sitnicki Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191212102259.418536-7-jakub@cloudflare.com",".../testing/selftests/bpf/test_select_reuseport.c | 55 +++++++++++++---------; 1 file changed, 34 insertions(+), 21 deletions(-)","The commit updates reuseport tests to run in loops for preparing integration into the test_progs framework.","reuseport,loop,tests","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"9936338258308aa008387dc4f9fd3f5fec6c046a","9936338258308aa008387dc4f9fd3f5fec6c046a","Jakub Sitnicki","jakub@cloudflare.com","1576146174","Alexei Starovoitov","ast@kernel.org","1576269480","8d236b3551d3ae96b5cdf8349060426e59004076","a9ce4cf4e47c55ab40641b92551bc9e1de4bfa61","selftests/bpf: Unroll the main loop in reuseport test Prepare for iterating over individual tests without introducing another nested loop in the main test function. Signed-off-by: Jakub Sitnicki Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191212102259.418536-6-jakub@cloudflare.com",".../testing/selftests/bpf/test_select_reuseport.c | 73 ++++++++++++----------; 1 file changed, 41 insertions(+), 32 deletions(-)","The commit refactors the reuseport test by unrolling the main loop to facilitate individual test iterations.","unroll,reuseport,iteration","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"a9ce4cf4e47c55ab40641b92551bc9e1de4bfa61","a9ce4cf4e47c55ab40641b92551bc9e1de4bfa61","Jakub Sitnicki","jakub@cloudflare.com","1576146173","Alexei Starovoitov","ast@kernel.org","1576269480","f8040169492f470614b2e963c386ca339601d763","11f80355d4d27c7c798fc9890b4056c5d98af992","selftests/bpf: Add helpers for getting socket family & type name Having string arrays to map socket family & type to a name prevents us from unrolling the test runner loop in the subsequent patch. Introduce helpers that do the same thing. Signed-off-by: Jakub Sitnicki Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191212102259.418536-5-jakub@cloudflare.com",".../testing/selftests/bpf/test_select_reuseport.c | 28 +++++++++++++++++++---; 1 file changed, 25 insertions(+), 3 deletions(-)","Introduce helpers for mapping socket family and type names in selftests to prevent loop unrolling issues.","helpers,socket,selftests","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"11f80355d4d27c7c798fc9890b4056c5d98af992","11f80355d4d27c7c798fc9890b4056c5d98af992","Jakub Sitnicki","jakub@cloudflare.com","1576146172","Alexei Starovoitov","ast@kernel.org","1576269480","e2d90c4700afdd8f5ac6c51a44574b6448b5d684","1fbcef929d7d71321745e61e8c20b0a02bd38cf1","selftests/bpf: Use sa_family_t everywhere in reuseport tests Update the only function that is not using sa_family_t in this source file. Signed-off-by: Jakub Sitnicki Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191212102259.418536-4-jakub@cloudflare.com","tools/testing/selftests/bpf/test_select_reuseport.c | 6 +++---; 1 file changed, 3 insertions(+), 3 deletions(-)","Updated reuseport tests to consistently use sa_family_t type across all functions.","selftests,bpf,reuseport","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"1fbcef929d7d71321745e61e8c20b0a02bd38cf1","1fbcef929d7d71321745e61e8c20b0a02bd38cf1","Jakub Sitnicki","jakub@cloudflare.com","1576146171","Alexei Starovoitov","ast@kernel.org","1576269480","dfbe663432c641e311a7226a12aef376ba5eb9ef","67d69ccdf389f3b7fabb00e2d81473a915b3b64d","selftests/bpf: Let libbpf determine program type from section name Now that libbpf can recognize SK_REUSEPORT programs, we no longer have to pass a prog_type hint before loading the object file. Signed-off-by: Jakub Sitnicki Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191212102259.418536-3-jakub@cloudflare.com",".../testing/selftests/bpf/progs/test_select_reuseport_kern.c | 2 +-; tools/testing/selftests/bpf/test_select_reuseport.c | 12 +++---------; 2 files changed, 4 insertions(+), 10 deletions(-)","This commit updates selftests to use libbpf's capability to auto-detect SK_REUSEPORT program types from section names.","libbpf,SK_REUSEPORT,selftests","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime."", ""I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear.""]" +"67d69ccdf389f3b7fabb00e2d81473a915b3b64d","67d69ccdf389f3b7fabb00e2d81473a915b3b64d","Jakub Sitnicki","jakub@cloudflare.com","1576146170","Alexei Starovoitov","ast@kernel.org","1576269480","65332edc16f817e021a858ae12b5015259a9c52c","679152d3a32e305c213f83160c328c37566ae8bc","libbpf: Recognize SK_REUSEPORT programs from section name Allow loading BPF object files that contain SK_REUSEPORT programs without having to manually set the program type before load if the the section name is set to ""sk_reuseport"". Makes user-space code needed to load SK_REUSEPORT BPF program more concise. Signed-off-by: Jakub Sitnicki Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191212102259.418536-2-jakub@cloudflare.com","tools/lib/bpf/libbpf.c | 1 +; 1 file changed, 1 insertion(+)","The commit enables automatic recognition of SK_REUSEPORT programs from section names in libbpf for easier loading.","SK_REUSEPORT,libbpf,section","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"679152d3a32e305c213f83160c328c37566ae8bc","679152d3a32e305c213f83160c328c37566ae8bc","Andrii Nakryiko","andriin@fb.com","1576171158","Alexei Starovoitov","ast@kernel.org","1576187244","351a0db3db9a691a61ad0678798a1df012b60ad7","81c22041d9f19df07b9cba95e3cd02e0f41bc1e1","libbpf: Fix printf compilation warnings on ppc64le arch On ppc64le __u64 and __s64 are defined as long int and unsigned long int, respectively. This causes compiler to emit warning when %lld/%llu are used to printf 64-bit numbers. Fix this by casting to size_t/ssize_t with %zu and %zd format specifiers, respectively. v1->v2: - use size_t/ssize_t instead of custom typedefs (Martin). Fixes: 1f8e2bcb2cd5 (""libbpf: Refactor relocation handling"") Fixes: abd29c931459 (""libbpf: allow specifying map definitions using BTF"") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191212171918.638010-1-andriin@fb.com","tools/lib/bpf/libbpf.c | 37 +++++++++++++++++++------------------; 1 file changed, 19 insertions(+), 18 deletions(-)","Fixes printf compilation warnings for 64-bit numbers in libbpf on ppc64le architecture by adjusting format specifiers.","libbpf,printf,ppc64le","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"148709bc278a2e49ff7b10cee2d8cdc33b894598","148709bc278a2e49ff7b10cee2d8cdc33b894598","David S. Miller","davem@davemloft.net","1576124025","David S. Miller","davem@davemloft.net","1576124025","c27a039d9886cae1572f81d80e35af60bf9cd740","24dee0c7478d1a1e00abdf5625b7f921467325dc fe3300897cbfd76c6cb825776e5ac0ca50a91ca4","Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf Alexei Starovoitov says: ==================== pull-request: bpf 2019-12-11 The following pull-request contains BPF updates for your *net* tree. We've added 8 non-merge commits during the last 1 day(s) which contain a total of 10 files changed, 126 insertions(+), 18 deletions(-). The main changes are: 1) Make BPF trampoline co-exist with ftrace-based tracers, from Alexei. 2) Fix build in minimal configurations, from Arnd. 3) Fix mips, riscv bpf_tail_call limit, from Paul. 4) Fix bpftool segfault, from Toke. 5) Fix samples/bpf, from Daniel. ==================== Signed-off-by: David S. Miller ","","This commit merges multiple BPF updates including fixes for trampolines, build configurations, and bpftool segfault.","merge,BPF,fixes","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"81c22041d9f19df07b9cba95e3cd02e0f41bc1e1","81c22041d9f19df07b9cba95e3cd02e0f41bc1e1","Daniel Borkmann","daniel@iogearbox.net","1575904083","Alexei Starovoitov","ast@kernel.org","1576109761","3ea69cf58495130fa4eefa49a072a2dbeeeb8318","bae141f54be83b06652c1d47e50e4e75ed4e9c7e","bpf, x86, arm64: Enable jit by default when not built as always-on After Spectre 2 fix via 290af86629b2 (""bpf: introduce BPF_JIT_ALWAYS_ON config"") most major distros use BPF_JIT_ALWAYS_ON configuration these days which compiles out the BPF interpreter entirely and always enables the JIT. Also given recent fix in e1608f3fa857 (""bpf: Avoid setting bpf insns pages read-only when prog is jited""), we additionally avoid fragmenting the direct map for the BPF insns pages sitting in the general data heap since they are not used during execution. Latter is only needed when run through the interpreter. Since both x86 and arm64 JITs have seen a lot of exposure over the years, are generally most up to date and maintained, there is more downside in !BPF_JIT_ALWAYS_ON configurations to have the interpreter enabled by default rather than the JIT. Add a ARCH_WANT_DEFAULT_BPF_JIT config which archs can use to set the bpf_jit_{enable,kallsyms} to 1. Back in the days the bpf_jit_kallsyms knob was set to 0 by default since major distros still had /proc/kallsyms addresses exposed to unprivileged user space which is not the case anymore. Hence both knobs are set via BPF_JIT_DEFAULT_ON which is set to 'y' in case of BPF_JIT_ALWAYS_ON or ARCH_WANT_DEFAULT_BPF_JIT. Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Acked-by: Will Deacon Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/f78ad24795c2966efcc2ee19025fa3459f622185.1575903816.git.daniel@iogearbox.net","arch/arm64/Kconfig | 1 +; arch/x86/Kconfig | 1 +; init/Kconfig | 7 +++++++; kernel/bpf/core.c | 4 ++--; 4 files changed, 11 insertions(+), 2 deletions(-)","The commit enables JIT by default on x86 and arm64 architectures when not built as always-on, optimizing execution performance.","JIT, x86, arm64","A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"fe3300897cbfd76c6cb825776e5ac0ca50a91ca4","fe3300897cbfd76c6cb825776e5ac0ca50a91ca4","Daniel T. Lee","danieltimlee@gmail.com","1575532874","Alexei Starovoitov","ast@kernel.org","1576106886","c27a039d9886cae1572f81d80e35af60bf9cd740","bba1b2a890253528c45aa66cf856f289a215bfbc","samples: bpf: fix syscall_tp due to unused syscall Currently, open() is called from the user program and it calls the syscall 'sys_openat', not the 'sys_open'. This leads to an error of the program of user side, due to the fact that the counter maps are zero since no function such 'sys_open' is called. This commit adds the kernel bpf program which are attached to the tracepoint 'sys_enter_openat' and 'sys_enter_openat'. Fixes: 1da236b6be963 (""bpf: add a test case for syscalls/sys_{enter|exit}_* tracepoints"") Signed-off-by: Daniel T. Lee Signed-off-by: Alexei Starovoitov ","samples/bpf/syscall_tp_kern.c | 18 ++++++++++++++++--; 1 file changed, 16 insertions(+), 2 deletions(-)","This commit fixes the user program error by attaching a kernel BPF program to the correct tracepoint 'sys_enter_openat'.","syscall,tracepoint,fix","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.']" +"bba1b2a890253528c45aa66cf856f289a215bfbc","bba1b2a890253528c45aa66cf856f289a215bfbc","Daniel T. Lee","danieltimlee@gmail.com","1575532873","Alexei Starovoitov","ast@kernel.org","1576106848","9904527553fc4a39078b9602f0d99ab1905e1e04","7f193c2519a3dcfd61cd5e676b2959370f4b15be","samples: bpf: Replace symbol compare of trace_event Previously, when this sample is added, commit 1c47910ef8013 (""samples/bpf: add perf_event+bpf example""), a symbol 'sys_read' and 'sys_write' has been used without no prefixes. But currently there are no exact symbols with these under kallsyms and this leads to failure. This commit changes exact compare to substring compare to keep compatible with exact symbol or prefixed symbol. Fixes: 1c47910ef8013 (""samples/bpf: add perf_event+bpf example"") Signed-off-by: Daniel T. Lee Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191205080114.19766-2-danieltimlee@gmail.com","samples/bpf/trace_event_user.c | 4 ++--; 1 file changed, 2 insertions(+), 2 deletions(-)","The commit updates the symbol comparison method in bpf samples for improved compatibility with current kallsyms symbols.","symbol, comparison, kallsyms","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.', 'kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"7f193c2519a3dcfd61cd5e676b2959370f4b15be","7f193c2519a3dcfd61cd5e676b2959370f4b15be","Alexei Starovoitov","ast@kernel.org","1575849674","Alexei Starovoitov","ast@kernel.org","1576106369","4791cb467f027a8f445513b02c738e67a9644740","b91e014f078e2e4f24778680e28dbbdecc7f0eb9","selftests/bpf: Test function_graph tracer and bpf trampoline together Add simple test script to execute funciton graph tracer while BPF trampoline attaches and detaches from the functions being graph traced. Signed-off-by: Alexei Starovoitov Acked-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191209000114.1876138-4-ast@kernel.org","tools/testing/selftests/bpf/test_ftrace.sh | 39 ++++++++++++++++++++++++++++++; 1 file changed, 39 insertions(+)","Adds a test script to run function graph tracer with BPF trampoline.","selftests tracer trampoline","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"b91e014f078e2e4f24778680e28dbbdecc7f0eb9","b91e014f078e2e4f24778680e28dbbdecc7f0eb9","Alexei Starovoitov","ast@kernel.org","1575849673","Alexei Starovoitov","ast@kernel.org","1576106288","7d92e7ddbdd5cc48543536c6311b6ea292c7f949","5b79bcdf03628a3a9ee04d9cd5fabcf61a8e20be","bpf: Make BPF trampoline use register_ftrace_direct() API Make BPF trampoline attach its generated assembly code to kernel functions via register_ftrace_direct() API. It helps ftrace-based tracers co-exist with BPF trampoline on the same kernel function. It also switches attaching logic from arch specific text_poke to generic ftrace that is available on many architectures. text_poke is still necessary for bpf-to-bpf attach and for bpf_tail_call optimization. Signed-off-by: Alexei Starovoitov Acked-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191209000114.1876138-3-ast@kernel.org","include/linux/bpf.h | 1 +; kernel/bpf/trampoline.c | 64 ++++++++++++++++++++++++++++++++++++++++++++-----; 2 files changed, 59 insertions(+), 6 deletions(-)","This commit changes BPF trampoline to use register_ftrace_direct() API for attaching to kernel functions, enhancing compatibility with ftrace-based tracers.","BPF, trampoline, ftrace","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.', 'kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"bae141f54be83b06652c1d47e50e4e75ed4e9c7e","bae141f54be83b06652c1d47e50e4e75ed4e9c7e","Daniel Borkmann","daniel@iogearbox.net","1575668974","Daniel Borkmann","daniel@iogearbox.net","1576082469","09b1716fe1145eab1023d1b3a84b683c87ee76a0","b590cb5f802dc20c72f507f7fbe6737222d0afba","bpf: Emit audit messages upon successful prog load and unload Allow for audit messages to be emitted upon BPF program load and unload for having a timeline of events. The load itself is in syscall context, so additional info about the process initiating the BPF prog creation can be logged and later directly correlated to the unload event. The only info really needed from BPF side is the globally unique prog ID where then audit user space tooling can query / dump all info needed about the specific BPF program right upon load event and enrich the record, thus these changes needed here can be kept small and non-intrusive to the core. Raw example output: # auditctl -D # auditctl -a always,exit -F arch=x86_64 -S bpf # ausearch --start recent -m 1334 ... ---- time->Wed Nov 27 16:04:13 2019 type=PROCTITLE msg=audit(1574867053.120:84664): proctitle=""./bpf"" type=SYSCALL msg=audit(1574867053.120:84664): arch=c000003e syscall=321 \ success=yes exit=3 a0=5 a1=7ffea484fbe0 a2=70 a3=0 items=0 ppid=7477 \ pid=12698 auid=1001 uid=1001 gid=1001 euid=1001 suid=1001 fsuid=1001 \ egid=1001 sgid=1001 fsgid=1001 tty=pts2 ses=4 comm=""bpf"" \ exe=""/home/jolsa/auditd/audit-testsuite/tests/bpf/bpf"" \ subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) type=UNKNOWN[1334] msg=audit(1574867053.120:84664): prog-id=76 op=LOAD ---- time->Wed Nov 27 16:04:13 2019 type=UNKNOWN[1334] msg=audit(1574867053.120:84665): prog-id=76 op=UNLOAD ... Signed-off-by: Daniel Borkmann Co-developed-by: Jiri Olsa Signed-off-by: Jiri Olsa Acked-by: Paul Moore Link: https://lore.kernel.org/bpf/20191206214934.11319-1-jolsa@kernel.org","include/uapi/linux/audit.h | 1 +; kernel/bpf/syscall.c | 33 +++++++++++++++++++++++++++++++++; 2 files changed, 34 insertions(+)","The commit implements audit message generation for BPF program load and unload to provide event history.","audit,program,events","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The syscall interface. It changes the system calls through which user-space programs interact with eBPF.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"b590cb5f802dc20c72f507f7fbe6737222d0afba","b590cb5f802dc20c72f507f7fbe6737222d0afba","Stanislav Fomichev","sdf@google.com","1576005573","Daniel Borkmann","daniel@iogearbox.net","1576072338","dfe609803b0fbe1536d8223c4e021c926ae30315","09c4708d3cf42b2b2211b1aee82e7baf446a24e8","bpf: Switch to offsetofend in BPF_PROG_TEST_RUN Switch existing pattern of ""offsetof(..., member) + FIELD_SIZEOF(..., member)' to ""offsetofend(..., member)"" which does exactly what we need without all the copy-paste. Suggested-by: Andrii Nakryiko Signed-off-by: Stanislav Fomichev Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20191210191933.105321-1-sdf@google.com","net/bpf/test_run.c | 12 ++++--------; 1 file changed, 4 insertions(+), 8 deletions(-)","Switches BPF_PROG_TEST_RUN to use offsetofend for cleaner code.","offsetofend, BPF_PROG_TEST_RUN, refactoring","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"09c4708d3cf42b2b2211b1aee82e7baf446a24e8","09c4708d3cf42b2b2211b1aee82e7baf446a24e8","Andrii Nakryiko","andriin@fb.com","1575931222","Daniel Borkmann","daniel@iogearbox.net","1576072237","21560775aa0db792262159edd2e60e8b86f710f4","c453312857ba41129db3558f5428405bbbb8f1a4","libbpf: Bump libpf current version to v0.0.7 New development cycles starts, bump to v0.0.7 proactively. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191209224022.3544519-1-andriin@fb.com","tools/lib/bpf/libbpf.map | 3 +++; 1 file changed, 3 insertions(+)","The commit bumps the libbpf version to v0.0.7 indicating the start of a new development cycle.","libbpf,version,bump","It's other type of commit. It does not fit into any of the categories listed above.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"c453312857ba41129db3558f5428405bbbb8f1a4","c453312857ba41129db3558f5428405bbbb8f1a4","Russell King","rmk+kernel@armlinux.org.uk","1575890250","Daniel Borkmann","daniel@iogearbox.net","1576071266","10b7805bc7995c24515874aef85e65c7827c5cdc","c21939998802b48e7afd0c0568193f6e4e4954f8","ARM: net: bpf: Improve prologue code sequence Improve the prologue code sequence to be able to take advantage of 64-bit stores, changing the code from: push {r4, r5, r6, r7, r8, r9, fp, lr} mov fp, sp sub ip, sp, #80 ; 0x50 sub sp, sp, #600 ; 0x258 str ip, [fp, #-100] ; 0xffffff9c mov r6, #0 str r6, [fp, #-96] ; 0xffffffa0 mov r4, #0 mov r3, r4 mov r2, r0 str r4, [fp, #-104] ; 0xffffff98 str r4, [fp, #-108] ; 0xffffff94 to the tighter: push {r4, r5, r6, r7, r8, r9, fp, lr} mov fp, sp mov r3, #0 sub r2, sp, #80 ; 0x50 sub sp, sp, #600 ; 0x258 strd r2, [fp, #-100] ; 0xffffff9c mov r2, #0 strd r2, [fp, #-108] ; 0xffffff94 mov r2, r0 resulting in a saving of three instructions. Signed-off-by: Russell King Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/E1ieH2g-0004ih-Rb@rmk-PC.armlinux.org.uk","arch/arm/net/bpf_jit_32.c | 30 +++++++++++++-----------------; 1 file changed, 13 insertions(+), 17 deletions(-)","This commit optimizes the ARM BPF JIT prologue code by utilizing 64-bit stores, improving efficiency and reducing instruction count.","ARM,JIT,optimization","A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"761bfc33dd7504de951aa7b9db27a3cc5df1fde6","761bfc33dd7504de951aa7b9db27a3cc5df1fde6","Arnaldo Carvalho de Melo","acme@redhat.com","1576069096","Arnaldo Carvalho de Melo","acme@redhat.com","1576069096","93f4ac22fb206fe214998a599f4d2ea0214be70a","0f60a0bcc1b96d531fa623ab520f863f1292c75b 6794862a16ef41f753abd75c03a152836e4c8028","Merge remote-tracking branch 'torvalds/master' into perf/urgent To pick up BPF fixes to allow a clean 'make -C tools/perf build-test': 7c3977d1e804 libbpf: Fix sym->st_value print on 32-bit arches 1fd450f99272 libbpf: Fix up generation of bpf_helper_defs.h Signed-off-by: Arnaldo Carvalho de Melo ","","This commit merges changes from the 'torvalds/master' branch into 'perf/urgent' focusing on BPF fixes for build compatibility.","merge, BPF, fixes","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"5b79bcdf03628a3a9ee04d9cd5fabcf61a8e20be","5b79bcdf03628a3a9ee04d9cd5fabcf61a8e20be","Toke Høiland-Jørgensen","toke@redhat.com","1576001652","Daniel Borkmann","daniel@iogearbox.net","1576069046","c3f21a9c363b0b320e5678a69b1d847d733cb5ef","4c80c7bc583a87ded5f61906f81256b57c795806","bpftool: Don't crash on missing jited insns or ksyms When the kptr_restrict sysctl is set, the kernel can fail to return jited_ksyms or jited_prog_insns, but still have positive values in nr_jited_ksyms and jited_prog_len. This causes bpftool to crash when trying to dump the program because it only checks the len fields not the actual pointers to the instructions and ksyms. Fix this by adding the missing checks. Fixes: 71bb428fe2c1 (""tools: bpf: add bpftool"") Fixes: f84192ee00b7 (""tools: bpftool: resolve calls without using imm field"") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191210181412.151226-1-toke@redhat.com","tools/bpf/bpftool/prog.c | 2 +-; tools/bpf/bpftool/xlated_dumper.c | 2 +-; 2 files changed, 2 insertions(+), 2 deletions(-)","Fixes a crash in bpftool by adding checks for missing jited instructions or ksyms.","bpftool,crash,checks","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"4c80c7bc583a87ded5f61906f81256b57c795806","4c80c7bc583a87ded5f61906f81256b57c795806","Arnd Bergmann","arnd@arndb.de","1576010146","Daniel Borkmann","daniel@iogearbox.net","1576069046","62e3ab6555488373a29752f5fd23cfedbfba8f53","e49e6f6db04e915dccb494ae10fa14888fea6f89","bpf: Fix build in minimal configurations, again Building with -Werror showed another failure: kernel/bpf/btf.c: In function 'btf_get_prog_ctx_type.isra.31': kernel/bpf/btf.c:3508:63: error: array subscript 0 is above array bounds of 'u8[0]' {aka 'unsigned char[0]'} [-Werror=array-bounds] ctx_type = btf_type_member(conv_struct) + bpf_ctx_convert_map[prog_type] * 2; I don't actually understand why the array is empty, but a similar fix has addressed a related problem, so I suppose we can do the same thing here. Fixes: ce27709b8162 (""bpf: Fix build in minimal configurations"") Signed-off-by: Arnd Bergmann Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191210203553.2941035-1-arnd@arndb.de","kernel/bpf/btf.c | 1 +; 1 file changed, 1 insertion(+)","Fixes a build error in btf.c related to array bounds in minimal configuration builds.","build,error,array","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.","BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"e49e6f6db04e915dccb494ae10fa14888fea6f89","e49e6f6db04e915dccb494ae10fa14888fea6f89","Paul Chaignon","paul.chaignon@orange.com","1575917572","Daniel Borkmann","daniel@iogearbox.net","1576069042","15bc7b936f5dab803ec4e14f0b2ff33decee73c2","96bc4432f5ade1045521f3b247f516b1478166bd","bpf, mips: Limit to 33 tail calls All BPF JIT compilers except RISC-V's and MIPS' enforce a 33-tail calls limit at runtime. In addition, a test was recently added, in tailcalls2, to check this limit. This patch updates the tail call limit in MIPS' JIT compiler to allow 33 tail calls. Fixes: b6bd53f9c4e8 (""MIPS: Add missing file for eBPF JIT."") Reported-by: Mahshid Khezri Signed-off-by: Paul Chaignon Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/b8eb2caac1c25453c539248e56ca22f74b5316af.1575916815.git.paul.chaignon@gmail.com","arch/mips/net/ebpf_jit.c | 9 +++++----; 1 file changed, 5 insertions(+), 4 deletions(-)","The commit updates the MIPS eBPF JIT compiler to enforce a limit of 33 tail calls.","MIPS,JIT,tail","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"96bc4432f5ade1045521f3b247f516b1478166bd","96bc4432f5ade1045521f3b247f516b1478166bd","Paul Chaignon","paul.chaignon@orange.com","1575917527","Daniel Borkmann","daniel@iogearbox.net","1576069037","fdfa20e990e22c74004d58a1246f958112394b86","24dee0c7478d1a1e00abdf5625b7f921467325dc","bpf, riscv: Limit to 33 tail calls All BPF JIT compilers except RISC-V's and MIPS' enforce a 33-tail calls limit at runtime. In addition, a test was recently added, in tailcalls2, to check this limit. This patch updates the tail call limit in RISC-V's JIT compiler to allow 33 tail calls. I tested it using the above selftest on an emulated RISCV64. Fixes: 2353ecc6f91f (""bpf, riscv: add BPF JIT for RV64G"") Reported-by: Mahshid Khezri Signed-off-by: Paul Chaignon Signed-off-by: Daniel Borkmann Acked-by: Björn Töpel Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/966fe384383bf23a0ee1efe8d7291c78a3fb832b.1575916815.git.paul.chaignon@gmail.com","arch/riscv/net/bpf_jit_comp.c | 4 ++--; 1 file changed, 2 insertions(+), 2 deletions(-)","The commit updates RISC-V's BPF JIT compiler to enforce a 33-tail calls limit.","RISC-V, JIT, tail-calls","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"95e6ba5133163f8241c9ea2439369cec0452fec6","95e6ba5133163f8241c9ea2439369cec0452fec6","Linus Torvalds","torvalds@linux-foundation.org","1575840491","Linus Torvalds","torvalds@linux-foundation.org","1575840491","3b84a8150537c03573ea8bfbd123e9cd52e19f3d","138f371ddf4ff50207dbe33ebfc237e756cd6222 0fc75219fe9a3c90631453e9870e4f6d956f0ebc","Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from David Miller: 1) More jumbo frame fixes in r8169, from Heiner Kallweit. 2) Fix bpf build in minimal configuration, from Alexei Starovoitov. 3) Use after free in slcan driver, from Jouni Hogander. 4) Flower classifier port ranges don't work properly in the HW offload case, from Yoshiki Komachi. 5) Use after free in hns3_nic_maybe_stop_tx(), from Yunsheng Lin. 6) Out of bounds access in mqprio_dump(), from Vladyslav Tarasiuk. 7) Fix flow dissection in dsa TX path, from Alexander Lobakin. 8) Stale syncookie timestampe fixes from Guillaume Nault. [ Did an evil merge to silence a warning introduced by this pull - Linus ] * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (84 commits) r8169: fix rtl_hw_jumbo_disable for RTL8168evl net_sched: validate TCA_KIND attribute in tc_chain_tmplt_add() r8169: add missing RX enabling for WoL on RTL8125 vhost/vsock: accept only packets with the right dst_cid net: phy: dp83867: fix hfs boot in rgmii mode net: ethernet: ti: cpsw: fix extra rx interrupt inet: protect against too small mtu values. gre: refetch erspan header from skb->data after pskb_may_pull() pppoe: remove redundant BUG_ON() check in pppoe_pernet tcp: Protect accesses to .ts_recent_stamp with {READ,WRITE}_ONCE() tcp: tighten acceptance of ACKs not matching a child socket tcp: fix rejected syncookies due to stale timestamps lpc_eth: kernel BUG on remove tcp: md5: fix potential overestimation of TCP option space net: sched: allow indirect blocks to bind to clsact in TC net: core: rename indirect block ingress cb function net-sysfs: Call dev_hold always in netdev_queue_add_kobject net: dsa: fix flow dissection on Tx path net/tls: Fix return values to avoid ENOTSUPP net: avoid an indirect call in ____sys_recvmsg() ...","","The commit merges networking fixes including bpf build and multiple driver bugs from the netdev repository by David Miller.","networking,fixes,merge","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"ae72555b410410568b493f8735324f8e9bd7c051","ae72555b410410568b493f8735324f8e9bd7c051","David S. Miller","davem@davemloft.net","1575619455","David S. Miller","davem@davemloft.net","1575619455","6b86350dbaf4de0801e7ae58aac9b0e410714ecc","0033b34a03ec5cf747cdaf9b1f9dceb91c020f17 8f9081c92523328aa569d09051add79a6c0ae9ff","Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf Alexei Starovoitov says: ==================== pull-request: bpf 2019-12-05 The following pull-request contains BPF updates for your *net* tree. We've added 6 non-merge commits during the last 1 day(s) which contain a total of 14 files changed, 116 insertions(+), 37 deletions(-). The main changes are: 1) three selftests fixes, from Stanislav. 2) one samples fix, from Jesper. 3) one verifier fix, from Yonghong. ==================== Signed-off-by: David S. Miller ","","Merge commit integrating BPF updates into the net tree, including fixes for selftests, samples, and verifier.","BPF, merge, updates","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"0033b34a03ec5cf747cdaf9b1f9dceb91c020f17","0033b34a03ec5cf747cdaf9b1f9dceb91c020f17","Eric Biggers","ebiggers@google.com","1575525259","David S. Miller","davem@davemloft.net","1575585919","299f3f47c09c1e21245194204662b96bb73ef6a1","a116f4e238cc20dfbac30c65949752798f5b6efa","ppp: fix out-of-bounds access in bpf_prog_create() sock_fprog_kern::len is in units of struct sock_filter, not bytes. Fixes: 3e859adf3643 (""compat_ioctl: unify copy-in of ppp filters"") Reported-by: syzbot+eb853b51b10f1befa0b7@syzkaller.appspotmail.com Signed-off-by: Eric Biggers Reviewed-by: Arnd Bergmann Signed-off-by: David S. Miller ","drivers/net/ppp/ppp_generic.c | 5 +++--; 1 file changed, 3 insertions(+), 2 deletions(-)","Fixes an out-of-bounds access issue in bpf_prog_create with sock_fprog_kern::len.","ppp out-of-bounds sock_fprog_kern","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.","It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.","[""It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here.""]" +"8f9081c92523328aa569d09051add79a6c0ae9ff","8f9081c92523328aa569d09051add79a6c0ae9ff","Yonghong Song","yhs@fb.com","1575507967","Alexei Starovoitov","ast@kernel.org","1575524082","5cd0f621eb5b96126bf31cc8fec67a49d14e8e51","e9eeec58c992c47b394e4f829e4f81b923b0a322","selftests/bpf: Add a fexit/bpf2bpf test with target bpf prog no callees The existing fexit_bpf2bpf test covers the target progrm with callees. This patch added a test for the target program without callees. Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191205010607.177904-1-yhs@fb.com",".../selftests/bpf/prog_tests/fexit_bpf2bpf.c | 70 ++++++++++++++++------; .../selftests/bpf/progs/fexit_bpf2bpf_simple.c | 26 ++++++++; .../selftests/bpf/progs/test_pkt_md_access.c | 4 +-; 3 files changed, 81 insertions(+), 19 deletions(-)","The commit adds a selftest for an eBPF program without callees in the fexit_bpf2bpf test suite.","test,fexit,bpf2bpf","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"e9eeec58c992c47b394e4f829e4f81b923b0a322","e9eeec58c992c47b394e4f829e4f81b923b0a322","Yonghong Song","yhs@fb.com","1575507966","Alexei Starovoitov","ast@kernel.org","1575523207","a77691b0ca01393ba337e39261c0d3c2e5225ac8","ef8c84effce3c7a0b8196fcda8f430c815ab511c","bpf: Fix a bug when getting subprog 0 jited image in check_attach_btf_id For jited bpf program, if the subprogram count is 1, i.e., there is no callees in the program, prog->aux->func will be NULL and prog->bpf_func points to image address of the program. If there is more than one subprogram, prog->aux->func is populated, and subprogram 0 can be accessed through either prog->bpf_func or prog->aux->func[0]. Other subprograms should be accessed through prog->aux->func[subprog_id]. This patch fixed a bug in check_attach_btf_id(), where prog->aux->func[subprog_id] is used to access any subprogram which caused a segfault like below: [79162.619208] BUG: kernel NULL pointer dereference, address: 0000000000000000 ...... [79162.634255] Call Trace: [79162.634974] ? _cond_resched+0x15/0x30 [79162.635686] ? kmem_cache_alloc_trace+0x162/0x220 [79162.636398] ? selinux_bpf_prog_alloc+0x1f/0x60 [79162.637111] bpf_prog_load+0x3de/0x690 [79162.637809] __do_sys_bpf+0x105/0x1740 [79162.638488] do_syscall_64+0x5b/0x180 [79162.639147] entry_SYSCALL_64_after_hwframe+0x44/0xa9 ...... Fixes: 5b92a28aae4d (""bpf: Support attaching tracing BPF program to other BPF programs"") Reported-by: Eelco Chaudron Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191205010606.177774-1-yhs@fb.com","kernel/bpf/verifier.c | 5 ++++-; 1 file changed, 4 insertions(+), 1 deletion(-)","Fixes a bug causing a segfault in check_attach_btf_id by correcting subprogram access in jited BPF programs.","bug,segfault,subprogram","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"ef8c84effce3c7a0b8196fcda8f430c815ab511c","ef8c84effce3c7a0b8196fcda8f430c815ab511c","Stanislav Fomichev","sdf@google.com","1575486595","Alexei Starovoitov","ast@kernel.org","1575511265","10cc86cc9c2f54f8bf93c7e8f6da1ccfafa6c719","6bf6affe18dafea6ef12036001162ac7f2dbf738","selftests/bpf: De-flake test_tcpbpf It looks like BPF program that handles BPF_SOCK_OPS_STATE_CB state can race with the bpf_map_lookup_elem(""global_map""); I sometimes see the failures in this test and re-running helps. Since we know that we expect the callback to be called 3 times (one time for listener socket, two times for both ends of the connection), let's export this number and add simple retry logic around that. Also, let's make EXPECT_EQ() not return on failure, but continue evaluating all conditions; that should make potential debugging easier. With this fix in place I don't observe the flakiness anymore. Signed-off-by: Stanislav Fomichev Signed-off-by: Alexei Starovoitov Cc: Lawrence Brakmo Link: https://lore.kernel.org/bpf/20191204190955.170934-1-sdf@google.com",".../testing/selftests/bpf/progs/test_tcpbpf_kern.c | 1 +; tools/testing/selftests/bpf/test_tcpbpf.h | 1 +; tools/testing/selftests/bpf/test_tcpbpf_user.c | 25 ++++++++++++++++------; 3 files changed, 20 insertions(+), 7 deletions(-)","The commit addresses test flakiness in test_tcpbpf by adding retry logic and enhancing error handling.","test, retry, flakiness","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"6bf6affe18dafea6ef12036001162ac7f2dbf738","6bf6affe18dafea6ef12036001162ac7f2dbf738","Stanislav Fomichev","sdf@google.com","1575323971","Alexei Starovoitov","ast@kernel.org","1575511075","409a3af52c0fd0670c0bbae50df63d5ca1f8e577","01d434ce98d38e36901c72493b96afc4075ee887","selftests/bpf: Bring back c++ include/link test Commit 5c26f9a78358 (""libbpf: Don't use cxx to test_libpf target"") converted existing c++ test to c. We still want to include and link against libbpf from c++ code, so reinstate this test back, this time in a form of a selftest with a clear comment about its purpose. v2: * -lelf -> $(LDLIBS) (Andrii Nakryiko) Fixes: 5c26f9a78358 (""libbpf: Don't use cxx to test_libpf target"") Signed-off-by: Stanislav Fomichev Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20191202215931.248178-1-sdf@google.com","tools/lib/bpf/.gitignore | 1 -; tools/lib/bpf/Makefile | 5 +----; tools/lib/bpf/test_libbpf.c | 20 --------------------; tools/testing/selftests/bpf/.gitignore | 1 +; tools/testing/selftests/bpf/Makefile | 6 +++++-; tools/testing/selftests/bpf/test_cpp.cpp | 20 ++++++++++++++++++++; 6 files changed, 27 insertions(+), 26 deletions(-)","Reinstate the C++ include and link test for libbpf in the selftests framework to ensure proper functionality.","C++ include, link test, libbpf","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"01d434ce98d38e36901c72493b96afc4075ee887","01d434ce98d38e36901c72493b96afc4075ee887","Stanislav Fomichev","sdf@google.com","1575316903","Alexei Starovoitov","ast@kernel.org","1575510982","ccfa1fb75daed2ee62cd8252b106dc255a6f8782","edbca120a8cdfa5a5793707e33497aa5185875ca","selftests/bpf: Don't hard-code root cgroup id Commit 40430452fd5d (""kernfs: use 64bit inos if ino_t is 64bit"") changed the way cgroup ids are exposed to the userspace. Instead of assuming fixed root id, let's query it. Fixes: 40430452fd5d (""kernfs: use 64bit inos if ino_t is 64bit"") Signed-off-by: Stanislav Fomichev Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191202200143.250793-1-sdf@google.com","tools/testing/selftests/bpf/test_skb_cgroup_id_user.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","The commit adjusts a selftest to query the dynamic root cgroup ID instead of using a fixed value due to changes in kernfs handling.","query cgroup selftests","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","['cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups).']" +"edbca120a8cdfa5a5793707e33497aa5185875ca","edbca120a8cdfa5a5793707e33497aa5185875ca","Jesper Dangaard Brouer","brouer@redhat.com","1575290251","Alexei Starovoitov","ast@kernel.org","1575510855","0503e0d8d7acdf7ccac3a62e123e232a956c5b17","099ffd7eddfe03b9b5b43e1f4ffece99121dd7ba","samples/bpf: Fix broken xdp_rxq_info due to map order assumptions In the days of using bpf_load.c the order in which the 'maps' sections were defines in BPF side (*_kern.c) file, were used by userspace side to identify the map via using the map order as an index. In effect the order-index is created based on the order the maps sections are stored in the ELF-object file, by the LLVM compiler. This have also carried over in libbpf via API bpf_map__next(NULL, obj) to extract maps in the order libbpf parsed the ELF-object file. When BTF based maps were introduced a new section type "".maps"" were created. I found that the LLVM compiler doesn't create the "".maps"" sections in the order they are defined in the C-file. The order in the ELF file is based on the order the map pointer is referenced in the code. This combination of changes lead to xdp_rxq_info mixing up the map file-descriptors in userspace, resulting in very broken behaviour, but without warning the user. This patch fix issue by instead using bpf_object__find_map_by_name() to find maps via their names. (Note, this is the ELF name, which can be longer than the name the kernel retains). Fixes: be5bca44aa6b (""samples: bpf: convert some XDP samples from bpf_load to libbpf"") Fixes: 451d1dc886b5 (""samples: bpf: update map definition to new syntax BTF-defined map"") Signed-off-by: Jesper Dangaard Brouer Signed-off-by: Alexei Starovoitov Acked-by: Toke Høiland-Jørgensen Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/157529025128.29832.5953245340679936909.stgit@firesoul","samples/bpf/xdp_rxq_info_user.c | 6 +++---; 1 file changed, 3 insertions(+), 3 deletions(-)","Fixes map descriptor ordering issue in xdp_rxq_info by using map names instead of order-indexing.","map ordering, xdp_rxq_info, BTF-defined","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"01d1dff64662646023482806c6db8ef0b280c403","01d1dff64662646023482806c6db8ef0b280c403","Linus Torvalds","torvalds@linux-foundation.org","1575406200","Linus Torvalds","torvalds@linux-foundation.org","1575406200","52647a59400ed89e90d096cf77f36b20e105e25f","4d7048f55104434ec64fe0b5196cbc89a8f99548 2115fbf7210bd053ba55a95e7ebc366df41aa9cf","Merge tag 's390-5.5-2' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull more s390 updates from Vasily Gorbik: - Make stack unwinder reliable and suitable for livepatching. Add unwinder testing module. - Fixes for CALL_ON_STACK helper used for stack switching. - Fix unwinding from bpf code. - Fix getcpu and remove compat support in vdso code. - Fix address space control registers initialization. - Save KASLR offset for early dumps. - Handle new FILTERED_BY_HYPERVISOR reply code in crypto code. - Minor perf code cleanup and potential memory leak fix. - Add couple of error messages for corner cases during PCI device creation. * tag 's390-5.5-2' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: (33 commits) s390: remove compat vdso code s390/livepatch: Implement reliable stack tracing for the consistency model s390/unwind: add stack pointer alignment sanity checks s390/unwind: filter out unreliable bogus %r14 s390/unwind: start unwinding from reliable state s390/test_unwind: add program check context tests s390/test_unwind: add irq context tests s390/test_unwind: print verbose unwinding results s390/test_unwind: add CALL_ON_STACK tests s390: fix register clobbering in CALL_ON_STACK s390/test_unwind: require that unwinding ended successfully s390/unwind: add a test for the internal API s390/unwind: always inline get_stack_pointer s390/pci: add error message on device number limit s390/pci: add error message for UID collision s390/cpum_sf: Check for SDBT and SDB consistency s390/cpum_sf: Use TEAR_REG macro consistantly s390/cpum_sf: Remove unnecessary check for pending SDBs s390/cpum_sf: Replace function name in debug statements s390/kaslr: store KASLR offset for early dumps ...","","This is a merge commit incorporating various updates and fixes for the s390 architecture in the Linux kernel.","s390, updates, merge","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"734c7022adaa7833aa809b3f2c3fc0cf09b2a48e","734c7022adaa7833aa809b3f2c3fc0cf09b2a48e","David S. Miller","davem@davemloft.net","1575312629","David S. Miller","davem@davemloft.net","1575312629","a6d220f304709e6c18c0e42b9746bf0c3fcb74c9","596cf45cbf6e4fa7bcb0df33e373a7d062b644b5 3464afdf11f9a1e031e7858a05351ceca1792fea","Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf Daniel Borkmann says: ==================== pull-request: bpf 2019-12-02 The following pull-request contains BPF updates for your *net* tree. We've added 10 non-merge commits during the last 6 day(s) which contain a total of 10 files changed, 60 insertions(+), 51 deletions(-). The main changes are: 1) Fix vmlinux BTF generation for binutils pre v2.25, from Stanislav Fomichev. 2) Fix libbpf global variable relocation to take symbol's st_value offset into account, from Andrii Nakryiko. 3) Fix libbpf build on powerpc where check_abi target fails due to different readelf output format, from Aurelien Jarno. 4) Don't set BPF insns RO for the case when they are JITed in order to avoid fragmenting the direct map, from Daniel Borkmann. 5) Fix static checker warning in btf_distill_func_proto() as well as a build error due to empty enum when BPF is compiled out, from Alexei Starovoitov. 6) Fix up generation of bpf_helper_defs.h for perf, from Arnaldo Carvalho de Melo. ==================== Signed-off-by: David S. Miller ","","This is a merge commit of BPF updates with fixes for various issues like vmlinux BTF generation and libbpf builds.","merge,BPF,fixes","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"3464afdf11f9a1e031e7858a05351ceca1792fea","3464afdf11f9a1e031e7858a05351ceca1792fea","Aurelien Jarno","aurelien@aurel32.net","1575230248","Daniel Borkmann","daniel@iogearbox.net","1575279114","2eb264beecf93f18c644d6a4dede1bb2244f9d46","e1608f3fa857b600045b6df7f7dadc70eeaa4496","libbpf: Fix readelf output parsing on powerpc with recent binutils On powerpc with recent versions of binutils, readelf outputs an extra field when dumping the symbols of an object file. For example: 35: 0000000000000838 96 FUNC LOCAL DEFAULT [: 8] 1 btf_is_struct The extra ""[: 8]"" prevents the GLOBAL_SYM_COUNT variable to be computed correctly and causes the check_abi target to fail. Fix that by looking for the symbol name in the last field instead of the 8th one. This way it should also cope with future extra fields. Signed-off-by: Aurelien Jarno Signed-off-by: Daniel Borkmann Tested-by: Michael Ellerman Link: https://lore.kernel.org/bpf/20191201195728.4161537-1-aurelien@aurel32.net","tools/lib/bpf/Makefile | 4 ++--; 1 file changed, 2 insertions(+), 2 deletions(-)","Fixes readelf output parsing on powerpc with recent binutils by adjusting symbol name field detection.","libbpf,readelf,powerpc","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"c3bfc5dd73c6f519ff0636d4e709515f06edef78","c3bfc5dd73c6f519ff0636d4e709515f06edef78","Linus Torvalds","torvalds@linux-foundation.org","1575261303","Linus Torvalds","torvalds@linux-foundation.org","1575261303","e4e0ab6d67c44a96ca06e05d7d074e39320cc7e2","e5b3fc125d768eacd73bb4dc5019f0ce95635af4 c5d728113532c695c894c2a88a10453ac83b0f3b","Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from David Miller: 1) Fix several scatter gather list issues in kTLS code, from Jakub Kicinski. 2) macb driver device remove has to kill the hresp_err_tasklet. From Chuhong Yuan. 3) Several memory leak and reference count bug fixes in tipc, from Tung Nguyen. 4) Fix mlx5 build error w/o ipv6, from Yue Haibing. 5) Fix jumbo frame and other regressions in r8169, from Heiner Kallweit. 6) Undo some BUG_ON()'s and replace them with WARN_ON_ONCE and proper error propagation/handling. From Paolo Abeni. * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (24 commits) openvswitch: remove another BUG_ON() openvswitch: drop unneeded BUG_ON() in ovs_flow_cmd_build_info() net: phy: realtek: fix using paged operations with RTL8105e / RTL8208 r8169: fix resume on cable plug-in r8169: fix jumbo configuration for RTL8168evl net: emulex: benet: indent a Kconfig depends continuation line selftests: forwarding: fix race between packet receive and tc check net: sched: fix `tc -s class show` no bstats on class with nolock subqueues net: ethernet: ti: ale: ensure vlan/mdb deleted when no members net/mlx5e: Fix build error without IPV6 selftests: pmtu: use -oneline for ip route list cache tipc: fix duplicate SYN messages under link congestion tipc: fix wrong timeout input for tipc_wait_for_cond() tipc: fix wrong socket reference counter after tipc_sk_timeout() returns tipc: fix potential memory leak in __tipc_sendmsg() net: macb: add missed tasklet_kill selftests: bpf: correct perror strings selftests: bpf: test_sockmap: handle file creation failures gracefully net/tls: use sg_next() to walk sg entries net/tls: remove the dead inplace_crypto code ...","","This commit merges multiple networking fixes from the netdev branch into the main branch.","networking,merge,fixes","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"b7fcf31f7036895ca8fc3a30eefffab0e82f75f6","b7fcf31f7036895ca8fc3a30eefffab0e82f75f6","Linus Torvalds","torvalds@linux-foundation.org","1575254997","Linus Torvalds","torvalds@linux-foundation.org","1575254997","de2480af1cb8213dd32f56ab596759a76ec7bd57","72c0870e3a05d9cd5466d08c3d2a3069ed0a2f9f e680a41fcaf07ccac8817c589fc4824988b48eac","Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf fixes from Ingo Molnar: - Make /sys/devices/cpu/rdpmc based RDPMC enforcement more instantaneous - decoder: Update the Intel opcode map - Various tooling fixes, including a few late optimizations and cleanups. * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (23 commits) perf script: Fix invalid LBR/binary mismatch error perf script: Fix brstackinsn for AUXTRACE perf affinity: Add infrastructure to save/restore affinity perf pmu: Use file system cache to optimize sysfs access perf regs: Make perf_reg_name() return ""unknown"" instead of NULL perf diff: Use llabs() with 64-bit values perf diff: Use llabs() with 64-bit values perf/x86: Implement immediate enforcement of /sys/devices/cpu/rdpmc value of 0 perf tools: Allow to link with libbpf dynamicaly perf tests: Rename tests/map_groups.c to tests/maps.c perf tests: Rename thread-mg-share to thread-maps-share perf maps: Rename map_groups.h to maps.h perf maps: Rename 'mg' variables to 'maps' perf map_symbol: Rename ms->mg to ms->maps perf addr_location: Rename al->mg to al->maps perf thread: Rename thread->mg to thread->maps perf maps: Merge 'struct maps' with 'struct map_groups' x86/insn: perf tools: Add some more instructions to the new instructions test x86/insn: Add some more Intel instructions to the opcode map perf map: Remove unused functions ...","","This commit merges perf fixes, updates, and optimizations from Ingo Molnar's branch to the mainline kernel.","merge,perf,fixes","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"e1608f3fa857b600045b6df7f7dadc70eeaa4496","e1608f3fa857b600045b6df7f7dadc70eeaa4496","Daniel Borkmann","daniel@iogearbox.net","1575066551","Alexei Starovoitov","ast@kernel.org","1575221643","5993631f992a9465dc0036dabe9c6890d948acf2","df786c9b947639aedbc7bb44b5dae2a7824af360","bpf: Avoid setting bpf insns pages read-only when prog is jited For the case where the interpreter is compiled out or when the prog is jited it is completely unnecessary to set the BPF insn pages as read-only. In fact, on frequent churn of BPF programs, it could lead to performance degradation of the system over time since it would break the direct map down to 4k pages when calling set_memory_ro() for the insn buffer on x86-64 / arm64 and there is no reverse operation. Thus, avoid breaking up large pages for data maps, and only limit this to the module range used by the JIT where it is necessary to set the image read-only and executable. Suggested-by: Peter Zijlstra Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191129222911.3710-1-daniel@iogearbox.net","include/linux/filter.h | 8 ++++++--; 1 file changed, 6 insertions(+), 2 deletions(-)","This commit optimizes system performance by avoiding unnecessary read-only memory settings for BPF instruction pages when the program is JIT compiled.","JIT,performance,memory","A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"914d52e46490b6599b7f03fad233f4f19bf23cf7","914d52e46490b6599b7f03fad233f4f19bf23cf7","Ilya Leoshkevich","iii@linux.ibm.com","1562249895","Vasily Gorbik","gor@linux.ibm.com","1575107564","fc4a50362037e203cfacff290f77f8db02df8fb6","ea1f56fa16ae5f6e67f6ea03836b36c6053d33d1","s390: implement perf_arch_fetch_caller_regs On s390 bpf_get_stack_raw_tp() returns 0 entries for both kernel and user stacks. While there is no practical unwinding solution for userspace on s390 at this moment, there certainly is a kernel unwinder. However, it is not properly integrated with BPF. In order to start unwinding, bpf_get_stack_raw_tp() obtains the current kernel register values using perf_fetch_caller_regs(), which is not implemented for s390. The actual unwinding then happens by passing those registers to perf_callchain_kernel(). Implement perf_arch_fetch_caller_regs() for s390, where __builtin_frame_address(0) points to back_chain. Signed-off-by: Ilya Leoshkevich Acked-by: Heiko Carstens Signed-off-by: Vasily Gorbik ","arch/s390/include/asm/perf_event.h | 7 +++++++; 1 file changed, 7 insertions(+)","Implement perf_arch_fetch_caller_regs for s390 to integrate kernel unwinding with BPF.","s390 kernel unwinding","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.', 'Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.', 'Profile related type programs. It affects programs used for profiling system or application performance.']" +"df786c9b947639aedbc7bb44b5dae2a7824af360","df786c9b947639aedbc7bb44b5dae2a7824af360","Stanislav Fomichev","sdf@google.com","1574895479","Daniel Borkmann","daniel@iogearbox.net","1575019137","c47ad5f82c960333514486f3b0b3572ffae569f5","ce27709b8162e5c501bc54292b8bf6bdecc4bbd4","bpf: Force .BTF section start to zero when dumping from vmlinux While trying to figure out why fentry_fexit selftest doesn't pass for me (old pahole, broken BTF), I found out that my latest patch can break vmlinux .BTF generation. objcopy preserves section start when doing --only-section, so there is a chance (depending on where pahole inserts .BTF section) to have leading empty zeroes. Let's explicitly force section offset to zero. Before: $ objcopy --set-section-flags .BTF=alloc -O binary \ --only-section=.BTF vmlinux .btf.vmlinux.bin $ xxd .btf.vmlinux.bin | head -n1 00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................ After: $ objcopy --change-section-address .BTF=0 \ --set-section-flags .BTF=alloc -O binary \ --only-section=.BTF vmlinux .btf.vmlinux.bin $ xxd .btf.vmlinux.bin | head -n1 00000000: 9feb 0100 1800 0000 0000 0000 80e1 1c00 ................ ^BTF magic As part of this change, I'm also dropping '2>/dev/null' from objcopy invocation to be able to catch possible other issues (objcopy doesn't produce any warnings for me anymore, it did before with --dump-section). Fixes: da5fb18225b4 (""bpf: Support pre-2.25-binutils objcopy for vmlinux BTF"") Signed-off-by: Stanislav Fomichev Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Cc: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20191127225759.39923-1-sdf@google.com","scripts/link-vmlinux.sh | 5 +++--; 1 file changed, 3 insertions(+), 2 deletions(-)","The commit fixes the BTF section offset in vmlinux to prevent leading zeros in objcopy operations.","BTF,objcopy,offset","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"2eaa857534b4860dc337496e35f72f50614383b3","2eaa857534b4860dc337496e35f72f50614383b3","David S. Miller","davem@davemloft.net","1575009630","David S. Miller","davem@davemloft.net","1575009630","c221b6c928b70543c9c5d1ba29c60b33448a74c3","81b6b96475ac7a4ebfceae9f16fb3758327adbfe e5dc9dd3258098bf8b5ceb75fc3433b41eff618a","Merge branch 'net-tls-fix-scatter-gather-list-issues' Jakub Kicinski says: ==================== net: tls: fix scatter-gather list issues This series kicked of by a syzbot report fixes three issues around scatter gather handling in the TLS code. First patch fixes a use- -after-free situation which may occur if record was freed on error. This could have already happened in BPF paths, and patch 2 now makes the same condition occur in non-BPF code. Patch 2 fixes the problem spotted by syzbot. If encryption failed we have to clean the end markings from scatter gather list. As suggested by John the patch frees the record entirely and caller may retry copying data from user space buffer again. Third patch fixes a bug in the TLS 1.3 code spotted while working on patch 2. TLS 1.3 may effectively overflow the SG list which leads to the BUG() in sg_page() being triggered. Patch 4 adds a test case which triggers this bug reliably. Next two patches are small cleanups of dead code and code which makes dangerous assumptions. Last but not least two minor improvements to the sockmap tests. Tested: - bpf/test_sockmap - net/tls - syzbot repro (which used error injection, hence no direct selftest is added to preserve it). ==================== Signed-off-by: David S. Miller ","","The commit merges fixes for TLS issues in scatter-gather lists, affecting both BPF and non-BPF paths for stability improvements.","TLS,scatter-gather,fixes","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.","It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.","[""It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.""]" +"e5dc9dd3258098bf8b5ceb75fc3433b41eff618a","e5dc9dd3258098bf8b5ceb75fc3433b41eff618a","Jakub Kicinski","jakub.kicinski@netronome.com","1574885806","David S. Miller","davem@davemloft.net","1575009630","c221b6c928b70543c9c5d1ba29c60b33448a74c3","4b67c515036313f3c3ecba3cb2babb9cbddb3f85","selftests: bpf: correct perror strings perror(str) is basically equivalent to print(""%s: %s\n"", str, strerror(errno)). New line or colon at the end of str is a mistake/breaks formatting. Signed-off-by: Jakub Kicinski Reviewed-by: Simon Horman Signed-off-by: David S. Miller ","tools/testing/selftests/bpf/test_sockmap.c | 38 +++++++++++++++---------------; tools/testing/selftests/bpf/xdping.c | 2 +-; 2 files changed, 20 insertions(+), 20 deletions(-)","Correct formatting of perror strings in BPF selftest files.","perror, formatting, selftests","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"4b67c515036313f3c3ecba3cb2babb9cbddb3f85","4b67c515036313f3c3ecba3cb2babb9cbddb3f85","Jakub Kicinski","jakub.kicinski@netronome.com","1574885805","David S. Miller","davem@davemloft.net","1575009629","1c65cc52ee48a877be23fcc2203cfef98fca3fd8","c5daa6cccdc2f94aca2c9b3fa5f94e4469997293","selftests: bpf: test_sockmap: handle file creation failures gracefully test_sockmap creates a temporary file to use for sendpage. this may fail for various reasons. Handle the error rather than segfault. Signed-off-by: Jakub Kicinski Reviewed-by: Simon Horman Signed-off-by: David S. Miller ","tools/testing/selftests/bpf/test_sockmap.c | 9 +++++++++; 1 file changed, 9 insertions(+)","The commit enhances test_sockmap to handle file creation errors gracefully to prevent segfaults.","selftests,file,segfault","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"9e5ffed37df68d0ccfb2fdc528609e23a1e70ebe","9e5ffed37df68d0ccfb2fdc528609e23a1e70ebe","Jakub Kicinski","jakub.kicinski@netronome.com","1574885803","David S. Miller","davem@davemloft.net","1575009629","92fafe20cc6e67a73043b9bf46711e65934eda85","65190f77424d7b82c4aad7326c9cce6bd91a2fcc","net/tls: remove the dead inplace_crypto code Looks like when BPF support was added by commit d3b18ad31f93 (""tls: add bpf support to sk_msg handling"") and commit d829e9c4112b (""tls: convert to generic sk_msg interface"") it broke/removed the support for in-place crypto as added by commit 4e6d47206c32 (""tls: Add support for inplace records encryption""). The inplace_crypto member of struct tls_rec is dead, inited to zero, and sometimes set to zero again. It used to be set to 1 when record was allocated, but the skmsg code doesn't seem to have been written with the idea of in-place crypto in mind. Since non trivial effort is required to bring the feature back and we don't really have the HW to measure the benefit just remove the left over support for now to avoid confusing readers. Signed-off-by: Jakub Kicinski Reviewed-by: Simon Horman Signed-off-by: David S. Miller ","include/net/tls.h | 1 -; net/tls/tls_sw.c | 6 +-----; 2 files changed, 1 insertion(+), 6 deletions(-)","The commit removes obsolete in-place crypto code in TLS affected by past BPF sk_msg handling changes.","TLS,inplace_crypto,sk_msg","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","[""It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here.""]" +"d10523d0b3d78153ee58d19853ced26c9004c8c4","d10523d0b3d78153ee58d19853ced26c9004c8c4","Jakub Kicinski","jakub.kicinski@netronome.com","1574885800","David S. Miller","davem@davemloft.net","1575009629","8e86eea39a1cfc9a35cc3abb86e532915f0e10c7","c329ef9684de9517d82af5b4758c9e1b64a8a11a","net/tls: free the record on encryption error When tls_do_encryption() fails the SG lists are left with the SG_END and SG_CHAIN marks in place. One could hope that once encryption fails we will never see the record again, but that is in fact not true. Commit d3b18ad31f93 (""tls: add bpf support to sk_msg handling"") added special handling to ENOMEM and ENOSPC errors which mean we may see the same record re-submitted. As suggested by John free the record, the BPF code is already doing just that. Reported-by: syzbot+df0d4ec12332661dd1f9@syzkaller.appspotmail.com Fixes: d3b18ad31f93 (""tls: add bpf support to sk_msg handling"") Signed-off-by: Jakub Kicinski Reviewed-by: Simon Horman Acked-by: John Fastabend Signed-off-by: David S. Miller ","net/tls/tls_sw.c | 10 ++++++++--; 1 file changed, 8 insertions(+), 2 deletions(-)","The commit fixes a bug in net/tls by freeing the record on encryption error to prevent re-submission issues.","tls, encryption, error","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.","It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.","[""It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.""]" +"c329ef9684de9517d82af5b4758c9e1b64a8a11a","c329ef9684de9517d82af5b4758c9e1b64a8a11a","Jakub Kicinski","jakub.kicinski@netronome.com","1574885799","David S. Miller","davem@davemloft.net","1575009629","a4f623037c5505b26a1a70e01786352308b6a5cd","81b6b96475ac7a4ebfceae9f16fb3758327adbfe","net/tls: take into account that bpf_exec_tx_verdict() may free the record bpf_exec_tx_verdict() may free the record if tls_push_record() fails, or if the entire record got consumed by BPF. Re-check ctx->open_rec before touching the data. Fixes: d3b18ad31f93 (""tls: add bpf support to sk_msg handling"") Signed-off-by: Jakub Kicinski Reviewed-by: Simon Horman Acked-by: John Fastabend Signed-off-by: David S. Miller ","net/tls/tls_sw.c | 13 ++++++++-----; 1 file changed, 8 insertions(+), 5 deletions(-)","Fixes a bug in bpf_exec_tx_verdict() within the net/tls subsystem that frees records incorrectly.","bpf,tx_verdict,net/tls","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime."", ""I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear.""]" +"e680a41fcaf07ccac8817c589fc4824988b48eac","e680a41fcaf07ccac8817c589fc4824988b48eac","Ingo Molnar","mingo@kernel.org","1575006965","Ingo Molnar","mingo@kernel.org","1575006965","8993cdfbd30e3d95162c53bc6af4e410360f99a8","405b45376de90b3027aaf8c4de035c6bb721fa7e 5172672da02e483d9b3c4d814c3482d0c8ffb1a6","Merge tag 'perf-core-for-mingo-5.5-20191128' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent Pull perf/core improvements and fixes from Arnaldo Carvalho de Melo: perf script: Adrian Hunter: - Fix brstackinsn for AUXTRACE. - Fix invalid LBR/binary mismatch error. perf diff: Arnaldo Carvalho de Melo: - Use llabs() with 64-bit values, fixing the build in some 32-bit architectures. perf pmu: Andi Kleen: - Use file system cache to optimize sysfs access. x86: Adrian Hunter: - Add some more Intel instructions to the opcode map and to the perf test entry: gf2p8affineinvqb, gf2p8affineqb, gf2p8mulb, v4fmaddps, v4fmaddss, v4fnmaddps, v4fnmaddss, vaesdec, vaesdeclast, vaesenc, vaesenclast, vcvtne2ps2bf16, vcvtneps2bf16, vdpbf16ps, vgf2p8affineinvqb, vgf2p8affineqb, vgf2p8mulb, vp2intersectd, vp2intersectq, vp4dpwssd, vp4dpwssds, vpclmulqdq, vpcompressb, vpcompressw, vpdpbusd, vpdpbusds, vpdpwssd, vpdpwssds, vpexpandb, vpexpandw, vpopcntb, vpopcntd, vpopcntq, vpopcntw, vpshldd, vpshldq, vpshldvd, vpshldvq, vpshldvw, vpshldw, vpshrdd, vpshrdq, vpshrdvd, vpshrdvq, vpshrdvw, vpshrdw, vpshufbitqmb. perf affinity: Andi Kleen: - Add infrastructure to save/restore affinity perf maps: Arnaldo Carvalho de Melo: - Merge 'struct maps' with 'struct map_groups', as there is a 1x1 relationship, simplifying code overal. perf build: Jiri Olsa: - Allow to link with libbpf dynamicaly. Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Ingo Molnar ","","The commit merges performance-related improvements and fixes from the perf/core branch into perf/urgent.","perf,improvements,fixes","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"ce27709b8162e5c501bc54292b8bf6bdecc4bbd4","ce27709b8162e5c501bc54292b8bf6bdecc4bbd4","Alexei Starovoitov","ast@kernel.org","1574915708","Daniel Borkmann","daniel@iogearbox.net","1574985822","f57422083563c11598d5452c46c1f3110e816c6f","7c3977d1e80401b1a25efded698b05d60ee26e31","bpf: Fix build in minimal configurations Some kconfigs can have BPF enabled without a single valid program type. In such configurations the build will fail with: ./kernel/bpf/btf.c:3466:1: error: empty enum is invalid Fix it by adding unused value to the enum. Reported-by: Randy Dunlap Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: Randy Dunlap # build-tested Link: https://lore.kernel.org/bpf/20191128043508.2346723-1-ast@kernel.org","kernel/bpf/btf.c | 1 +; 1 file changed, 1 insertion(+)","Fixes build issues in minimal configurations by adding an unused value to an enum in the BPF subsystem.","build, enum, BPF","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"7c3977d1e80401b1a25efded698b05d60ee26e31","7c3977d1e80401b1a25efded698b05d60ee26e31","Alexei Starovoitov","ast@kernel.org","1574905616","Alexei Starovoitov","ast@kernel.org","1574905616","e523f6bbe5bca61548f4feec747ee854f7a13209","1fd450f99272791df8ea8e1b0f5657678e118e90","libbpf: Fix sym->st_value print on 32-bit arches The st_value field is a 64-bit value and causing this error on 32-bit arches: In file included from libbpf.c:52: libbpf.c: In function 'bpf_program__record_reloc': libbpf_internal.h:59:22: error: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'Elf64_Addr' {aka 'const long long unsigned int'} [-Werror=format=] Fix it with (__u64) cast. Fixes: 1f8e2bcb2cd5 (""libbpf: Refactor relocation handling"") Reported-by: Arnaldo Carvalho de Melo Signed-off-by: Alexei Starovoitov ","tools/lib/bpf/libbpf.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","Fix formatting error for the st_value field in libbpf on 32-bit architectures by casting to __u64.","libbpf, 32-bit, fix","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"1fd450f99272791df8ea8e1b0f5657678e118e90","1fd450f99272791df8ea8e1b0f5657678e118e90","Arnaldo Carvalho de Melo","arnaldo.melo@gmail.com","1574781045","Alexei Starovoitov","ast@kernel.org","1574902351","eaea18ad685f1d3e62075f9d19b3c7da7eb7424f","53f8dd434b6fe666b1c4e0be80a8727e8fa9839f","libbpf: Fix up generation of bpf_helper_defs.h $ make -C tools/perf build-test does, ends up with these two problems: make[3]: *** No rule to make target '/tmp/tmp.zq13cHILGB/perf-5.3.0/include/uapi/linux/bpf.h', needed by 'bpf_helper_defs.h'. Stop. make[3]: *** Waiting for unfinished jobs.... make[2]: *** [Makefile.perf:757: /tmp/tmp.zq13cHILGB/perf-5.3.0/tools/lib/bpf/libbpf.a] Error 2 make[2]: *** Waiting for unfinished jobs.... Because $(srcdir) points to the /tmp/tmp.zq13cHILGB/perf-5.3.0 directory and we need '/tools/ after that variable, and after fixing this then we get to another problem: /bin/sh: /home/acme/git/perf/tools/scripts/bpf_helpers_doc.py: No such file or directory make[3]: *** [Makefile:184: bpf_helper_defs.h] Error 127 make[3]: *** Deleting file 'bpf_helper_defs.h' LD /tmp/build/perf/libapi-in.o make[2]: *** [Makefile.perf:778: /tmp/build/perf/libbpf.a] Error 2 make[2]: *** Waiting for unfinished jobs.... Because this requires something outside the tools/ directories that gets collected into perf's detached tarballs, to fix it just add it to tools/perf/MANIFEST, which this patch does, now it works for that case and also for all these other cases. Fixes: e01a75c15969 (""libbpf: Move bpf_{helpers, helper_defs, endian, tracing}.h into libbpf"") Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Alexei Starovoitov Cc: Adrian Hunter Cc: Alexei Starovoitov Cc: Andrii Nakryiko Cc: Daniel Borkmann Cc: Jiri Olsa Cc: Martin KaFai Lau Cc: Namhyung Kim Link: https://lkml.kernel.org/n/tip-4pnkg2vmdvq5u6eivc887wen@git.kernel.org Link: https://lore.kernel.org/bpf/20191126151045.GB19483@kernel.org","tools/lib/bpf/Makefile | 4 ++--; tools/perf/MANIFEST | 1 +; 2 files changed, 3 insertions(+), 2 deletions(-)","The commit resolves build issues for bpf_helper_defs.h by updating the libbpf Makefile and tools/perf MANIFEST.","libbpf,Makefile,MANIFEST","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"53f8dd434b6fe666b1c4e0be80a8727e8fa9839f","53f8dd434b6fe666b1c4e0be80a8727e8fa9839f","Andrii Nakryiko","andriin@fb.com","1574885210","Alexei Starovoitov","ast@kernel.org","1574901261","be37020c2c607328241889de5890eb1ed460a2d7","b568405856906ee4d9ba6284fd36f2928653a623","libbpf: Fix global variable relocation Similarly to a0d7da26ce86 (""libbpf: Fix call relocation offset calculation bug""), relocations against global variables need to take into account referenced symbol's st_value, which holds offset into a corresponding data section (and, subsequently, offset into internal backing map). For static variables this offset is always zero and data offset is completely described by respective instruction's imm field. Convert a bunch of selftests to global variables. Previously they were relying on `static volatile` trick to ensure Clang doesn't inline static variables, which with global variables is not necessary anymore. Fixes: 393cdfbee809 (""libbpf: Support initialized global variables"") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20191127200651.1381348-1-andriin@fb.com","tools/lib/bpf/libbpf.c | 43 ++++++++++-------------; tools/testing/selftests/bpf/progs/fentry_test.c | 12 +++----; tools/testing/selftests/bpf/progs/fexit_bpf2bpf.c | 6 ++--; tools/testing/selftests/bpf/progs/fexit_test.c | 12 +++----; tools/testing/selftests/bpf/progs/test_mmap.c | 4 +--; 5 files changed, 36 insertions(+), 41 deletions(-)","This commit fixes global variable relocation in libbpf and updates selftests accordingly.","libbpf,relocation,variables","A bug fix. It primarily resolves a bug or issue in the code.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"b568405856906ee4d9ba6284fd36f2928653a623","b568405856906ee4d9ba6284fd36f2928653a623","Andrii Nakryiko","andriin@fb.com","1574884894","Daniel Borkmann","daniel@iogearbox.net","1574890142","1ee672ed73457fef7a73fc26c812ad34a1c6f2a0","da5fb18225b49b97bb37c51bcbbb2990a507c364","libbpf: Fix Makefile' libbpf symbol mismatch diagnostic Fix Makefile's diagnostic diff output when there is LIBBPF_API-versioned symbols mismatch. Fixes: 1bd63524593b (""libbpf: handle symbol versioning properly for libbpf.a"") Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20191127200134.1360660-1-andriin@fb.com","tools/lib/bpf/Makefile | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","Fixes diagnostic output in Makefile for libbpf symbol version mismatches.","libbpf,Makefile,diagnostic","A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"da5fb18225b49b97bb37c51bcbbb2990a507c364","da5fb18225b49b97bb37c51bcbbb2990a507c364","Stanislav Fomichev","sdf@google.com","1574871250","Alexei Starovoitov","ast@kernel.org","1574881902","2d8c17dcb803aee714dd523ceacea53824021fdb","d0f010434124598988ba1c97fbb0e4e820ff5d8c","bpf: Support pre-2.25-binutils objcopy for vmlinux BTF If vmlinux BTF generation fails, but CONFIG_DEBUG_INFO_BTF is set, .BTF section of vmlinux is empty and kernel will prohibit BPF loading and return ""in-kernel BTF is malformed"". --dump-section argument to binutils' objcopy was added in version 2.25. When using pre-2.25 binutils, BTF generation silently fails. Convert to --only-section which is present on pre-2.25 binutils. Documentation/process/changes.rst states that binutils 2.21+ is supported, not sure those standards apply to BPF subsystem. v2: * exit and print an error if gen_btf fails (John Fastabend) v3: * resend with Andrii's Acked-by/Tested-by tags Fixes: 341dfcf8d78ea (""btf: expose BTF info through sysfs"") Signed-off-by: Stanislav Fomichev Signed-off-by: Alexei Starovoitov Tested-by: Andrii Nakryiko Acked-by: Andrii Nakryiko Cc: John Fastabend Link: https://lore.kernel.org/bpf/20191127161410.57327-1-sdf@google.com","scripts/link-vmlinux.sh | 7 ++++++-; 1 file changed, 6 insertions(+), 1 deletion(-)","The commit adjusts vmlinux BTF generation for compatibility with older binutils by switching to --only-section.","BTF,objcopy,binutils","A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"d0f010434124598988ba1c97fbb0e4e820ff5d8c","d0f010434124598988ba1c97fbb0e4e820ff5d8c","Alexei Starovoitov","ast@kernel.org","1574809266","Daniel Borkmann","daniel@iogearbox.net","1574813087","89d190812932b184d17d6848bf24635dea2680c9","a95069ecb7092d03b2ea1c39ee04514fe9627540","bpf: Fix static checker warning kernel/bpf/btf.c:4023 btf_distill_func_proto() error: potentially dereferencing uninitialized 't'. kernel/bpf/btf.c 4012 nargs = btf_type_vlen(func); 4013 if (nargs >= MAX_BPF_FUNC_ARGS) { 4014 bpf_log(log, 4015 ""The function %s has %d arguments. Too many.\n"", 4016 tname, nargs); 4017 return -EINVAL; 4018 } 4019 ret = __get_type_size(btf, func->type, &t); ^^ t isn't initialized for the first -EINVAL return This is unlikely path, since BTF should have been validated at this point. Fix it by returning 'void' BTF. Reported-by: Dan Carpenter Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191126230106.237179-1-ast@kernel.org","kernel/bpf/btf.c | 4 +++-; 1 file changed, 3 insertions(+), 1 deletion(-)","Fix a static checker warning by initializing 't' in the btf_distill_func_proto function in bpf subsystem.","static,checker,warning","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.","BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"1ae78780eda54023a0fb49ee743dbba39da148e0","1ae78780eda54023a0fb49ee743dbba39da148e0","Linus Torvalds","torvalds@linux-foundation.org","1574811763","Linus Torvalds","torvalds@linux-foundation.org","1574811763","615313e65083cc30aca62cba3c717331f53002a6","77a05940eee7e9891cd6add7a690a3e762ee21b0 43e0ae7ae0f567a3f8c10ec7a4078bc482660921","Merge branch 'core-rcu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull RCU updates from Ingo Molnar: ""The main changes in this cycle were: - Dynamic tick (nohz) updates, perhaps most notably changes to force the tick on when needed due to lengthy in-kernel execution on CPUs on which RCU is waiting. - Linux-kernel memory consistency model updates. - Replace rcu_swap_protected() with rcu_prepace_pointer(). - Torture-test updates. - Documentation updates. - Miscellaneous fixes"" * 'core-rcu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (51 commits) security/safesetid: Replace rcu_swap_protected() with rcu_replace_pointer() net/sched: Replace rcu_swap_protected() with rcu_replace_pointer() net/netfilter: Replace rcu_swap_protected() with rcu_replace_pointer() net/core: Replace rcu_swap_protected() with rcu_replace_pointer() bpf/cgroup: Replace rcu_swap_protected() with rcu_replace_pointer() fs/afs: Replace rcu_swap_protected() with rcu_replace_pointer() drivers/scsi: Replace rcu_swap_protected() with rcu_replace_pointer() drm/i915: Replace rcu_swap_protected() with rcu_replace_pointer() x86/kvm/pmu: Replace rcu_swap_protected() with rcu_replace_pointer() rcu: Upgrade rcu_swap_protected() to rcu_replace_pointer() rcu: Suppress levelspread uninitialized messages rcu: Fix uninitialized variable in nocb_gp_wait() rcu: Update descriptions for rcu_future_grace_period tracepoint rcu: Update descriptions for rcu_nocb_wake tracepoint rcu: Remove obsolete descriptions for rcu_barrier tracepoint rcu: Ensure that ->rcu_urgent_qs is set before resched IPI workqueue: Convert for_each_wq to use built-in list check rcu: Several rcu_segcblist functions can be static rcu: Remove unused function hlist_bl_del_init_rcu() Documentation: Rename rcu_node_context_switch() to rcu_note_context_switch() ...","","This commit merges RCU updates addressing dynamic tick handling and replacing rcu_swap_protected with rcu_replace_pointer in multiple components.","RCU, merge, pointer","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"7b65e2034fde011d090d4ec472902b71129c6cbd","7b65e2034fde011d090d4ec472902b71129c6cbd","Jiri Olsa","jolsa@kernel.org","1574770373","Arnaldo Carvalho de Melo","acme@redhat.com","1574777865","570e29c12a67d5af3c764f4ffcb196f23f7aa32e","a5732681e0e6ea0c3024f9d23bcf99b9237189ee","perf tools: Allow to link with libbpf dynamicaly Currently we support only static linking with kernel's libbpf (tools/lib/bpf). This patch adds libbpf package detection and support to link perf with it dynamically. The libbpf package status is displayed with: $ make VF=1 Auto-detecting system features: ... ... libbpf: [ on ] It's not checked by default, because it's quite new. Once it's on most distros we can switch it on. For the same reason it's not added to the test-all check. Perf does not need advanced version of libbpf, so we can check just for the base bpf_object__open function. Adding new compile variable to detect libbpf package and link bpf dynamically: $ make LIBBPF_DYNAMIC=1 ... LINK perf $ ldd perf | grep bpf libbpf.so.0 => /lib64/libbpf.so.0 (0x00007f46818bc000) If libbpf is not installed, build stops with: Makefile.config:486: *** Error: No libbpf devel library found,\ please install libbpf-devel. Stop. Committer testing: $ make LIBBPF_DYNAMIC=1 -C tools/perf O=/tmp/build/perf make: Entering directory '/home/acme/git/perf/tools/perf' BUILD: Doing 'make -j8' parallel build Makefile.config:493: *** Error: No libbpf devel library found, please install libbpf-devel. Stop. make[1]: *** [Makefile.perf:225: sub-make] Error 2 make: *** [Makefile:70: all] Error 2 make: Leaving directory '/home/acme/git/perf/tools/perf' $ Signed-off-by: Jiri Olsa Tested-by: Arnaldo Carvalho de Melo Cc: Toke Høiland-Jørgensen Cc: Alexander Shishkin Cc: Alexei Starovoitov Cc: Andrii Nakryiko Cc: Daniel Borkmann Cc: Jesper Dangaard Brouer Cc: Martin KaFai Lau Cc: Michael Petlan Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Song Liu Cc: Yonghong Song Cc: bpf@vger.kernel.org Cc: netdev@vger.kernel.org Link: http://lore.kernel.org/lkml/20191126121253.28253-1-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo ","tools/build/Makefile.feature | 3 ++-; tools/build/feature/Makefile | 4 ++++; tools/build/feature/test-libbpf.c | 7 +++++++; tools/perf/Makefile.config | 10 ++++++++++; tools/perf/Makefile.perf | 6 +++++-; 5 files changed, 28 insertions(+), 2 deletions(-)","This commit enables dynamic linking with libbpf in perf tools by adding package detection and support for it during build.","dynamic, libbpf, linking","A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"386403a115f95997c2715691226e11a7b5cffcfd","386403a115f95997c2715691226e11a7b5cffcfd","Linus Torvalds","torvalds@linux-foundation.org","1574740977","Linus Torvalds","torvalds@linux-foundation.org","1574740977","a685df70bd3d5b295683713818ddf0752c3d75b6","642356cb5f4a8c82b5ca5ebac288c327d10df236 622dc5ad8052f4f0c6b7a12787696a5caa3c6a58","Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next Pull networking updates from David Miller: ""Another merge window, another pull full of stuff: 1) Support alternative names for network devices, from Jiri Pirko. 2) Introduce per-netns netdev notifiers, also from Jiri Pirko. 3) Support MSG_PEEK in vsock/virtio, from Matias Ezequiel Vara Larsen. 4) Allow compiling out the TLS TOE code, from Jakub Kicinski. 5) Add several new tracepoints to the kTLS code, also from Jakub. 6) Support set channels ethtool callback in ena driver, from Sameeh Jubran. 7) New SCTP events SCTP_ADDR_ADDED, SCTP_ADDR_REMOVED, SCTP_ADDR_MADE_PRIM, and SCTP_SEND_FAILED_EVENT. From Xin Long. 8) Add XDP support to mvneta driver, from Lorenzo Bianconi. 9) Lots of netfilter hw offload fixes, cleanups and enhancements, from Pablo Neira Ayuso. 10) PTP support for aquantia chips, from Egor Pomozov. 11) Add UDP segmentation offload support to igb, ixgbe, and i40e. From Josh Hunt. 12) Add smart nagle to tipc, from Jon Maloy. 13) Support L2 field rewrite by TC offloads in bnxt_en, from Venkat Duvvuru. 14) Add a flow mask cache to OVS, from Tonghao Zhang. 15) Add XDP support to ice driver, from Maciej Fijalkowski. 16) Add AF_XDP support to ice driver, from Krzysztof Kazimierczak. 17) Support UDP GSO offload in atlantic driver, from Igor Russkikh. 18) Support it in stmmac driver too, from Jose Abreu. 19) Support TIPC encryption and auth, from Tuong Lien. 20) Introduce BPF trampolines, from Alexei Starovoitov. 21) Make page_pool API more numa friendly, from Saeed Mahameed. 22) Introduce route hints to ipv4 and ipv6, from Paolo Abeni. 23) Add UDP segmentation offload to cxgb4, Rahul Lakkireddy"" * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next: (1857 commits) libbpf: Fix usage of u32 in userspace code mm: Implement no-MMU variant of vmalloc_user_node_flags slip: Fix use-after-free Read in slip_open net: dsa: sja1105: fix sja1105_parse_rgmii_delays() macvlan: schedule bc_work even if error enetc: add support Credit Based Shaper(CBS) for hardware offload net: phy: add helpers phy_(un)lock_mdio_bus mdio_bus: don't use managed reset-controller ax88179_178a: add ethtool_op_get_ts_info() mlxsw: spectrum_router: Fix use of uninitialized adjacency index mlxsw: spectrum_router: After underlay moves, demote conflicting tunnels bpf: Simplify __bpf_arch_text_poke poke type handling bpf: Introduce BPF_TRACE_x helper for the tracing tests bpf: Add bpf_jit_blinding_enabled for !CONFIG_BPF_JIT bpf, testing: Add various tail call test cases bpf, x86: Emit patchable direct jump as tail call bpf: Constant map key tracking for prog array pokes bpf: Add poke dependency tracking for prog array maps bpf: Add initial poke descriptor table for jit images bpf: Move owner type, jited info into array auxiliary data ...","","Merge networking updates with features like XDP, SCTP, and BPF trampolines affecting various networking components and drivers.","networking, merge, updates","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"622dc5ad8052f4f0c6b7a12787696a5caa3c6a58","622dc5ad8052f4f0c6b7a12787696a5caa3c6a58","David S. Miller","davem@davemloft.net","1574725618","David S. Miller","davem@davemloft.net","1574725618","d869a2aefe3deed534a4bfc35073e93e6d0e2047","adf6f8cb3f4c2a15d5f35e6cf9ffeb6856d35312 b615e5a1e067dcb327482d1af7463268b89b1629","Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next Daniel Borkmann says: ==================== pull-request: bpf-next 2019-11-26 The following pull-request contains BPF updates for your *net-next* tree. We've added 2 non-merge commits during the last 1 day(s) which contain a total of 2 files changed, 14 insertions(+), 3 deletions(-). The main changes, 2 small fixes are: 1) Fix libbpf out of tree compilation which complained about unknown u32 type used in libbpf_find_vmlinux_btf_id() which needs to be __u32 instead, from Andrii Nakryiko. 2) Follow-up fix for the prior BPF mmap series where kbuild bot complained about missing vmalloc_user_node_flags() for no-MMU, also from Andrii Nakryiko. ==================== Signed-off-by: David S. Miller ","","Merge commit updating BPF subsystem with two small bug fixes from bpf-next branch.","merge, fixes, bpf","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"b615e5a1e067dcb327482d1af7463268b89b1629","b615e5a1e067dcb327482d1af7463268b89b1629","Andrii Nakryiko","andriin@fb.com","1574717388","Alexei Starovoitov","ast@kernel.org","1574718721","d65b338b4596fb800599d5876aed7868c9df18da","ed81745a4c96841937f1da35c0eb66ac312e1480","libbpf: Fix usage of u32 in userspace code u32 is not defined for libbpf when compiled outside of kernel sources (e.g., in Github projection). Use __u32 instead. Fixes: b8c54ea455dc (""libbpf: Add support to attach to fentry/fexit tracing progs"") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191125212948.1163343-1-andriin@fb.com","tools/lib/bpf/libbpf.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","The commit fixes the usage of u32 in libbpf userspace code by replacing it with __u32.","libbpf, u32, fix","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"ed81745a4c96841937f1da35c0eb66ac312e1480","ed81745a4c96841937f1da35c0eb66ac312e1480","Andrii Nakryiko","andriin@fb.com","1574546915","Alexei Starovoitov","ast@kernel.org","1574718599","f17dbf8a881bb81cde966507c7c62f9385308b5a","c431047c4efe7903fb1c5a23e0f3f8eb1efc89f9","mm: Implement no-MMU variant of vmalloc_user_node_flags To fix build with !CONFIG_MMU, implement it for no-MMU configurations as well. Fixes: fc9702273e2e (""bpf: Add mmap() support for BPF_MAP_TYPE_ARRAY"") Reported-by: kbuild test robot Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Johannes Weiner Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20191123220835.1237773-1-andriin@fb.com","mm/nommu.c | 15 +++++++++++++--; 1 file changed, 13 insertions(+), 2 deletions(-)","This commit implements a no-MMU variant of vmalloc_user_node_flags to fix a build issue.","no-MMU,build fix,vmalloc","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.","It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.","[""It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.""]" +"4eb47198e955fc01d14113f525b62a4bc95554c7","4eb47198e955fc01d14113f525b62a4bc95554c7","David S. Miller","davem@davemloft.net","1574661947","David S. Miller","davem@davemloft.net","1574661947","1a3ed7a7ad916ca878d130491241123f76e50ac9","5f04ed74a8a3bcb2122738b7eda857187e85aa34 b553a6ec570044fc1ae300c6fb24f9ce204c5894","Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next Alexei Starovoitov says: ==================== pull-request: bpf-next 2019-11-24 The following pull-request contains BPF updates for your *net-next* tree. We've added 27 non-merge commits during the last 4 day(s) which contain a total of 50 files changed, 2031 insertions(+), 548 deletions(-). The main changes are: 1) Optimize bpf_tail_call() from retpoline-ed indirect jump to direct jump, from Daniel. 2) Support global variables in libbpf, from Andrii. 3) Cleanup selftests with BPF_TRACE_x() macro, from Martin. 4) Fix devmap hash, from Toke. 5) Fix register bounds after 32-bit conditional jumps, from Yonghong. ==================== Signed-off-by: David S. Miller ","","The commit merges BPF-next updates including optimizations, support for global variables, and fixes in devmap hash and register bounds handling.","BPF, merge, updates","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"b553a6ec570044fc1ae300c6fb24f9ce204c5894","b553a6ec570044fc1ae300c6fb24f9ce204c5894","Daniel Borkmann","daniel@iogearbox.net","1574555982","Alexei Starovoitov","ast@kernel.org","1574644331","6121de7c1e38050fd9d4d46480ae6fddf9d585b2","f9a7cf6eb17cd0110c8c47d9e7969fc2716e5772","bpf: Simplify __bpf_arch_text_poke poke type handling Given that we have BPF_MOD_NOP_TO_{CALL,JUMP}, BPF_MOD_{CALL,JUMP}_TO_NOP and BPF_MOD_{CALL,JUMP}_TO_{CALL,JUMP} poke types and that we also pass in old_addr as well as new_addr, it's a bit redundant and unnecessarily complicates __bpf_arch_text_poke() itself since we can derive the same from the *_addr that were passed in. Hence simplify and use BPF_MOD_{CALL,JUMP} as types which also allows to clean up call-sites. In addition to that, __bpf_arch_text_poke() currently verifies that text matches expected old_insn before we invoke text_poke_bp(). Also add a check on new_insn and skip rewrite if it already matches. Reason why this is rather useful is that it avoids making any special casing in prog_array_map_poke_run() when old and new prog were NULL and has the benefit that also for this case we perform a check on text whether it really matches our expectations. Suggested-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/fcb00a2b0b288d6c73de4ef58116a821c8fe8f2f.1574555798.git.daniel@iogearbox.net","arch/x86/net/bpf_jit_comp.c | 85 +++++++++++++--------------------------------; include/linux/bpf.h | 10 ++----; kernel/bpf/arraymap.c | 12 +------; kernel/bpf/trampoline.c | 8 ++---; 4 files changed, 32 insertions(+), 83 deletions(-)","The commit simplifies BPF architecture text poke function by consolidating poke type handling and adding instruction checks, enhancing efficiency and maintainability.","BPF,simplify,poke","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"f9a7cf6eb17cd0110c8c47d9e7969fc2716e5772","f9a7cf6eb17cd0110c8c47d9e7969fc2716e5772","Martin KaFai Lau","kafai@fb.com","1574540704","Alexei Starovoitov","ast@kernel.org","1574644331","9db74c8c6aaa198f2d163d066abe228f24bb22d5","b8cd76ca4ae34731d47cd6a876d912a08efcc240","bpf: Introduce BPF_TRACE_x helper for the tracing tests For BPF_PROG_TYPE_TRACING, the bpf_prog's ctx is an array of u64. This patch borrows the idea from BPF_CALL_x in filter.h to convert a u64 to the arg type of the traced function. The new BPF_TRACE_x has an arg to specify the return type of a bpf_prog. It will be used in the future TCP-ops bpf_prog that may return ""void"". The new macros are defined in the new header file ""bpf_trace_helpers.h"". It is under selftests/bpf/ for now. It could be moved to libbpf later after seeing more upcoming non-tracing use cases. The tests are changed to use these new macros also. Hence, the k[s]u8/16/32/64 are no longer needed and they are removed from the bpf_helpers.h. Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191123202504.1502696-1-kafai@fb.com","tools/lib/bpf/bpf_helpers.h | 13 ----; tools/testing/selftests/bpf/bpf_trace_helpers.h | 58 ++++++++++++++++; tools/testing/selftests/bpf/progs/fentry_test.c | 72 +++++---------------; tools/testing/selftests/bpf/progs/fexit_bpf2bpf.c | 27 +++-----; tools/testing/selftests/bpf/progs/fexit_test.c | 83 ++++++-----------------; tools/testing/selftests/bpf/progs/kfree_skb.c | 43 ++++--------; tools/testing/selftests/bpf/progs/test_overhead.c | 16 ++---; 7 files changed, 125 insertions(+), 187 deletions(-)","Introduced BPF_TRACE_x helper macros for tracing tests and adjusted tests to use them, removing unnecessary helpers.","BPF_TRACE_x,tracing,macros","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.']" +"b8cd76ca4ae34731d47cd6a876d912a08efcc240","b8cd76ca4ae34731d47cd6a876d912a08efcc240","Daniel Borkmann","daniel@iogearbox.net","1574541451","Alexei Starovoitov","ast@kernel.org","1574644288","be1fc17c4f8926794876b62e927b5c78b5d9c117","6dbae03b2e851fe58e9d9d1ac9ed58017b07960c","bpf: Add bpf_jit_blinding_enabled for !CONFIG_BPF_JIT Add a definition of bpf_jit_blinding_enabled() when CONFIG_BPF_JIT is not set in order to fix a recent build regression: [...] CC kernel/bpf/verifier.o CC kernel/bpf/inode.o kernel/bpf/verifier.c: In function ‘fixup_bpf_calls’: kernel/bpf/verifier.c:9132:25: error: implicit declaration of function ‘bpf_jit_blinding_enabled’; did you mean ‘bpf_jit_kallsyms_enabled’? [-Werror=implicit-function-declaration] 9132 | bool expect_blinding = bpf_jit_blinding_enabled(prog); | ^~~~~~~~~~~~~~~~~~~~~~~~ | bpf_jit_kallsyms_enabled CC kernel/bpf/helpers.o CC kernel/bpf/hashtab.o [...] Fixes: d2e4c1e6c294 (""bpf: Constant map key tracking for prog array pokes"") Reported-by: Jakub Sitnicki Reported-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/40baf8f3507cac4851a310578edfb98ce73b5605.1574541375.git.daniel@iogearbox.net","include/linux/filter.h | 5 +++++; 1 file changed, 5 insertions(+)","This commit adds bpf_jit_blinding_enabled definition to address a build error without CONFIG_BPF_JIT.","bpf jit regression","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"6dbae03b2e851fe58e9d9d1ac9ed58017b07960c","6dbae03b2e851fe58e9d9d1ac9ed58017b07960c","Alexei Starovoitov","ast@kernel.org","1574474564","Alexei Starovoitov","ast@kernel.org","1574643852","690f7ab7802bc6fc215043adfe112fa867fb4e1f","c4781e37c6a22c39cb4a57411d14f42aca124f04 79d49ba048ecace59a9850e8a04b618d7848b8e7","Merge branch 'optimize-bpf_tail_call' Daniel Borkmann says: ==================== This gets rid of indirect jumps for BPF tail calls whenever possible. The series adds emission for *direct* jumps for tail call maps in order to avoid the retpoline overhead from a493a87f38cf (""bpf, x64: implement retpoline for tail call"") for situations that allow for it, meaning, for known constant keys at verification time which are used as index into the tail call map. See patch 7/8 for more general details. Thanks! v1 -> v2: - added more test cases - u8 ip_stable -> bool (Andrii) - removed bpf_map_poke_{un,}lock and simplified the code (Andrii) - added break into prog_array_map_poke_untrack since there's just one prog (Andrii) - fixed typo: for for in commit msg (Andrii) - reworked __bpf_arch_text_poke (Andrii) - added subtests, and comment on tests themselves, NULL-NULL transistion (Andrii) - in constant map key tracking I've moved the map_poke_track callback to once we've finished creating the poke tab as otherwise concurrent access from tail call map would blow up (since we realloc the table) rfc -> v1: - Applied Alexei's and Andrii's feeback from https://lore.kernel.org/bpf/cover.1573779287.git.daniel@iogearbox.net/T/#t ==================== Signed-off-by: Alexei Starovoitov ","","This commit merges optimizations for BPF tail calls by incorporating direct jumps to reduce retpoline overhead.","BPF tail call, direct jumps, optimization","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"79d49ba048ecace59a9850e8a04b618d7848b8e7","79d49ba048ecace59a9850e8a04b618d7848b8e7","Daniel Borkmann","daniel@iogearbox.net","1574453281","Alexei Starovoitov","ast@kernel.org","1574643852","690f7ab7802bc6fc215043adfe112fa867fb4e1f","428d5df1fa4f28daf622c48dd19da35585c9053c","bpf, testing: Add various tail call test cases Add several BPF kselftest cases for tail calls which test the various patch directions, and that multiple locations are patched in same and different programs. # ./test_progs -n 45 #45/1 tailcall_1:OK #45/2 tailcall_2:OK #45/3 tailcall_3:OK #45/4 tailcall_4:OK #45/5 tailcall_5:OK #45 tailcalls:OK Summary: 1/5 PASSED, 0 SKIPPED, 0 FAILED I've also verified the JITed dump after each of the rewrite cases that it matches expectations. Also regular test_verifier suite passes fine which contains further tail call tests: # ./test_verifier [...] Summary: 1563 PASSED, 0 SKIPPED, 0 FAILED Checked under JIT, interpreter and JIT + hardening. Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/3d6cbecbeb171117dccfe153306e479798fb608d.1574452833.git.daniel@iogearbox.net","tools/testing/selftests/bpf/prog_tests/tailcalls.c | 487 +++++++++++++++++++++; tools/testing/selftests/bpf/progs/tailcall1.c | 48 ++; tools/testing/selftests/bpf/progs/tailcall2.c | 59 +++; tools/testing/selftests/bpf/progs/tailcall3.c | 31 ++; tools/testing/selftests/bpf/progs/tailcall4.c | 33 ++; tools/testing/selftests/bpf/progs/tailcall5.c | 40 ++; 6 files changed, 698 insertions(+)","Add new eBPF selftest cases for tail calls to verify patch directions and multi-location patching.","selftest,tailcalls,JIT","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"428d5df1fa4f28daf622c48dd19da35585c9053c","428d5df1fa4f28daf622c48dd19da35585c9053c","Daniel Borkmann","daniel@iogearbox.net","1574453280","Alexei Starovoitov","ast@kernel.org","1574643851","1afc34a28e187bb3204bcddcb12a941cb8e6e181","d2e4c1e6c2947269346054ac8937ccfe9e0bcc6b","bpf, x86: Emit patchable direct jump as tail call Add initial code emission for *direct* jumps for tail call maps in order to avoid the retpoline overhead from a493a87f38cf (""bpf, x64: implement retpoline for tail call"") for situations that allow for it, meaning, for known constant keys at verification time which are used as index into the tail call map. In case of Cilium which makes heavy use of tail calls, constant keys are used in the vast majority, only for a single occurrence we use a dynamic key. High level outline is that if the target prog is NULL in the map, we emit a 5-byte nop for the fall-through case and if not, we emit a 5-byte direct relative jmp to the target bpf_func + skipped prologue offset. Later during runtime, we patch these 5-byte nop/jmps upon tail call map update or deletions dynamically. Note that on x86-64 the direct jmp works as we reuse the same stack frame and skip prologue (as opposed to some other JIT implementations). One of the issues is that the tail call map slots can change at any given time even during JITing. Therefore, we have two passes: i) emit nops for all patchable locations during main JITing phase until we declare prog->jited = 1 eventually. At this point the image is stable, not public yet and with all jmps disabled. While JITing, we collect additional info like poke->ip in order to remember the patch location for later modifications. In ii) bpf_tail_call_direct_fixup() walks over the progs poke_tab, locks the tail call maps poke_mutex to prevent from parallel updates and patches in the right locations via __bpf_arch_text_poke(). Note, the main bpf_arch_text_poke() cannot be used at this point since we're not yet exposed to kallsyms. For the update we use plain memcpy() since the image is not public and still in read-write mode. After patching, we activate that poke entry through poke->ip_stable. Meaning, at this point any tail call map updates/deletions are not going to ignore that poke entry anymore. Then, bpf_arch_text_poke() might still occur on the read-write image until we finally locked it as read-only. Both modifications on the given image are under text_mutex to avoid interference with each other when update requests come in in parallel for different tail call maps (current one we have locked in JIT and different one where poke->ip_stable was already set). Example prog: # ./bpftool p d x i 1655 0: (b7) r3 = 0 1: (18) r2 = map[id:526] 3: (85) call bpf_tail_call#12 4: (b7) r0 = 1 5: (95) exit Before: # ./bpftool p d j i 1655 0xffffffffc076e55c: 0: nopl 0x0(%rax,%rax,1) 5: push %rbp 6: mov %rsp,%rbp 9: sub $0x200,%rsp 10: push %rbx 11: push %r13 13: push %r14 15: push %r15 17: pushq $0x0 _ 19: xor %edx,%edx |_ index (arg 3) 1b: movabs $0xffff88d95cc82600,%rsi |_ map (arg 2) 25: mov %edx,%edx | index >= array->map.max_entries 27: cmp %edx,0x24(%rsi) | 2a: jbe 0x0000000000000066 |_ 2c: mov -0x224(%rbp),%eax | tail call limit check 32: cmp $0x20,%eax | 35: ja 0x0000000000000066 | 37: add $0x1,%eax | 3a: mov %eax,-0x224(%rbp) |_ 40: mov 0xd0(%rsi,%rdx,8),%rax |_ prog = array->ptrs[index] 48: test %rax,%rax | prog == NULL check 4b: je 0x0000000000000066 |_ 4d: mov 0x30(%rax),%rax | goto *(prog->bpf_func + prologue_size) 51: add $0x19,%rax | 55: callq 0x0000000000000061 | retpoline for indirect jump 5a: pause | 5c: lfence | 5f: jmp 0x000000000000005a | 61: mov %rax,(%rsp) | 65: retq |_ 66: mov $0x1,%eax 6b: pop %rbx 6c: pop %r15 6e: pop %r14 70: pop %r13 72: pop %rbx 73: leaveq 74: retq After; state after JIT: # ./bpftool p d j i 1655 0xffffffffc08e8930: 0: nopl 0x0(%rax,%rax,1) 5: push %rbp 6: mov %rsp,%rbp 9: sub $0x200,%rsp 10: push %rbx 11: push %r13 13: push %r14 15: push %r15 17: pushq $0x0 _ 19: xor %edx,%edx |_ index (arg 3) 1b: movabs $0xffff9d8afd74c000,%rsi |_ map (arg 2) 25: mov -0x224(%rbp),%eax | tail call limit check 2b: cmp $0x20,%eax | 2e: ja 0x000000000000003e | 30: add $0x1,%eax | 33: mov %eax,-0x224(%rbp) |_ 39: jmpq 0xfffffffffffd1785 |_ [direct] goto *(prog->bpf_func + prologue_size) 3e: mov $0x1,%eax 43: pop %rbx 44: pop %r15 46: pop %r14 48: pop %r13 4a: pop %rbx 4b: leaveq 4c: retq After; state after map update (target prog): # ./bpftool p d j i 1655 0xffffffffc08e8930: 0: nopl 0x0(%rax,%rax,1) 5: push %rbp 6: mov %rsp,%rbp 9: sub $0x200,%rsp 10: push %rbx 11: push %r13 13: push %r14 15: push %r15 17: pushq $0x0 19: xor %edx,%edx 1b: movabs $0xffff9d8afd74c000,%rsi 25: mov -0x224(%rbp),%eax 2b: cmp $0x20,%eax . 2e: ja 0x000000000000003e . 30: add $0x1,%eax . 33: mov %eax,-0x224(%rbp) |_ 39: jmpq 0xffffffffffb09f55 |_ goto *(prog->bpf_func + prologue_size) 3e: mov $0x1,%eax 43: pop %rbx 44: pop %r15 46: pop %r14 48: pop %r13 4a: pop %rbx 4b: leaveq 4c: retq After; state after map update (no prog): # ./bpftool p d j i 1655 0xffffffffc08e8930: 0: nopl 0x0(%rax,%rax,1) 5: push %rbp 6: mov %rsp,%rbp 9: sub $0x200,%rsp 10: push %rbx 11: push %r13 13: push %r14 15: push %r15 17: pushq $0x0 19: xor %edx,%edx 1b: movabs $0xffff9d8afd74c000,%rsi 25: mov -0x224(%rbp),%eax 2b: cmp $0x20,%eax . 2e: ja 0x000000000000003e . 30: add $0x1,%eax . 33: mov %eax,-0x224(%rbp) |_ 39: nopl 0x0(%rax,%rax,1) |_ fall-through nop 3e: mov $0x1,%eax 43: pop %rbx 44: pop %r15 46: pop %r14 48: pop %r13 4a: pop %rbx 4b: leaveq 4c: retq Nice bonus is that this also shrinks the code emission quite a bit for every tail call invocation. Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/6ada4c1c9d35eeb5f4ecfab94593dafa6b5c4b09.1574452833.git.daniel@iogearbox.net","arch/x86/net/bpf_jit_comp.c | 282 +++++++++++++++++++++++++++++---------------; 1 file changed, 187 insertions(+), 95 deletions(-)","The commit modifies x86 BPF tail call handling to use direct jumps instead of retpolines for performance gains.","x86,JIT,retpoline","A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"d2e4c1e6c2947269346054ac8937ccfe9e0bcc6b","d2e4c1e6c2947269346054ac8937ccfe9e0bcc6b","Daniel Borkmann","daniel@iogearbox.net","1574453279","Alexei Starovoitov","ast@kernel.org","1574643851","0148367a8be1e1d30bb99acff716b5d945bdd4e2","da765a2f599304a81a25e77908d1790414ecdbb6","bpf: Constant map key tracking for prog array pokes Add tracking of constant keys into tail call maps. The signature of bpf_tail_call_proto is that arg1 is ctx, arg2 map pointer and arg3 is a index key. The direct call approach for tail calls can be enabled if the verifier asserted that for all branches leading to the tail call helper invocation, the map pointer and index key were both constant and the same. Tracking of map pointers we already do from prior work via c93552c443eb (""bpf: properly enforce index mask to prevent out-of-bounds speculation"") and 09772d92cd5a (""bpf: avoid retpoline for lookup/update/ delete calls on maps""). Given the tail call map index key is not on stack but directly in the register, we can add similar tracking approach and later in fixup_bpf_calls() add a poke descriptor to the progs poke_tab with the relevant information for the JITing phase. We internally reuse insn->imm for the rewritten BPF_JMP | BPF_TAIL_CALL instruction in order to point into the prog's poke_tab, and keep insn->imm as 0 as indicator that current indirect tail call emission must be used. Note that publishing to the tracker must happen at the end of fixup_bpf_calls() since adding elements to the poke_tab reallocates its memory, so we need to wait until its in final state. Future work can generalize and add similar approach to optimize plain array map lookups. Difference there is that we need to look into the key value that sits on stack. For clarity in bpf_insn_aux_data, map_state has been renamed into map_ptr_state, so we get map_{ptr,key}_state as trackers. Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/e8db37f6b2ae60402fa40216c96738ee9b316c32.1574452833.git.daniel@iogearbox.net","include/linux/bpf_verifier.h | 3 +-; kernel/bpf/verifier.c | 120 +++++++++++++++++++++++++++++++++++++++----; 2 files changed, 113 insertions(+), 10 deletions(-)","This commit adds constant map key tracking to optimize BPF program array tail calls.","constant,map,key","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"da765a2f599304a81a25e77908d1790414ecdbb6","da765a2f599304a81a25e77908d1790414ecdbb6","Daniel Borkmann","daniel@iogearbox.net","1574453278","Alexei Starovoitov","ast@kernel.org","1574643851","73e3edfabd9a026157bfaf4a73764f351be7dcf3","a66886fe6c24ebeeb6dc10fbd9b75158029eacf7","bpf: Add poke dependency tracking for prog array maps This work adds program tracking to prog array maps. This is needed such that upon prog array updates/deletions we can fix up all programs which make use of this tail call map. We add ops->map_poke_{un,}track() helpers to maps to maintain the list of programs and ops->map_poke_run() for triggering the actual update. bpf_array_aux is extended to contain the list head and poke_mutex in order to serialize program patching during updates/deletions. bpf_free_used_maps() will untrack the program shortly before dropping the reference to the map. For clearing out the prog array once all urefs are dropped we need to use schedule_work() to have a sleepable context. The prog_array_map_poke_run() is triggered during updates/deletions and walks the maintained prog list. It checks in their poke_tabs whether the map and key is matching and runs the actual bpf_arch_text_poke() for patching in the nop or new jmp location. Depending on the type of update, we use one of BPF_MOD_{NOP_TO_JUMP,JUMP_TO_NOP,JUMP_TO_JUMP}. Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/1fb364bb3c565b3e415d5ea348f036ff379e779d.1574452833.git.daniel@iogearbox.net","include/linux/bpf.h | 12 ++++; kernel/bpf/arraymap.c | 183 ++++++++++++++++++++++++++++++++++++++++++++++++--; kernel/bpf/core.c | 9 ++-; kernel/bpf/syscall.c | 20 ++++--; 4 files changed, 212 insertions(+), 12 deletions(-)","The commit adds dependency tracking for prog array maps to manage updates and deletions affecting programs.","prog array, dependency tracking, updates","A new feature. It adds a new capability or feature that was not previously present.","Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"a66886fe6c24ebeeb6dc10fbd9b75158029eacf7","a66886fe6c24ebeeb6dc10fbd9b75158029eacf7","Daniel Borkmann","daniel@iogearbox.net","1574453277","Alexei Starovoitov","ast@kernel.org","1574643851","c47b8231030896a840130b56aea3277780e78653","2beee5f57441413b64a9c2bd657e17beabb98d1c","bpf: Add initial poke descriptor table for jit images Add initial poke table data structures and management to the BPF prog that can later be used by JITs. Also add an instance of poke specific data for tail call maps; plan for later work is to extend this also for BPF static keys. Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/1db285ec2ea4207ee0455b3f8e191a4fc58b9ade.1574452833.git.daniel@iogearbox.net","include/linux/bpf.h | 20 ++++++++++++++++++++; include/linux/filter.h | 10 ++++++++++; kernel/bpf/core.c | 34 ++++++++++++++++++++++++++++++++++; 3 files changed, 64 insertions(+)","The commit adds a poke descriptor table for managing JIT images in BPF programs.","poke, descriptor, JIT","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"2beee5f57441413b64a9c2bd657e17beabb98d1c","2beee5f57441413b64a9c2bd657e17beabb98d1c","Daniel Borkmann","daniel@iogearbox.net","1574453276","Alexei Starovoitov","ast@kernel.org","1574643851","8ad85ac286a4c8a435ac2b83204f610b4e8e2cfa","6332be04c039a72fca32ed0a4265bac58d606bb6","bpf: Move owner type, jited info into array auxiliary data We're going to extend this with further information which is only relevant for prog array at this point. Given this info is not used in critical path, move it into its own structure such that the main array map structure can be kept on diet. Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/b9ddccdb0f6f7026489ee955f16c96381e1e7238.1574452833.git.daniel@iogearbox.net","include/linux/bpf.h | 18 +++++++++++-------; kernel/bpf/arraymap.c | 32 ++++++++++++++++++++++++++++++--; kernel/bpf/core.c | 11 +++++------; kernel/bpf/map_in_map.c | 5 ++---; kernel/bpf/syscall.c | 16 ++++++----------; 5 files changed, 54 insertions(+), 28 deletions(-)","The commit optimizes the eBPF array map by moving non-critical data into a separate auxiliary structure.","owner,type,auxiliary","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"6332be04c039a72fca32ed0a4265bac58d606bb6","6332be04c039a72fca32ed0a4265bac58d606bb6","Daniel Borkmann","daniel@iogearbox.net","1574453275","Alexei Starovoitov","ast@kernel.org","1574643824","e6bb35f65a435ed543365e2ad750c3e69cb28e3a","4b3da77b72ad6b3c48c6fe4a395ace7db39a12c5","bpf: Move bpf_free_used_maps into sleepable section We later on are going to need a sleepable context as opposed to plain RCU callback in order to untrack programs we need to poke at runtime and tracking as well as image update is performed under mutex. Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/09823b1d5262876e9b83a8e75df04cf0467357a4.1574452833.git.daniel@iogearbox.net","include/linux/bpf.h | 4 ++++; kernel/bpf/core.c | 23 +++++++++++++++++++++++; kernel/bpf/syscall.c | 20 --------------------; 3 files changed, 27 insertions(+), 20 deletions(-)","This commit moves the bpf_free_used_maps function to a sleepable section for runtime updates under mutex.","bpf_free_used_maps,sleepable,mutex","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"4b3da77b72ad6b3c48c6fe4a395ace7db39a12c5","4b3da77b72ad6b3c48c6fe4a395ace7db39a12c5","Daniel Borkmann","daniel@iogearbox.net","1574453274","Alexei Starovoitov","ast@kernel.org","1574643527","3c65c1076f917574a67c3ee1c4de18364549bebc","c4781e37c6a22c39cb4a57411d14f42aca124f04","bpf, x86: Generalize and extend bpf_arch_text_poke for direct jumps Add BPF_MOD_{NOP_TO_JUMP,JUMP_TO_JUMP,JUMP_TO_NOP} patching for x86 JIT in order to be able to patch direct jumps or nop them out. We need this facility in order to patch tail call jumps and in later work also BPF static keys. Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/aa4784196a8e5e985af4b30a4fe5336bce6e9643.1574452833.git.daniel@iogearbox.net","arch/x86/net/bpf_jit_comp.c | 64 ++++++++++++++++++++++++++++++++-------------; include/linux/bpf.h | 6 +++++; 2 files changed, 52 insertions(+), 18 deletions(-)","Enhance bpf_arch_text_poke to support direct jump and nop patching for x86 JIT tail calls and future BPF static keys.","bpf_arch_text_poke,direct jumps,nop patching","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"c4781e37c6a22c39cb4a57411d14f42aca124f04","c4781e37c6a22c39cb4a57411d14f42aca124f04","Alexei Starovoitov","ast@kernel.org","1574385315","Alexei Starovoitov","ast@kernel.org","1574643526","feeb550fccfecba072ae58bac2ca83fb52964093","161f3cbcda06aa70faed6b703066fedbd7653e23","selftests/bpf: Add BPF trampoline performance test Add a test that benchmarks different ways of attaching BPF program to a kernel function. Here are the results for 2.4Ghz x86 cpu on a kernel without mitigations: $ ./test_progs -n 49 -v|grep events task_rename base 2743K events per sec task_rename kprobe 2419K events per sec task_rename kretprobe 1876K events per sec task_rename raw_tp 2578K events per sec task_rename fentry 2710K events per sec task_rename fexit 2685K events per sec On a kernel with retpoline: $ ./test_progs -n 49 -v|grep events task_rename base 2401K events per sec task_rename kprobe 1930K events per sec task_rename kretprobe 1485K events per sec task_rename raw_tp 2053K events per sec task_rename fentry 2351K events per sec task_rename fexit 2185K events per sec All 5 approaches: - kprobe/kretprobe in __set_task_comm() - raw tracepoint in trace_task_rename() - fentry/fexit in __set_task_comm() are roughly equivalent. __set_task_comm() by itself is quite fast, so any extra instructions add up. Until BPF trampoline was introduced the fastest mechanism was raw tracepoint. kprobe via ftrace was second best. kretprobe is slow due to trap. New fentry/fexit methods via BPF trampoline are clearly the fastest and the difference is more pronounced with retpoline on, since BPF trampoline doesn't use indirect jumps. Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20191122011515.255371-1-ast@kernel.org",".../selftests/bpf/prog_tests/test_overhead.c | 142 +++++++++++++++++++++; tools/testing/selftests/bpf/progs/test_overhead.c | 43 +++++++; 2 files changed, 185 insertions(+)","Add a selftest that evaluates BPF trampoline performance compared to other attachment methods.","BPF,trampoline,performance","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","['kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.', 'Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.', ""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"161f3cbcda06aa70faed6b703066fedbd7653e23","161f3cbcda06aa70faed6b703066fedbd7653e23","Alexei Starovoitov","ast@kernel.org","1574447378","Alexei Starovoitov","ast@kernel.org","1574643526","dc410e35bdb263512e095f64aed2456b19e132d8","6147a140c99f1ded2b519dfbed17e781e5861bf3 260cb5df9d16c5715b32d73cc8af26ad9a17a792","Merge branch 'jmp32-reg-bounds' Yonghong Song says: ==================== With latest llvm, bpf selftest test_progs, which has +alu32 enabled, failed for strobemeta.o and a few other subtests. The reason is due to that verifier did not provide better var_off.mask after jmp32 instructions. This patch set addressed this issue and after the fix, test_progs passed with alu32. Patch #1 provided detailed explanation of the problem and the fix. Patch #2 added three tests in test_verifier. Changelog: v1 -> v2: - do not directly manipulate tnum.{value,mask} in __reg_bound_offset32(), using tnum_lshift/tnum_rshift functions instead - do __reg_bound_offset32() after regular 64bit __reg_bound_offset() since the latter may give a better upper 32bit var_off, which can be inherited by __reg_bound_offset32(). ==================== Signed-off-by: Alexei Starovoitov ","","The commit merges changes to address verifier issues with jmp32 instructions in eBPF programs on new LLVM versions.","verifier, jmp32, llvm","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"6147a140c99f1ded2b519dfbed17e781e5861bf3","6147a140c99f1ded2b519dfbed17e781e5861bf3","Andrii Nakryiko","andriin@fb.com","1574359140","Alexei Starovoitov","ast@kernel.org","1574643526","3d3484f31c432843f412fb9ee4bf72ee8777baed","1aace10f41adf1080d1cc54de9b3db98b8b8b0fb","selftests/bpf: Ensure core_reloc_kernel is reading test_progs's data only test_core_reloc_kernel.c selftest is the only CO-RE test that reads and returns for validation calling thread's information (pid, tgid, comm). Thus it has to make sure that only test_prog's invocations are honored. Fixes: df36e621418b (""selftests/bpf: add CO-RE relocs testing setup"") Reported-by: Alexei Starovoitov Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20191121175900.3486133-1-andriin@fb.com","tools/testing/selftests/bpf/prog_tests/core_reloc.c | 16 +++++++++++-----; .../testing/selftests/bpf/progs/test_core_reloc_kernel.c | 4 ++++; 2 files changed, 15 insertions(+), 5 deletions(-)","The commit ensures that selftests read and validate data specific to test_progs for CO-RE tests.","selftests, CO-RE, validation","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"260cb5df9d16c5715b32d73cc8af26ad9a17a792","260cb5df9d16c5715b32d73cc8af26ad9a17a792","Yonghong Song","yhs@fb.com","1574356011","Alexei Starovoitov","ast@kernel.org","1574643526","dc410e35bdb263512e095f64aed2456b19e132d8","581738a681b6faae5725c2555439189ca81c0f1f","selftests/bpf: Add verifier tests for better jmp32 register bounds Three test cases are added. Test 1: jmp32 'reg op imm'. Test 2: jmp32 'reg op reg' where dst 'reg' has unknown constant and src 'reg' has known constant Test 3: jmp32 'reg op reg' where dst 'reg' has known constant and src 'reg' has unknown constant Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191121170651.449096-1-yhs@fb.com","tools/testing/selftests/bpf/verifier/jmp32.c | 83 ++++++++++++++++++++++++++++; 1 file changed, 83 insertions(+)","Added new eBPF verifier test cases for jmp32 instruction register bounds.","verifier tests jmp32","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"1aace10f41adf1080d1cc54de9b3db98b8b8b0fb","1aace10f41adf1080d1cc54de9b3db98b8b8b0fb","Andrii Nakryiko","andriin@fb.com","1574382927","Alexei Starovoitov","ast@kernel.org","1574643526","36bcf6fb5bbafede18a029dec609d94c9c67bf30","071cdecec57fb5d5df78e6a12114ad7bccea5b0e","libbpf: Fix bpf_object name determination for bpf_object__open_file() If bpf_object__open_file() gets path like ""some/dir/obj.o"", it should derive BPF object's name as ""obj"" (unless overriden through opts->object_name). Instead, due to using `path` as a fallback value for opts->obj_name, path is used as is for object name, so for above example BPF object's name will be verbatim ""some/dir/obj"", which leads to all sorts of troubles, especially when internal maps are concern (they are using up to 8 characters of object name). Fix that by ensuring object_name stays NULL, unless overriden. Fixes: 291ee02b5e40 (""libbpf: Refactor bpf_object__open APIs to use common opts"") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191122003527.551556-1-andriin@fb.com","tools/lib/bpf/libbpf.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","Fix the object name derivation for bpf_object__open_file() in libbpf to prevent misnaming issues.","libbpf,name,fix","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"581738a681b6faae5725c2555439189ca81c0f1f","581738a681b6faae5725c2555439189ca81c0f1f","Yonghong Song","yhs@fb.com","1574356010","Alexei Starovoitov","ast@kernel.org","1574643526","0dc31d022d0a906aa6ad84c1c9094b285cee7b30","6147a140c99f1ded2b519dfbed17e781e5861bf3","bpf: Provide better register bounds after jmp32 instructions With latest llvm (trunk https://github.com/llvm/llvm-project), test_progs, which has +alu32 enabled, failed for strobemeta.o. The verifier output looks like below with edit to replace large decimal numbers with hex ones. 193: (85) call bpf_probe_read_user_str#114 R0=inv(id=0) 194: (26) if w0 > 0x1 goto pc+4 R0_w=inv(id=0,umax_value=0xffffffff00000001) 195: (6b) *(u16 *)(r7 +80) = r0 196: (bc) w6 = w0 R6_w=inv(id=0,umax_value=0xffffffff,var_off=(0x0; 0xffffffff)) 197: (67) r6 <<= 32 R6_w=inv(id=0,smax_value=0x7fffffff00000000,umax_value=0xffffffff00000000, var_off=(0x0; 0xffffffff00000000)) 198: (77) r6 >>= 32 R6=inv(id=0,umax_value=0xffffffff,var_off=(0x0; 0xffffffff)) ... 201: (79) r8 = *(u64 *)(r10 -416) R8_w=map_value(id=0,off=40,ks=4,vs=13872,imm=0) 202: (0f) r8 += r6 R8_w=map_value(id=0,off=40,ks=4,vs=13872,umax_value=0xffffffff,var_off=(0x0; 0xffffffff)) 203: (07) r8 += 9696 R8_w=map_value(id=0,off=9736,ks=4,vs=13872,umax_value=0xffffffff,var_off=(0x0; 0xffffffff)) ... 255: (bf) r1 = r8 R1_w=map_value(id=0,off=9736,ks=4,vs=13872,umax_value=0xffffffff,var_off=(0x0; 0xffffffff)) ... 257: (85) call bpf_probe_read_user_str#114 R1 unbounded memory access, make sure to bounds check any array access into a map The value range for register r6 at insn 198 should be really just 0/1. The umax_value=0xffffffff caused later verification failure. After jmp instructions, the current verifier already tried to use just obtained information to get better register range. The current mechanism is for 64bit register only. This patch implemented to tighten the range for 32bit sub-registers after jmp32 instructions. With the patch, we have the below range ranges for the above code sequence: 193: (85) call bpf_probe_read_user_str#114 R0=inv(id=0) 194: (26) if w0 > 0x1 goto pc+4 R0_w=inv(id=0,smax_value=0x7fffffff00000001,umax_value=0xffffffff00000001, var_off=(0x0; 0xffffffff00000001)) 195: (6b) *(u16 *)(r7 +80) = r0 196: (bc) w6 = w0 R6_w=inv(id=0,umax_value=0xffffffff,var_off=(0x0; 0x1)) 197: (67) r6 <<= 32 R6_w=inv(id=0,umax_value=0x100000000,var_off=(0x0; 0x100000000)) 198: (77) r6 >>= 32 R6=inv(id=0,umax_value=1,var_off=(0x0; 0x1)) ... 201: (79) r8 = *(u64 *)(r10 -416) R8_w=map_value(id=0,off=40,ks=4,vs=13872,imm=0) 202: (0f) r8 += r6 R8_w=map_value(id=0,off=40,ks=4,vs=13872,umax_value=1,var_off=(0x0; 0x1)) 203: (07) r8 += 9696 R8_w=map_value(id=0,off=9736,ks=4,vs=13872,umax_value=1,var_off=(0x0; 0x1)) ... 255: (bf) r1 = r8 R1_w=map_value(id=0,off=9736,ks=4,vs=13872,umax_value=1,var_off=(0x0; 0x1)) ... 257: (85) call bpf_probe_read_user_str#114 ... At insn 194, the register R0 has better var_off.mask and smax_value. Especially, the var_off.mask ensures later lshift and rshift maintains proper value range. Suggested-by: Alexei Starovoitov Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191121170650.449030-1-yhs@fb.com","kernel/bpf/verifier.c | 19 +++++++++++++++++++; 1 file changed, 19 insertions(+)","Enhances the eBPF verifier to provide more precise register bounds for 32-bit jumps.","verifier, register, bounds","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"071cdecec57fb5d5df78e6a12114ad7bccea5b0e","071cdecec57fb5d5df78e6a12114ad7bccea5b0e","Toke Høiland-Jørgensen","toke@redhat.com","1574343372","Alexei Starovoitov","ast@kernel.org","1574643526","6280415744ee6ce2e137d8d90262b20de7f6184f","1f60750401c7672419e1b606e2b73727c1f8626c","xdp: Fix cleanup on map free for devmap_hash map type Tetsuo pointed out that it was not only the device unregister hook that was broken for devmap_hash types, it was also cleanup on map free. So better fix this as well. While we're at it, there's no reason to allocate the netdev_map array for DEVMAP_HASH, so skip that and adjust the cost accordingly. Fixes: 6f9d451ab1a3 (""xdp: Add devmap_hash map type for looking up devices by hashed index"") Reported-by: Tetsuo Handa Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20191121133612.430414-1-toke@redhat.com","kernel/bpf/devmap.c | 74 +++++++++++++++++++++++++++++++++--------------------; 1 file changed, 46 insertions(+), 28 deletions(-)","Fixes cleanup on map free and unnecessary allocation for devmap_hash in XDP.","fixes,devmap_hash,XDP","A bug fix. It primarily resolves a bug or issue in the code.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.', ""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"1f60750401c7672419e1b606e2b73727c1f8626c","1f60750401c7672419e1b606e2b73727c1f8626c","Alexei Starovoitov","ast@kernel.org","1574356372","Alexei Starovoitov","ast@kernel.org","1574643526","1f046a91c4fdc56fabf6559e47fd5793a08df058","a8fdaad5cfd250b9effcec942b3bf7bc5a6c8b17 393cdfbee809891dc6ba859a44cc6441fa8dce9e","Merge branch 'libbpf-global-vars' Andrii Nakryiko says: ==================== This patch set salvages all the non-extern-specific changes out of blocked externs patch set ([0]). In addition to small clean ups, it also refactors libbpf's handling of relocations and allows support for global (non-static) variables. [0] https://patchwork.ozlabs.org/project/netdev/list/?series=143358&state=* ==================== Signed-off-by: Alexei Starovoitov ","","This commit merges libbpf changes for global variable support and relocation handling.","libbpf,global,relocations","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"a8fdaad5cfd250b9effcec942b3bf7bc5a6c8b17","a8fdaad5cfd250b9effcec942b3bf7bc5a6c8b17","Andrii Nakryiko","andriin@fb.com","1574210148","Alexei Starovoitov","ast@kernel.org","1574643525","5df857b4e1a49deb284ffa7ba42461d6550a2e20","5940c5bf6504f66f57f03f1d0046abfaf2198b3a","selftests/bpf: Integrate verbose verifier log into test_progs Add exra level of verboseness, activated by -vvv argument. When -vv is specified, verbose libbpf and verifier log (level 1) is output, even for successful tests. With -vvv, verifier log goes to level 2. This is extremely useful to debug verifier failures, as well as just see the state and flow of verification. Before this, you'd have to go and modify load_program()'s source code inside libbpf to specify extra log_level flags, which is suboptimal to say the least. Currently -vv and -vvv triggering verifier output is integrated into test_stub's bpf_prog_load as well as bpf_verif_scale.c tests. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191120003548.4159797-1-andriin@fb.com",".../testing/selftests/bpf/prog_tests/bpf_verif_scale.c | 4 +++-; tools/testing/selftests/bpf/test_progs.c | 18 ++++++++++++------; tools/testing/selftests/bpf/test_progs.h | 10 ++++++++--; tools/testing/selftests/bpf/test_stub.c | 4 ++++; 4 files changed, 27 insertions(+), 9 deletions(-)","The commit enhances verbosity in eBPF test logs to aid debugging by integrating different verbosity levels.","verbosity,verifier,debugging","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"393cdfbee809891dc6ba859a44cc6441fa8dce9e","393cdfbee809891dc6ba859a44cc6441fa8dce9e","Andrii Nakryiko","andriin@fb.com","1574320063","Alexei Starovoitov","ast@kernel.org","1574643525","1f046a91c4fdc56fabf6559e47fd5793a08df058","8983b731ceb42939acaa6158abcf8adb56f834bf","libbpf: Support initialized global variables Initialized global variables are no different in ELF from static variables, and don't require any extra support from libbpf. But they are matching semantics of global data (backed by BPF maps) more closely, preventing LLVM/Clang from aggressively inlining constant values and not requiring volatile incantations to prevent those. This patch enables global variables. It still disables uninitialized variables, which will be put into special COM (common) ELF section, because BPF doesn't allow uninitialized data to be accessed. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191121070743.1309473-5-andriin@fb.com","tools/lib/bpf/libbpf.c | 9 ++-------; tools/testing/selftests/bpf/progs/test_core_reloc_arrays.c | 4 ++--; .../selftests/bpf/progs/test_core_reloc_bitfields_direct.c | 4 ++--; .../selftests/bpf/progs/test_core_reloc_bitfields_probed.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_existence.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_flavors.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_ints.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_kernel.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_misc.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_mods.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_nesting.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_primitives.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_ptr_as_arr.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_size.c | 4 ++--; 14 files changed, 28 insertions(+), 33 deletions(-)","This commit allows libbpf to support initialized global variables, aligning them with BPF map semantics.","libbpf,initialized,global","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"5940c5bf6504f66f57f03f1d0046abfaf2198b3a","5940c5bf6504f66f57f03f1d0046abfaf2198b3a","Jakub Kicinski","jakub.kicinski@netronome.com","1574160610","Alexei Starovoitov","ast@kernel.org","1574643525","d1395935d61237275e7e98cf5b9aa1b55289d129","31f8b8295bb8997f139fe34b68654f8f1408f0da","selftests, bpftool: Skip the build test if not in tree If selftests are copied over to another machine/location for execution the build test of bpftool will obviously not work, since the sources are not copied. Skip it if we can't find bpftool's Makefile. Reported-by: Naresh Kamboju Signed-off-by: Jakub Kicinski Signed-off-by: Quentin Monnet Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191119105010.19189-3-quentin.monnet@netronome.com","tools/testing/selftests/bpf/test_bpftool_build.sh | 4 ++++; 1 file changed, 4 insertions(+)","Skip bpftool build test if sources are not available in selftests environment.","selftests,bpftool,build","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"8983b731ceb42939acaa6158abcf8adb56f834bf","8983b731ceb42939acaa6158abcf8adb56f834bf","Andrii Nakryiko","andriin@fb.com","1574320062","Alexei Starovoitov","ast@kernel.org","1574643525","a0ff51981d6544f46c20fcf28069f4c46de5e518","1f8e2bcb2cd5ee1a731fb625a5438e2c305f6a7c","libbpf: Fix various errors and warning reported by checkpatch.pl Fix a bunch of warnings and errors reported by checkpatch.pl, to make it easier to spot new problems. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191121070743.1309473-4-andriin@fb.com","tools/lib/bpf/libbpf.c | 38 +++++++++++++++++++++-----------------; 1 file changed, 21 insertions(+), 17 deletions(-)","The commit fixes errors and warnings in libbpf identified by checkpatch.pl to enhance code quality.","libbpf,fix,checkpatch","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"31f8b8295bb8997f139fe34b68654f8f1408f0da","31f8b8295bb8997f139fe34b68654f8f1408f0da","Quentin Monnet","quentin.monnet@netronome.com","1574160609","Alexei Starovoitov","ast@kernel.org","1574643525","c6a62ad38a8a7cc87f6389a3723b0f6b2445d296","a89b2cbf71d64b61e79bbe5cb7ff4664797eeaaf","selftests, bpftool: Set EXIT trap after usage function The trap on EXIT is used to clean up any temporary directory left by the build attempts. It is not needed when the user simply calls the script with its --help option, and may not be needed either if we add checks (e.g. on the availability of bpftool files) before the build attempts. Let's move this trap and related variables lower down in the code, so that we don't accidentally change the value returned from the script on early exits at pre-checks. Signed-off-by: Quentin Monnet Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Kicinski Link: https://lore.kernel.org/bpf/20191119105010.19189-2-quentin.monnet@netronome.com","tools/testing/selftests/bpf/test_bpftool_build.sh | 26 +++++++++++------------; 1 file changed, 13 insertions(+), 13 deletions(-)","This commit refactors the EXIT trap usage in the bpftool build test script to improve early exit handling.","EXIT trap refactor","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"1f8e2bcb2cd5ee1a731fb625a5438e2c305f6a7c","1f8e2bcb2cd5ee1a731fb625a5438e2c305f6a7c","Andrii Nakryiko","andriin@fb.com","1574320061","Alexei Starovoitov","ast@kernel.org","1574643525","b06cb9fbde1c9a91db7429122fef164adfc10ac6","ffc88174cdcf5f51fb7f6298fe9203a36c904f1f","libbpf: Refactor relocation handling Relocation handling code is convoluted and unnecessarily deeply nested. Split out per-relocation logic into separate function. Also refactor the logic to be more a sequence of per-relocation type checks and processing steps, making it simpler to follow control flow. This makes it easier to further extends it to new kinds of relocations (e.g., support for extern variables). This patch also makes relocation's section verification more robust. Previously relocations against not yet supported externs were silently ignored because of obj->efile.text_shndx was zero, when all BPF programs had custom section names and there was no .text section. Also, invalid LDIMM64 relocations against non-map sections were passed through, if they were pointing to a .text section (or 0, which is invalid section). All these bugs are fixed within this refactoring and checks are made more appropriate for each type of relocation. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191121070743.1309473-3-andriin@fb.com","tools/lib/bpf/libbpf.c | 261 +++++++++++++++++++++++++++----------------------; 1 file changed, 143 insertions(+), 118 deletions(-)","Refactor relocation handling in libbpf to simplify control flow and improve robustness.","refactor,relocation,libbpf","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"a89b2cbf71d64b61e79bbe5cb7ff4664797eeaaf","a89b2cbf71d64b61e79bbe5cb7ff4664797eeaaf","Quentin Monnet","quentin.monnet@netronome.com","1574160986","Alexei Starovoitov","ast@kernel.org","1574643525","3ce36bc3f89b98f8b62709d5b3df099db7d71850","a0f17cc6665c80ab2765f9244c41ec127821f343","tools, bpf: Fix build for 'make -s tools/bpf O=' Building selftests with 'make TARGETS=bpf kselftest' was fixed in commit 55d554f5d140 (""tools: bpf: Use !building_out_of_srctree to determine srctree""). However, by updating $(srctree) in tools/bpf/Makefile for in-tree builds only, we leave out the case where we pass an output directory to build BPF tools, but $(srctree) is not set. This typically happens for: $ make -s tools/bpf O=/tmp/foo Makefile:40: /tools/build/Makefile.feature: No such file or directory Fix it by updating $(srctree) in the Makefile not only for out-of-tree builds, but also if $(srctree) is empty. Detected with test_bpftool_build.sh. Fixes: 55d554f5d140 (""tools: bpf: Use !building_out_of_srctree to determine srctree"") Signed-off-by: Quentin Monnet Signed-off-by: Daniel Borkmann Acked-by: Jakub Kicinski Link: https://lore.kernel.org/bpf/20191119105626.21453-1-quentin.monnet@netronome.com","tools/bpf/Makefile | 6 ++++++; 1 file changed, 6 insertions(+)","The commit fixes the build issue for BPF tools when an output directory is specified but srctree is not set.","build, srctree, Makefile","A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"ffc88174cdcf5f51fb7f6298fe9203a36c904f1f","ffc88174cdcf5f51fb7f6298fe9203a36c904f1f","Andrii Nakryiko","andriin@fb.com","1574320060","Alexei Starovoitov","ast@kernel.org","1574643525","0776748fd7991bad8fd5ff1d8070d9d29035f8f7","a8fdaad5cfd250b9effcec942b3bf7bc5a6c8b17","selftests/bpf: Ensure no DWARF relocations for BPF object files Add -mattr=dwarfris attribute to llc to avoid having relocations against DWARF data. These relocations make it impossible to inspect DWARF contents: all strings are invalid. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191121070743.1309473-2-andriin@fb.com","tools/testing/selftests/bpf/Makefile | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","Modify Makefile to ensure no DWARF relocations for BPF object files.","DWARF,relocations,Makefile","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"a0f17cc6665c80ab2765f9244c41ec127821f343","a0f17cc6665c80ab2765f9244c41ec127821f343","Quentin Monnet","quentin.monnet@netronome.com","1574162226","Alexei Starovoitov","ast@kernel.org","1574643524","210d5eafe2c8e36549729e1df540525b390401c9","5d946c5abbaf68083fa6a41824dd79e1f06286d8","tools, bpftool: Fix warning on ignored return value for 'read' When building bpftool, a warning was introduced by commit a94364603610 (""bpftool: Allow to read btf as raw data""), because the return value from a call to 'read()' is ignored. Let's address it. Signed-off-by: Quentin Monnet Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Kicinski Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20191119111706.22440-1-quentin.monnet@netronome.com","tools/bpf/bpftool/btf.c | 6 +++---; 1 file changed, 3 insertions(+), 3 deletions(-)","The commit fixes a warning in bpftool by correctly handling the return value of the 'read' function.","bpftool,warning,read","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"5d946c5abbaf68083fa6a41824dd79e1f06286d8","5d946c5abbaf68083fa6a41824dd79e1f06286d8","Luc Van Oostenryck","luc.vanoostenryck@gmail.com","1574208642","Alexei Starovoitov","ast@kernel.org","1574643524","2f5e4665fa092b4d88216e7806aa592f11446c6d","c392bccf2c1075b5d2cc9022d0116a516acb721d","xsk: Fix xsk_poll()'s return type xsk_poll() is defined as returning 'unsigned int' but the .poll method is declared as returning '__poll_t', a bitwise type. Fix this by using the proper return type and using the EPOLL constants instead of the POLL ones, as required for __poll_t. Signed-off-by: Luc Van Oostenryck Signed-off-by: Daniel Borkmann Acked-by: Björn Töpel Link: https://lore.kernel.org/bpf/20191120001042.30830-1-luc.vanoostenryck@gmail.com","net/xdp/xsk.c | 8 ++++----; 1 file changed, 4 insertions(+), 4 deletions(-)","The commit fixes the xsk_poll() return type to use __poll_t with EPOLL constants, correcting an inconsistency.","xsk_poll, __poll_t, fix","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.']" +"84bb46cd62283cc371769ec1f77ff7924099f584","84bb46cd62283cc371769ec1f77ff7924099f584","Jakub Kicinski","jakub.kicinski@netronome.com","1574531698","Jakub Kicinski","jakub.kicinski@netronome.com","1574531762","eb34068e2731f902839116e415abfc5f9ba88f08","8dcdc9524cad74968b18322651d6fafb288a00ad","Revert ""bpf: Emit audit messages upon successful prog load and unload"" This commit reverts commit 91e6015b082b (""bpf: Emit audit messages upon successful prog load and unload"") and its follow up commit 7599a896f2e4 (""audit: Move audit_log_task declaration under CONFIG_AUDITSYSCALL"") as requested by Paul Moore. The change needs close review on linux-audit, tests etc. Signed-off-by: Jakub Kicinski ","include/linux/audit.h | 5 -----; include/uapi/linux/audit.h | 1 -; kernel/auditsc.c | 2 +-; kernel/bpf/syscall.c | 31 -------------------------------; 4 files changed, 1 insertion(+), 38 deletions(-)","The commit reverts changes that emitted audit messages during eBPF program load and unload.","revert, audit, bpf","It's other type of commit. It does not fit into any of the categories listed above.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"8cacac6ecd6d289d4ab52590784636a5b1043c66","8cacac6ecd6d289d4ab52590784636a5b1043c66","Ingo Molnar","mingo@kernel.org","1574496013","Ingo Molnar","mingo@kernel.org","1574496013","93ce4b0bee817972a525906600fd41087ee10094","8f6ee51d772d0dab407d868449d2c5d9c8d2b6fc 4584f084aa9d8033d5911935837dbee7b082d0e9","Merge tag 'perf-core-for-mingo-5.5-20191122' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core Pull perf/core improvements and fixes from Arnaldo Carvalho de Melo: perf report: Jin Yao: - Allow entering the annotation view (symbol source/assembly + overhead/cycles/etc column) from the 'perf report --total-cycles' interface. E.g.: # perf record --all-cpus --branch-any --all-kernel ^C[ perf record: Woken up 5 times to write data ] # # perf evlist -v cycles: size: 120, { sample_period, sample_freq }: 4000, sample_type: IP|TID|TIME|CPU|PERIOD|BRANCH_STACK, read_format: ID, disabled: 1, inherit: 1, exclude_user: 1, mmap: 1, comm: 1, freq: 1, task: 1, precise_ip: 3, sample_id_all: 1, exclude_guest: 1, mmap2: 1, comm_exec: 1, ksymbol: 1, bpf_event: 1, branch_sample_type: ANY # # perf report --total-cycles # # Samples: 78762 of event 'cycles' Sampled Sampled Avg Avg Cycles% Cycles Cycles% Cycles [Program Block Range] Shared Object 1.72% 95.8K 0.00% 254 [msr.h:105 -> msr.h:166] [kernel.vmlinux] 1.56% 107.6K 0.00% 618 [compiler.h:199 -> common.c:301] [kernel.vmlinux] 0.83% 46.3K 0.00% 409 [entry_64.S:153 -> entry_64.S:175] [kernel.vmlinux] 0.83% 46.1K 0.00% 83 [jump_label.h:41 -> tsc.c:230] [kernel.vmlinux] 0.64% 36.9K 0.01% 1.4K [hda_intel.c:904 -> hda_intel.c:916] [snd_hda_intel] 0.57% 30.2K 0.00% 282 [file.c:710 -> file.c:730] [kernel.vmlinux] 0.48% 25.8K 0.00% 82 [spinlock.c:158 -> spinlock.c:160] [kernel.vmlinux] 0.45% 23.7K 0.00% 369 [tick-broadcast.c:585 -> tick-broadcast.c:586] [kernel.vmlinux] 0.44% 24.4K 0.00% 73 [msr.h:236 -> tsc.c:1088] [kernel.vmlinux] 0.43% 22.7K 0.00% 144 [cpuidle.c:229 -> cpuidle.c:232] [kernel.vmlinux] Then press 'A' or Enter on one of those lines, just like with 'perf top', say the top one: [msr.h:105 -> msr.h:166], then this shows up: Samples: 78K of event 'cycles', 4000 Hz, Event count (approx.): 78762 native_write_msr /lib/modules/5.4.0-rc8/build/vmlinux [Percent: local period] Percent│ IPC Cycle (Average IPC: 0.02, IPC Coverage: 50.0%) │ │ Disassembly of section .text: │ │ ffffffff8106c480 : │ __wrmsr(): │ return EAX_EDX_VAL(val, low, high); │ } │ │ static inline void notrace __wrmsr(unsigned int msr, u32 low, u32 high) │ { │ asm volatile(""1: wrmsr\n"" 49.16 │0.02 mov %edi,%ecx │0.02 mov %esi,%eax │0.02 wrmsr │ arch_static_branch(): │ #include │ #include │ │ static __always_inline bool arch_static_branch(struct static_key *key, bool branch) │ { │ asm_volatile_goto(""1:"" 0.79 │0.02 nop │ native_write_msr(): │ { │ __wrmsr(msr, low, high); │ │ if (msr_tracepoint_active(__tracepoint_write_msr)) │ do_trace_write_msr(msr, ((u64)high << 32 | low), 0); │ } 50.05 │0.02 254 ← retq │ do_trace_write_msr(msr, ((u64)high << 32 | low), 0); │ shl $0x20,%rdx │ mov %esi,%esi │ or %rdx,%rsi │ xor %edx,%edx │ → jmpq do_trace_write_msr We need to improve this to show the source code line numbers in the annotation view, so one can go from that program block to the annotation view and see those source code line numbers straight away. auxtrace/Intel PT: Adrian Hunter: - Add support for AUX area sampling, requires new functionality that will land in 5.5, its already in tip. This includes kernel capability querying so that it fails gracefully with older kernels, duimping aux area samples in 'perf report -D' and 'perf script'. perf.data: Alexey Budankov: - Fix decompression of PERF_RECORD_COMPRESSED records. core: Arnaldo Carvalho de Melo: - Use the 'dcacheline' cmp routine to find the right DSOs taking into account the 'maj', 'min', 'ino' and 'ino_generation', that got moved from 'struct map' to 'struct dso', where it belongs. This further reduces the size of 'struct map', there is still more work to do to maybe get it to max one cacheline. libtraceevent: Hewenliang: - Fix memory leakage in copy_filter_type(). Sudip Mukherjee: - Fix header installation. perf parse: Ian Rogers : - Fix potential memory leak when handling tracepoint errors, found using LLVM's libFuzzer. perf probe: Colin Ian King: - Fix spelling mistake ""addrees"" -> ""address"". Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Ingo Molnar ","","This commit merges performance core improvements and fixes related to various perf subsystems for the Linux kernel 5.5.","perf,core,merge","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"8163999db445021f2651a8a47b5632483e8722ea","8163999db445021f2651a8a47b5632483e8722ea","John Fastabend","john.fastabend@gmail.com","1574353509","David S. Miller","davem@davemloft.net","1574372625","044f73c60b4d6d2becf9a03c5c78170d7dbe1e98","7599a896f2e46e9c072e02a8299a67d4d2f96675","bpf: skmsg, fix potential psock NULL pointer dereference Report from Dan Carpenter, net/core/skmsg.c:792 sk_psock_write_space() error: we previously assumed 'psock' could be null (see line 790) net/core/skmsg.c 789 psock = sk_psock(sk); 790 if (likely(psock && sk_psock_test_state(psock, SK_PSOCK_TX_ENABLED))) Check for NULL 791 schedule_work(&psock->work); 792 write_space = psock->saved_write_space; ^^^^^^^^^^^^^^^^^^^^^^^^ 793 rcu_read_unlock(); 794 write_space(sk); Ensure psock dereference on line 792 only occurs if psock is not null. Reported-by: Dan Carpenter Fixes: 604326b41a6f (""bpf, sockmap: convert to generic sk_msg interface"") Signed-off-by: John Fastabend Signed-off-by: David S. Miller ","net/core/skmsg.c | 13 ++++++++-----; 1 file changed, 8 insertions(+), 5 deletions(-)","Fixes a potential NULL pointer dereference in skmsg handling within the eBPF sockmap interface.","NULL, skmsg, psock","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.']" +"7599a896f2e46e9c072e02a8299a67d4d2f96675","7599a896f2e46e9c072e02a8299a67d4d2f96675","Jiri Olsa","jolsa@kernel.org","1574351933","David S. Miller","davem@davemloft.net","1574367289","a7ebc80127a1ec2b54d047aa8d37b76cbcba3b32","43da14110cb4d20de0b4b097da88addefeab5f13","audit: Move audit_log_task declaration under CONFIG_AUDITSYSCALL The 0-DAY found that audit_log_task is not declared under CONFIG_AUDITSYSCALL which causes compilation error when it is not defined: kernel/bpf/syscall.o: In function `bpf_audit_prog.isra.30': >> syscall.c:(.text+0x860): undefined reference to `audit_log_task' Adding the audit_log_task declaration and stub within CONFIG_AUDITSYSCALL ifdef. Fixes: 91e6015b082b (""bpf: Emit audit messages upon successful prog load and unload"") Reported-by: kbuild test robot Signed-off-by: Jiri Olsa Signed-off-by: David S. Miller ","include/linux/audit.h | 8 +++++---; 1 file changed, 5 insertions(+), 3 deletions(-)","The commit adjusts the audit_log_task declaration to fix compilation errors under specific configurations.","audit,declaration,compilation","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.""]" +"ee5a489fd9645104925e5cdf8f8e455d833730b9","ee5a489fd9645104925e5cdf8f8e455d833730b9","David S. Miller","davem@davemloft.net","1574302283","David S. Miller","davem@davemloft.net","1574302283","1e46a8c460e1d51d465fe472e42cf1c16f92f9c7","e2193c9334291ecdc437cdbd9fe9ac35c14fffa8 196e8ca74886c433dcfc64a809707074b936aaf5","Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next Daniel Borkmann says: ==================== pull-request: bpf-next 2019-11-20 The following pull-request contains BPF updates for your *net-next* tree. We've added 81 non-merge commits during the last 17 day(s) which contain a total of 120 files changed, 4958 insertions(+), 1081 deletions(-). There are 3 trivial conflicts, resolve it by always taking the chunk from 196e8ca74886c433: <<<<<<< HEAD ======= void *bpf_map_area_mmapable_alloc(u64 size, int numa_node); >>>>>>> 196e8ca74886c433dcfc64a809707074b936aaf5 <<<<<<< HEAD void *bpf_map_area_alloc(u64 size, int numa_node) ======= static void *__bpf_map_area_alloc(u64 size, int numa_node, bool mmapable) >>>>>>> 196e8ca74886c433dcfc64a809707074b936aaf5 <<<<<<< HEAD if (size <= (PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER)) { ======= /* kmalloc()'ed memory can't be mmap()'ed */ if (!mmapable && size <= (PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER)) { >>>>>>> 196e8ca74886c433dcfc64a809707074b936aaf5 The main changes are: 1) Addition of BPF trampoline which works as a bridge between kernel functions, BPF programs and other BPF programs along with two new use cases: i) fentry/fexit BPF programs for tracing with practically zero overhead to call into BPF (as opposed to k[ret]probes) and ii) attachment of the former to networking related programs to see input/output of networking programs (covering xdpdump use case), from Alexei Starovoitov. 2) BPF array map mmap support and use in libbpf for global data maps; also a big batch of libbpf improvements, among others, support for reading bitfields in a relocatable manner (via libbpf's CO-RE helper API), from Andrii Nakryiko. 3) Extend s390x JIT with usage of relative long jumps and loads in order to lift the current 64/512k size limits on JITed BPF programs there, from Ilya Leoshkevich. 4) Add BPF audit support and emit messages upon successful prog load and unload in order to have a timeline of events, from Daniel Borkmann and Jiri Olsa. 5) Extension to libbpf and xdpsock sample programs to demo the shared umem mode (XDP_SHARED_UMEM) as well as RX-only and TX-only sockets, from Magnus Karlsson. 6) Several follow-up bug fixes for libbpf's auto-pinning code and a new API call named bpf_get_link_xdp_info() for retrieving the full set of prog IDs attached to XDP, from Toke Høiland-Jørgensen. 7) Add BTF support for array of int, array of struct and multidimensional arrays and enable it for skb->cb[] access in kfree_skb test, from Martin KaFai Lau. 8) Fix AF_XDP by using the correct number of channels from ethtool, from Luigi Rizzo. 9) Two fixes for BPF selftest to get rid of a hang in test_tc_tunnel and to avoid xdping to be run as standalone, from Jiri Benc. 10) Various BPF selftest fixes when run with latest LLVM trunk, from Yonghong Song. 11) Fix a memory leak in BPF fentry test run data, from Colin Ian King. 12) Various smaller misc cleanups and improvements mostly all over BPF selftests and samples, from Daniel T. Lee, Andre Guedes, Anders Roxell, Mao Wenan, Yue Haibing. ==================== Signed-off-by: David S. Miller ","","This commit merges various BPF updates including new features, bug fixes, and performance optimizations from the bpf-next branch into the net-next tree.","BPF,merge,updates","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","[""It's likely a merge commit. It involves changes across multiple use cases or events.""]" +"196e8ca74886c433dcfc64a809707074b936aaf5","196e8ca74886c433dcfc64a809707074b936aaf5","Daniel Borkmann","daniel@iogearbox.net","1574287484","Daniel Borkmann","daniel@iogearbox.net","1574288338","9f3f34d9f9792de7b9e7c5285926341f1957a9a2","91e6015b082b08a74e5d9d326f651e5890a93519","bpf: Switch bpf_map_{area_alloc,area_mmapable_alloc}() to u64 size Given we recently extended the original bpf_map_area_alloc() helper in commit fc9702273e2e (""bpf: Add mmap() support for BPF_MAP_TYPE_ARRAY""), we need to apply the same logic as in ff1c08e1f74b (""bpf: Change size to u64 for bpf_map_{area_alloc, charge_init}()""). To avoid conflicts, extend it for bpf-next. Reported-by: Stephen Rothwell Signed-off-by: Daniel Borkmann ","include/linux/bpf.h | 6 +++---; kernel/bpf/syscall.c | 11 +++++++----; 2 files changed, 10 insertions(+), 7 deletions(-)","The commit modifies bpf_map allocation functions to use u64 for size to extend mmap support.","bpf_map, u64, mmap","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The syscall interface. It changes the system calls through which user-space programs interact with eBPF.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"91e6015b082b08a74e5d9d326f651e5890a93519","91e6015b082b08a74e5d9d326f651e5890a93519","Daniel Borkmann","daniel@iogearbox.net","1574285896","Alexei Starovoitov","ast@kernel.org","1574286291","dca309a8e414d6a13bb1a6a0a64847b5e28c50ed","b2e2f0e6a6f910c906c083584b6e0afd12266f22","bpf: Emit audit messages upon successful prog load and unload Allow for audit messages to be emitted upon BPF program load and unload for having a timeline of events. The load itself is in syscall context, so additional info about the process initiating the BPF prog creation can be logged and later directly correlated to the unload event. The only info really needed from BPF side is the globally unique prog ID where then audit user space tooling can query / dump all info needed about the specific BPF program right upon load event and enrich the record, thus these changes needed here can be kept small and non-intrusive to the core. Raw example output: # auditctl -D # auditctl -a always,exit -F arch=x86_64 -S bpf # ausearch --start recent -m 1334 [...] ---- time->Wed Nov 20 12:45:51 2019 type=PROCTITLE msg=audit(1574271951.590:8974): proctitle=""./test_verifier"" type=SYSCALL msg=audit(1574271951.590:8974): arch=c000003e syscall=321 success=yes exit=14 a0=5 a1=7ffe2d923e80 a2=78 a3=0 items=0 ppid=742 pid=949 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm=""test_verifier"" exe=""/root/bpf-next/tools/testing/selftests/bpf/test_verifier"" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) type=UNKNOWN[1334] msg=audit(1574271951.590:8974): auid=0 uid=0 gid=0 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=949 comm=""test_verifier"" exe=""/root/bpf-next/tools/testing/selftests/bpf/test_verifier"" prog-id=3260 event=LOAD ---- time->Wed Nov 20 12:45:51 2019 type=UNKNOWN[1334] msg=audit(1574271951.590:8975): prog-id=3260 event=UNLOAD ---- [...] Signed-off-by: Daniel Borkmann Signed-off-by: Jiri Olsa Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191120213816.8186-1-jolsa@kernel.org","include/linux/audit.h | 3 +++; include/uapi/linux/audit.h | 1 +; kernel/auditsc.c | 2 +-; kernel/bpf/syscall.c | 31 +++++++++++++++++++++++++++++++; 4 files changed, 36 insertions(+), 1 deletion(-)","Adds audit message support for eBPF program load and unload to track process events.","audit,prog,load","A new feature. It adds a new capability or feature that was not previously present.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The syscall interface. It changes the system calls through which user-space programs interact with eBPF.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"b2e2f0e6a6f910c906c083584b6e0afd12266f22","b2e2f0e6a6f910c906c083584b6e0afd12266f22","YueHaibing","yuehaibing@huawei.com","1574173273","Alexei Starovoitov","ast@kernel.org","1574211452","0272beb392994457c73e9980ef630ca9688eb3a2","24f65050276a4f82d5832e974dabfb5be5c07c39","bpf: Make array_map_mmap static Fix sparse warning: kernel/bpf/arraymap.c:481:5: warning: symbol 'array_map_mmap' was not declared. Should it be static? Reported-by: Hulk Robot Signed-off-by: YueHaibing Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20191119142113.15388-1-yuehaibing@huawei.com","kernel/bpf/arraymap.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-)","This commit marks array_map_mmap as static to correct a visibility warning in the kernel BPF module.","static,array_map,sparse","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"24f65050276a4f82d5832e974dabfb5be5c07c39","24f65050276a4f82d5832e974dabfb5be5c07c39","Andrii Nakryiko","andriin@fb.com","1574209510","Alexei Starovoitov","ast@kernel.org","1574211202","57f8eee96a6fa5541d11fea90a9ace782d8ae848","a0d7da26ce86a25e97ae191cb90574ada6daea98","selftests/bpf: Enforce no-ALU32 for test_progs-no_alu32 With the most recent Clang, alu32 is enabled by default if -mcpu=probe or -mcpu=v3 is specified. Use a separate build rule with -mcpu=v2 to enforce no ALU32 mode. Suggested-by: Yonghong Song Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20191120002510.4130605-1-andriin@fb.com","tools/testing/selftests/bpf/Makefile | 7 +++++++; 1 file changed, 7 insertions(+)","The commit enforces no-ALU32 mode for test cases by modifying build rules with -mcpu=v2 in the Makefile.","no-ALU32, Makefile, test_progs","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"d4ffb02dee2fcb20e0c8086a8d1305bf885820bb","d4ffb02dee2fcb20e0c8086a8d1305bf885820bb","Willem de Bruijn","willemb@google.com","1574091651","David S. Miller","davem@davemloft.net","1574204582","13860fc65238986228ef7e1fc98bf6cc707db7c8","db96c2cb4870173ea9b08df130f1d1cc9b5dd53d","net/tls: enable sk_msg redirect to tls socket egress Bring back tls_sw_sendpage_locked. sk_msg redirection into a socket with TLS_TX takes the following path: tcp_bpf_sendmsg_redir tcp_bpf_push_locked tcp_bpf_push kernel_sendpage_locked sock->ops->sendpage_locked Also update the flags test in tls_sw_sendpage_locked to allow flag MSG_NO_SHARED_FRAGS. bpf_tcp_sendmsg sets this. Link: https://lore.kernel.org/netdev/CA+FuTSdaAawmZ2N8nfDDKu3XLpXBbMtcCT0q4FntDD2gn8ASUw@mail.gmail.com/T/#t Link: https://github.com/wdebruij/kerneltools/commits/icept.2 Fixes: 0608c69c9a80 (""bpf: sk_msg, sock{map|hash} redirect through ULP"") Fixes: f3de19af0f5b (""Revert \""net/tls: remove unused function tls_sw_sendpage_locked\"""") Signed-off-by: Willem de Bruijn Acked-by: John Fastabend Signed-off-by: David S. Miller ","include/net/tls.h | 2 ++; net/tls/tls_main.c | 1 +; net/tls/tls_sw.c | 11 +++++++++++; 3 files changed, 14 insertions(+)","The commit allows sk_msg redirection to TLS socket egress and updates functionality for tls_sw_sendpage_locked.","TLS,socket,redirection","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","['Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.', ""It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.""]" +"a0d7da26ce86a25e97ae191cb90574ada6daea98","a0d7da26ce86a25e97ae191cb90574ada6daea98","Andrii Nakryiko","andriin@fb.com","1574203487","Alexei Starovoitov","ast@kernel.org","1574204412","0f5437ea21d4206bddda7a82176968abb6dc60cd","3de88c9113f88c04abda339f1aa629397bf89e02","libbpf: Fix call relocation offset calculation bug When relocating subprogram call, libbpf doesn't take into account relo->text_off, which comes from symbol's value. This generally works fine for subprograms implemented as static functions, but breaks for global functions. Taking a simplified test_pkt_access.c as an example: __attribute__ ((noinline)) static int test_pkt_access_subprog1(volatile struct __sk_buff *skb) { return skb->len * 2; } __attribute__ ((noinline)) static int test_pkt_access_subprog2(int val, volatile struct __sk_buff *skb) { return skb->len + val; } SEC(""classifier/test_pkt_access"") int test_pkt_access(struct __sk_buff *skb) { if (test_pkt_access_subprog1(skb) != skb->len * 2) return TC_ACT_SHOT; if (test_pkt_access_subprog2(2, skb) != skb->len + 2) return TC_ACT_SHOT; return TC_ACT_UNSPEC; } When compiled, we get two relocations, pointing to '.text' symbol. .text has st_value set to 0 (it points to the beginning of .text section): 0000000000000008 000000050000000a R_BPF_64_32 0000000000000000 .text 0000000000000040 000000050000000a R_BPF_64_32 0000000000000000 .text test_pkt_access_subprog1 and test_pkt_access_subprog2 offsets (targets of two calls) are encoded within call instruction's imm32 part as -1 and 2, respectively: 0000000000000000 test_pkt_access_subprog1: 0: 61 10 00 00 00 00 00 00 r0 = *(u32 *)(r1 + 0) 1: 64 00 00 00 01 00 00 00 w0 <<= 1 2: 95 00 00 00 00 00 00 00 exit 0000000000000018 test_pkt_access_subprog2: 3: 61 10 00 00 00 00 00 00 r0 = *(u32 *)(r1 + 0) 4: 04 00 00 00 02 00 00 00 w0 += 2 5: 95 00 00 00 00 00 00 00 exit 0000000000000000 test_pkt_access: 0: bf 16 00 00 00 00 00 00 r6 = r1 ===> 1: 85 10 00 00 ff ff ff ff call -1 2: bc 01 00 00 00 00 00 00 w1 = w0 3: b4 00 00 00 02 00 00 00 w0 = 2 4: 61 62 00 00 00 00 00 00 r2 = *(u32 *)(r6 + 0) 5: 64 02 00 00 01 00 00 00 w2 <<= 1 6: 5e 21 08 00 00 00 00 00 if w1 != w2 goto +8 7: bf 61 00 00 00 00 00 00 r1 = r6 ===> 8: 85 10 00 00 02 00 00 00 call 2 9: bc 01 00 00 00 00 00 00 w1 = w0 10: 61 62 00 00 00 00 00 00 r2 = *(u32 *)(r6 + 0) 11: 04 02 00 00 02 00 00 00 w2 += 2 12: b4 00 00 00 ff ff ff ff w0 = -1 13: 1e 21 01 00 00 00 00 00 if w1 == w2 goto +1 14: b4 00 00 00 02 00 00 00 w0 = 2 0000000000000078 LBB0_3: 15: 95 00 00 00 00 00 00 00 exit Now, if we compile example with global functions, the setup changes. Relocations are now against specifically test_pkt_access_subprog1 and test_pkt_access_subprog2 symbols, with test_pkt_access_subprog2 pointing 24 bytes into its respective section (.text), i.e., 3 instructions in: 0000000000000008 000000070000000a R_BPF_64_32 0000000000000000 test_pkt_access_subprog1 0000000000000048 000000080000000a R_BPF_64_32 0000000000000018 test_pkt_access_subprog2 Calls instructions now encode offsets relative to function symbols and are both set ot -1: 0000000000000000 test_pkt_access_subprog1: 0: 61 10 00 00 00 00 00 00 r0 = *(u32 *)(r1 + 0) 1: 64 00 00 00 01 00 00 00 w0 <<= 1 2: 95 00 00 00 00 00 00 00 exit 0000000000000018 test_pkt_access_subprog2: 3: 61 20 00 00 00 00 00 00 r0 = *(u32 *)(r2 + 0) 4: 0c 10 00 00 00 00 00 00 w0 += w1 5: 95 00 00 00 00 00 00 00 exit 0000000000000000 test_pkt_access: 0: bf 16 00 00 00 00 00 00 r6 = r1 ===> 1: 85 10 00 00 ff ff ff ff call -1 2: bc 01 00 00 00 00 00 00 w1 = w0 3: b4 00 00 00 02 00 00 00 w0 = 2 4: 61 62 00 00 00 00 00 00 r2 = *(u32 *)(r6 + 0) 5: 64 02 00 00 01 00 00 00 w2 <<= 1 6: 5e 21 09 00 00 00 00 00 if w1 != w2 goto +9 7: b4 01 00 00 02 00 00 00 w1 = 2 8: bf 62 00 00 00 00 00 00 r2 = r6 ===> 9: 85 10 00 00 ff ff ff ff call -1 10: bc 01 00 00 00 00 00 00 w1 = w0 11: 61 62 00 00 00 00 00 00 r2 = *(u32 *)(r6 + 0) 12: 04 02 00 00 02 00 00 00 w2 += 2 13: b4 00 00 00 ff ff ff ff w0 = -1 14: 1e 21 01 00 00 00 00 00 if w1 == w2 goto +1 15: b4 00 00 00 02 00 00 00 w0 = 2 0000000000000080 LBB2_3: 16: 95 00 00 00 00 00 00 00 exit Thus the right formula to calculate target call offset after relocation should take into account relocation's target symbol value (offset within section), call instruction's imm32 offset, and (subtracting, to get relative instruction offset) instruction index of call instruction itself. All that is shifted by number of instructions in main program, given all sub-programs are copied over after main program. Convert few selftests relying on bpf-to-bpf calls to use global functions instead of static ones. Fixes: 48cca7e44f9f (""libbpf: add support for bpf_call"") Reported-by: Alexei Starovoitov Signed-off-by: Andrii Nakryiko Acked-by: Yonghong Song Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191119224447.3781271-1-andriin@fb.com","tools/lib/bpf/libbpf.c | 8 ++++++--; tools/testing/selftests/bpf/progs/test_btf_haskv.c | 4 ++--; tools/testing/selftests/bpf/progs/test_btf_newkv.c | 4 ++--; tools/testing/selftests/bpf/progs/test_btf_nokv.c | 4 ++--; 4 files changed, 12 insertions(+), 8 deletions(-)","Fixes a bug in libbpf's call relocation offset calculation for global subprogram functions.","libbpf,relocation,offset","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"3de88c9113f88c04abda339f1aa629397bf89e02","3de88c9113f88c04abda339f1aa629397bf89e02","Luigi Rizzo","lrizzo@google.com","1574122791","Alexei Starovoitov","ast@kernel.org","1574201195","a5ca98f429517394b3799c63a7be0674365df9d1","0424c5a4dda5608a2910474e3e8f0fd8e7126f42","net-af_xdp: Use correct number of channels from ethtool Drivers use different fields to report the number of channels, so take the maximum of all data channels (rx, tx, combined) when determining the size of the xsk map. The current code used only 'combined' which was set to 0 in some drivers e.g. mlx4. Tested: compiled and run xdpsock -q 3 -r -S on mlx4 Signed-off-by: Luigi Rizzo Signed-off-by: Alexei Starovoitov Reviewed-by: Jakub Kicinski Acked-by: Magnus Karlsson Link: https://lore.kernel.org/bpf/20191119001951.92930-1-lrizzo@google.com","tools/lib/bpf/xsk.c | 11 ++++++++---; 1 file changed, 8 insertions(+), 3 deletions(-)","This commit fixes the method for determining the number of channels for xsk maps in net-af_xdp by using the maximum of rx, tx, and combined fields.","channels, xsk map, ethtool","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","['XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.']" +"d1242b10ff03a40ae095e6dd54aac4a6f0f547d5","d1242b10ff03a40ae095e6dd54aac4a6f0f547d5","Ilya Leoshkevich","iii@linux.ibm.com","1574100220","Alexei Starovoitov","ast@kernel.org","1574135476","eac6b55040cf06b2d4e3c2fb1836e019ceaf70d5","b25c57b6b7dda3799aaebc5f463776e4a0555927","s390/bpf: Remove JITed image size limitations Now that jump and long displacement ranges are no longer a problem, remove the limit on JITed image size. In practice it's still limited by 2G, but with verifier allowing ""only"" 1M instructions, it's not an issue. Signed-off-by: Ilya Leoshkevich Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191118180340.68373-7-iii@linux.ibm.com","arch/s390/net/bpf_jit_comp.c | 7 -------; 1 file changed, 7 deletions(-)","The commit removes limitations on the JITed image size for s390 architecture in the eBPF subsystem.","JIT,remove,limit","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"b25c57b6b7dda3799aaebc5f463776e4a0555927","b25c57b6b7dda3799aaebc5f463776e4a0555927","Ilya Leoshkevich","iii@linux.ibm.com","1574100219","Alexei Starovoitov","ast@kernel.org","1574135476","b81a1acaf090da5f1608e91ba957f85b9bc6dfc7","451e448ff4bb137da3d4b8b26a8260a2ff66869a","s390/bpf: Use lg(f)rl when long displacement cannot be used If literal pool grows past 524287 mark, it's no longer possible to use long displacement to reference literal pool entries. In JIT setting maintaining multiple literal pool registers is next to impossible, since we operate on one instruction at a time. Therefore, fall back to loading literal pool entry using PC-relative addressing, and then using a register-register form of the following machine instruction. Signed-off-by: Ilya Leoshkevich Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191118180340.68373-6-iii@linux.ibm.com","arch/s390/net/bpf_jit_comp.c | 96 +++++++++++++++++++++++++++++++++++++-------; 1 file changed, 81 insertions(+), 15 deletions(-)","This commit addresses long displacement issues in s390 BPF JIT by using PC-relative addressing and register-register instructions.","s390,BPF,JIT","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"451e448ff4bb137da3d4b8b26a8260a2ff66869a","451e448ff4bb137da3d4b8b26a8260a2ff66869a","Ilya Leoshkevich","iii@linux.ibm.com","1574100218","Alexei Starovoitov","ast@kernel.org","1574135476","e1829a7bf05560eb28a49d20b52b6b8def0ae61d","c1aff5682da2977c26fc087cf6a28e31a430174b","s390/bpf: Use lgrl instead of lg where possible lg and lgrl have the same performance characteristics, but the former requires a base register and is subject to long displacement range limits, while the latter does not. Therefore, lgrl is totally superior to lg and should be used instead whenever possible. Signed-off-by: Ilya Leoshkevich Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191118180340.68373-5-iii@linux.ibm.com","arch/s390/net/bpf_jit_comp.c | 32 ++++++++++++++++++++------------; 1 file changed, 20 insertions(+), 12 deletions(-)","The commit optimizes s390 BPF JIT by using lgrl instructions instead of lg for better efficiency.","s390,JIT,lgrl","A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"c1aff5682da2977c26fc087cf6a28e31a430174b","c1aff5682da2977c26fc087cf6a28e31a430174b","Ilya Leoshkevich","iii@linux.ibm.com","1574100217","Alexei Starovoitov","ast@kernel.org","1574135476","11140c655c168fa2f1cdfce89b15276f16d58596","e0491f64795bfc71ef6b13ba6b6fa6e176fa3c23","s390/bpf: Load literal pool register using larl Currently literal pool register is loaded using basr, which makes it point not to the beginning of the literal pool, but rather to the next instruction. In case JITed code is larger than 512k, this renders literal pool register absolutely useless due to long displacement range restrictions. The solution is to use larl to make literal pool register point to the very beginning of the literal pool. This makes it always possible to address 512k worth of literal pool entries using long displacement. However, for short programs, in which the entire literal pool is covered by basr-generated base, it is still beneficial to use basr, since it is 4 bytes shorter than larl. Detect situations when basr-generated base does not cover the entire literal pool, and in such cases use larl instead. Signed-off-by: Ilya Leoshkevich Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191118180340.68373-4-iii@linux.ibm.com","arch/s390/net/bpf_jit_comp.c | 22 +++++++++++++++++++---; 1 file changed, 19 insertions(+), 3 deletions(-)","The commit changes the s390 BPF JIT to use 'larl' for literal pool addressing to handle larger JITed code.","s390,BPF,JIT","A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"e0491f64795bfc71ef6b13ba6b6fa6e176fa3c23","e0491f64795bfc71ef6b13ba6b6fa6e176fa3c23","Ilya Leoshkevich","iii@linux.ibm.com","1574100216","Alexei Starovoitov","ast@kernel.org","1574135476","d11bc8278ce9007aee5b00fd6d6985e359aa72f8","4e9b4a6883dd97aff53ae3b08eb900716a5469dc","s390/bpf: Align literal pool entries When literal pool size exceeds 512k, it's no longer possible to reference all the entries in it using a single base register and long displacement. Therefore, PC-relative lgfrl and lgrl instructions need to be used. Unfortunately, they require their arguments to be aligned to 4- and 8-byte boundaries respectively. This generates certain overhead due to necessary padding bytes. Grouping 4- and 8-byte entries together reduces the maximum overhead to 6 bytes (2 for aligning 4-byte entries and 4 for aligning 8-byte entries). While in theory it is possible to detect whether or not alignment is needed by comparing the literal pool size with 512k, in practice this leads to having two ways of emitting constants, making the code more complicated. Prefer code simplicity over trivial size saving, and always group and align literal pool entries. Signed-off-by: Ilya Leoshkevich Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191118180340.68373-3-iii@linux.ibm.com","arch/s390/net/bpf_jit_comp.c | 37 ++++++++++++++++++++++++-------------; 1 file changed, 24 insertions(+), 13 deletions(-)","The commit improves literal pool alignment in the s390 BPF JIT compiler to simplify code structure.","alignment,literal pool,s390","A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here.""]" +"4e9b4a6883dd97aff53ae3b08eb900716a5469dc","4e9b4a6883dd97aff53ae3b08eb900716a5469dc","Ilya Leoshkevich","iii@linux.ibm.com","1574100215","Alexei Starovoitov","ast@kernel.org","1574135476","a84b391c76e15be3a752b9fcde7b55fc4e1cd651","a25ecd9d1e60241df905b29fb84765eb74545c4f","s390/bpf: Use relative long branches Currently maximum JITed code size is limited to 64k, because JIT can emit only relative short branches, whose range is limited by 64k in both directions. Teach JIT to use relative long branches. There are no compare+branch relative long instructions, so using relative long branches consumes more space due to having to having to emit an explicit comparison instruction. Therefore do this only when relative short branch is not enough. Signed-off-by: Ilya Leoshkevich Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191118180340.68373-2-iii@linux.ibm.com","arch/s390/net/bpf_jit_comp.c | 158 ++++++++++++++++++++++++++++++++++---------; 1 file changed, 126 insertions(+), 32 deletions(-)","This commit extends the s390 JIT compiler to support longer branch instructions for handling larger code sizes.","s390,JIT,long-branches","A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"a25ecd9d1e60241df905b29fb84765eb74545c4f","a25ecd9d1e60241df905b29fb84765eb74545c4f","Colin Ian King","colin.king@canonical.com","1574077259","Alexei Starovoitov","ast@kernel.org","1574134379","e2a6c5499d70887a01d047fe3a37f80a8dc91e3a","2ea2612b987ad703235c92be21d4e98ee9c2c67c","bpf: Fix memory leak on object 'data' The error return path on when bpf_fentry_test* tests fail does not kfree 'data'. Fix this by adding the missing kfree. Addresses-Coverity: (""Resource leak"") Fixes: faeb2dce084a (""bpf: Add kernel test functions for fentry testing"") Signed-off-by: Colin Ian King Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191118114059.37287-1-colin.king@canonical.com","net/bpf/test_run.c | 4 +++-; 1 file changed, 3 insertions(+), 1 deletion(-)","The commit fixes a memory leak in the bpf_fentry_test error path by adding a missing kfree for the 'data' object.","memory, leak, kfree","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"6960f7e3b2d77ebcb20d5cecdd74d7ca1ed425aa","6960f7e3b2d77ebcb20d5cecdd74d7ca1ed425aa","David S. Miller","davem@davemloft.net","1574125398","David S. Miller","davem@davemloft.net","1574125398","2a814316785aae3350f363e0f510472e30760f1c","b95e86d846b63b02ecdc94802ddbeaf9005fb6d9 832ccf6f80cda06ad2373cd1f40291b0183958b4","Merge branch 'page_pool-followup-changes-to-restore-tracepoint-features' Jesper Dangaard says: ==================== page_pool: followup changes to restore tracepoint features This patchset is a followup to Jonathan patch, that do not release pool until inflight == 0. That changed page_pool to be responsible for its own delayed destruction instead of relying on xdp memory model. As the page_pool maintainer, I'm promoting the use of tracepoint to troubleshoot and help driver developers verify correctness when converting at driver to use page_pool. The role of xdp:mem_disconnect have changed, which broke my bpftrace tools for shutdown verification. With these changes, the same capabilities are regained. ==================== Signed-off-by: David S. Miller ","","The commit merges changes to restore tracepoint features in page_pool, impacting bpftrace tools and driver debugging.","tracepoint,page_pool,bpftrace","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","It's like a merge commit. It includes significant changes across multiple components of the system.","It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.","['Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.']" +"2ea2612b987ad703235c92be21d4e98ee9c2c67c","2ea2612b987ad703235c92be21d4e98ee9c2c67c","Yonghong Song","yhs@fb.com","1574026836","Daniel Borkmann","daniel@iogearbox.net","1574109420","b4a474cffb33b89150e259f0231dd4847094b6ec","3b054b7133b4ad93671c82e8d6185258e3f1a7a5","selftests, bpf: Workaround an alu32 sub-register spilling issue Currently, with latest llvm trunk, selftest test_progs failed obj file test_seg6_loop.o with the following error in verifier: infinite loop detected at insn 76 The byte code sequence looks like below, and noted that alu32 has been turned off by default for better generated codes in general: 48: w3 = 100 49: *(u32 *)(r10 - 68) = r3 ... ; if (tlv.type == SR6_TLV_PADDING) { 76: if w3 == 5 goto -18 ... 85: r1 = *(u32 *)(r10 - 68) ; for (int i = 0; i < 100; i++) { 86: w1 += -1 87: if w1 == 0 goto +5 88: *(u32 *)(r10 - 68) = r1 The main reason for verification failure is due to partial spills at r10 - 68 for induction variable ""i"". Current verifier only handles spills with 8-byte values. The above 4-byte value spill to stack is treated to STACK_MISC and its content is not saved. For the above example: w3 = 100 R3_w=inv100 fp-64_w=inv1086626730498 *(u32 *)(r10 - 68) = r3 R3_w=inv100 fp-64_w=inv1086626730498 ... r1 = *(u32 *)(r10 - 68) R1_w=inv(id=0,umax_value=4294967295,var_off=(0x0; 0xffffffff)) fp-64=inv1086626730498 To resolve this issue, verifier needs to be extended to track sub-registers in spilling, or llvm needs to enhanced to prevent sub-register spilling in register allocation phase. The former will increase verifier complexity and the latter will need some llvm ""hacking"". Let us workaround this issue by declaring the induction variable as ""long"" type so spilling will happen at non sub-register level. We can revisit this later if sub-register spilling causes similar or other verification issues. Signed-off-by: Yonghong Song Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20191117214036.1309510-1-yhs@fb.com","tools/testing/selftests/bpf/progs/test_seg6_loop.c | 4 +++-; 1 file changed, 3 insertions(+), 1 deletion(-)","The commit provides a workaround for a verifier issue in eBPF selftests related to sub-register spilling.","workaround, sub-register, eBPF","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"3b054b7133b4ad93671c82e8d6185258e3f1a7a5","3b054b7133b4ad93671c82e8d6185258e3f1a7a5","Jiri Benc","jbenc@redhat.com","1573821803","Daniel Borkmann","daniel@iogearbox.net","1574109109","6e47271b9f9577ad807cbe6999b4c217a934f7a5","56bf877a508099f16fb78c71a348f39d0dc5fd72","selftests, bpf: Fix test_tc_tunnel hanging When run_kselftests.sh is run, it hangs after test_tc_tunnel.sh. The reason is test_tc_tunnel.sh ensures the server ('nc -l') is run all the time, starting it again every time it is expected to terminate. The exception is the final client_connect: the server is not started anymore, which ensures no process is kept running after the test is finished. For a sit test, though, the script is terminated prematurely without the final client_connect and the 'nc' process keeps running. This in turn causes the run_one function in kselftest/runner.sh to hang forever, waiting for the runaway process to finish. Ensure a remaining server is terminated on cleanup. Fixes: f6ad6accaa99 (""selftests/bpf: expand test_tc_tunnel with SIT encap"") Signed-off-by: Jiri Benc Signed-off-by: Daniel Borkmann Acked-by: Willem de Bruijn Link: https://lore.kernel.org/bpf/60919291657a9ee89c708d8aababc28ebe1420be.1573821780.git.jbenc@redhat.com","tools/testing/selftests/bpf/test_tc_tunnel.sh | 5 +++++; 1 file changed, 5 insertions(+)","Fixes a hanging issue in test_tc_tunnel.sh by ensuring server termination on cleanup during selftest execution.","selftests, fix, cleanup","A bug fix. It primarily resolves a bug or issue in the code.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"56bf877a508099f16fb78c71a348f39d0dc5fd72","56bf877a508099f16fb78c71a348f39d0dc5fd72","Jiri Benc","jbenc@redhat.com","1574108726","Daniel Borkmann","daniel@iogearbox.net","1574109105","62f408a94951ad74eb2c9131a7794365d680bb11","b97e12e594eb3d0fba35c99a83fef56ff692048b","selftests, bpf: xdping is not meant to be run standalone The actual test to run is test_xdping.sh, which is already in TEST_PROGS. The xdping program alone is not runnable with 'make run_tests', it immediatelly fails due to missing arguments. Move xdping to TEST_GEN_PROGS_EXTENDED in order to be built but not run. Fixes: cd5385029f1d (""selftests/bpf: measure RTT from xdp using xdping"") Signed-off-by: Jiri Benc Signed-off-by: Daniel Borkmann Reviewed-by: Alan Maguire Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/4365c81198f62521344c2215909634407184387e.1573821726.git.jbenc@redhat.com","tools/testing/selftests/bpf/Makefile | 4 ++--; 1 file changed, 2 insertions(+), 2 deletions(-)","The commit adjusts xdping in the BPF selftests to be built but not run standalone by moving it to TEST_GEN_PROGS_EXTENDED.","selftests, xdping, Makefile","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"b97e12e594eb3d0fba35c99a83fef56ff692048b","b97e12e594eb3d0fba35c99a83fef56ff692048b","Daniel Borkmann","daniel@iogearbox.net","1574073720","Daniel Borkmann","daniel@iogearbox.net","1574073731","50748951dae082f17a9919dce69ccd78962487bb","2893c996d8ae021611d02906b9e6fcd0c765fba4 5051b384523be92925d13694fabbc6bedf2f907b","Merge branch 'bpf-array-mmap' Andrii Nakryiko says: ==================== This patch set adds ability to memory-map BPF array maps (single- and multi-element). The primary use case is memory-mapping BPF array maps, created to back global data variables, created by libbpf implicitly. This allows for much better usability, along with avoiding syscalls to read or update data completely. Due to memory-mapping requirements, BPF array map that is supposed to be memory-mapped, has to be created with special BPF_F_MMAPABLE attribute, which triggers slightly different memory allocation strategy internally. See patch 1 for details. Libbpf is extended to detect kernel support for this flag, and if supported, will specify it for all global data maps automatically. Patch #1 refactors bpf_map_inc() and converts bpf_map's refcnt to atomic64_t to make refcounting never fail. Patch #2 does similar refactoring for bpf_prog_add()/bpf_prog_inc(). v5->v6: - add back uref counting (Daniel); v4->v5: - change bpf_prog's refcnt to atomic64_t (Daniel); v3->v4: - add mmap's open() callback to fix refcounting (Johannes); - switch to remap_vmalloc_pages() instead of custom fault handler (Johannes); - converted bpf_map's refcnt/usercnt into atomic64_t; - provide default bpf_map_default_vmops handling open/close properly; v2->v3: - change allocation strategy to avoid extra pointer dereference (Jakub); v1->v2: - fix map lookup code generation for BPF_F_MMAPABLE case; - prevent BPF_F_MMAPABLE flag for all but plain array map type; - centralize ref-counting in generic bpf_map_mmap(); - don't use uref counting (Alexei); - use vfree() directly; - print flags with %x (Song); - extend tests to verify bpf_map_{lookup,update}_elem() logic as well. ==================== Signed-off-by: Daniel Borkmann ","","This commit merges changes to support memory-mapping of BPF array maps enhancing performance and usability.","memory-map BPF array","It's like a merge commit. It merges changes from another branch or repository.","Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"5051b384523be92925d13694fabbc6bedf2f907b","5051b384523be92925d13694fabbc6bedf2f907b","Andrii Nakryiko","andriin@fb.com","1574011686","Daniel Borkmann","daniel@iogearbox.net","1574073720","50748951dae082f17a9919dce69ccd78962487bb","7fe74b436236b17ac57e46527166d22bcc230175","selftests/bpf: Add BPF_TYPE_MAP_ARRAY mmap() tests Add selftests validating mmap()-ing BPF array maps: both single-element and multi-element ones. Check that plain bpf_map_update_elem() and bpf_map_lookup_elem() work correctly with memory-mapped array. Also convert CO-RE relocation tests to use memory-mapped views of global data. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20191117172806.2195367-6-andriin@fb.com",".../testing/selftests/bpf/prog_tests/core_reloc.c | 45 +++--; tools/testing/selftests/bpf/prog_tests/mmap.c | 220 +++++++++++++++++++++; tools/testing/selftests/bpf/progs/test_mmap.c | 45 +++++; 3 files changed, 292 insertions(+), 18 deletions(-)","Add self-tests for mmap functionality in BPF array maps with validation for single and multi-element usage.","selftests,BPF,mmap","A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.","Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.","The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"7fe74b436236b17ac57e46527166d22bcc230175","7fe74b436236b17ac57e46527166d22bcc230175","Andrii Nakryiko","andriin@fb.com","1574011685","Daniel Borkmann","daniel@iogearbox.net","1574073719","7caa1d7e4c28ee1b925410be13da037eaee7d902","fc9702273e2edb90400a34b3be76f7b08fa3344b","libbpf: Make global data internal arrays mmap()-able, if possible Add detection of BPF_F_MMAPABLE flag support for arrays and add it as an extra flag to internal global data maps, if supported by kernel. This allows users to memory-map global data and use it without BPF map operations, greatly simplifying user experience. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Song Liu Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20191117172806.2195367-5-andriin@fb.com","tools/lib/bpf/libbpf.c | 32 ++++++++++++++++++++++++++++++--; 1 file changed, 30 insertions(+), 2 deletions(-)","This commit adds support for mmap()-able global data arrays in libbpf by detecting and using the BPF_F_MMAPABLE flag when supported by the kernel.","global,data,mmap","A new feature. It adds a new capability or feature that was not previously present.","Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.","The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.","Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" +"fc9702273e2edb90400a34b3be76f7b08fa3344b","fc9702273e2edb90400a34b3be76f7b08fa3344b","Andrii Nakryiko","andriin@fb.com","1574011684","Daniel Borkmann","daniel@iogearbox.net","1574073719","2b4f1121496869a32b6f82c63a7e37e737b6e356","85192dbf4de08795afe2b88e52a36fc6abfc3dba","bpf: Add mmap() support for BPF_MAP_TYPE_ARRAY Add ability to memory-map contents of BPF array map. This is extremely useful for working with BPF global data from userspace programs. It allows to avoid typical bpf_map_{lookup,update}_elem operations, improving both performance and usability. There had to be special considerations for map freezing, to avoid having writable memory view into a frozen map. To solve this issue, map freezing and mmap-ing is happening under mutex now: - if map is already frozen, no writable mapping is allowed; - if map has writable memory mappings active (accounted in map->writecnt), map freezing will keep failing with -EBUSY; - once number of writable memory mappings drops to zero, map freezing can be performed again. Only non-per-CPU plain arrays are supported right now. Maps with spinlocks can't be memory mapped either. For BPF_F_MMAPABLE array, memory allocation has to be done through vmalloc() to be mmap()'able. We also need to make sure that array data memory is page-sized and page-aligned, so we over-allocate memory in such a way that struct bpf_array is at the end of a single page of memory with array->value being aligned with the start of the second page. On deallocation we need to accomodate this memory arrangement to free vmalloc()'ed memory correctly. One important consideration regarding how memory-mapping subsystem functions. Memory-mapping subsystem provides few optional callbacks, among them open() and close(). close() is called for each memory region that is unmapped, so that users can decrease their reference counters and free up resources, if necessary. open() is *almost* symmetrical: it's called for each memory region that is being mapped, **except** the very first one. So bpf_map_mmap does initial refcnt bump, while open() will do any extra ones after that. Thus number of close() calls is equal to number of open() calls plus one more. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Song Liu Acked-by: John Fastabend Acked-by: Johannes Weiner Link: https://lore.kernel.org/bpf/20191117172806.2195367-4-andriin@fb.com","include/linux/bpf.h | 11 +++--; include/linux/vmalloc.h | 1 +; include/uapi/linux/bpf.h | 3 ++; kernel/bpf/arraymap.c | 58 ++++++++++++++++++++++---; kernel/bpf/syscall.c | 99 ++++++++++++++++++++++++++++++++++++++++--; mm/vmalloc.c | 20 +++++++++; tools/include/uapi/linux/bpf.h | 3 ++; 7 files changed, 183 insertions(+), 12 deletions(-)","The commit adds mmap() support for BPF_MAP_TYPE_ARRAY allowing memory-mapping for improved user-space access and performance.","mmap, BPF_ARRAY, performance","A new feature. It adds a new capability or feature that was not previously present.","Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.","The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.","Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.","[""It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.""]" diff --git a/docs/README.md b/docs/README.md deleted file mode 100644 index 3f4418b..0000000 --- a/docs/README.md +++ /dev/null @@ -1,161 +0,0 @@ - - -Imagine if you can ask every kernel developer to do a completed survey/questionare about a commit/a mail, what can you find with the results? - -This is what you can get from LKLA and quantatively Analysis with our datasets: - -1. **Understand decision-making**: Identify the rationale behind code changes and why specific solutions were chosen. -2. **Evaluate collaboration quality**: Gain insights into how effectively developers communicate and address feedback. -3. **Spot bottlenecks**: Discover inefficiencies in the review, testing, or approval processes that delay progress. -4. **Trace impact on kernel evolution**: Track patterns in feature additions, security fixes, and performance optimizations over time. -5. **Assess developer experience**: Measure satisfaction, difficulties faced, and the level of community support developers feel. -6. **Monitor subsystem stability**: Identify which kernel areas are frequently changing versus more stable and robust ones. -7. **Enhance tooling feedback**: Understand which tools help or hinder productivity, leading to potential improvements. - -We are trying to turn impossible into possible with AI, changing weeks of work into minutes. - -## Example report: eBPF - -QUESTIONS and insights: - -see the full lists in - -### Datasets with eBPF: Linux BPF subsystem - -- 680+ eBPF expert seleted Important feature commits information, with feature name, type(Map, helper, kfunc, prog, attach, etc...) -- bpf related feature commits information, with LLM Agent survey and summary -- 120000+ All bpf subsystem related mails, with LLM Agent survey -- vector index for all of them - -All the datasets are automatically updated by CI! The interative analysis is on the way to deployment... - -The result can be found in [report_ebpf.md](docs/report_ebpf.md). - -## Workflow/Method: - -``` -[Human Experts design survey] -> [LLM Agent complete survey] -> [Human Experts (LLM) evaluate survey results samples] -> [Human Experts (LLM) give the report] -``` - -Best practice for design survey: - -- No `ChatBot`! No `Document Search!`! No `Code Generation!` -- Survey will also be used as the prompt and action workflow for LLM Agent, so it does require prompt engineering with domain knowledge. -- Do not let LLM Answer any opening questions require domain knowledge. -- let LLM do summary, choice or say yes/no. -- Use traditional method and human expert to evaluate the results. - -It will be better to work with Human Experts to get better results in 2024, but LLM Agent can also help you if you are not human experts. - -## why llm? - -- Researcher has proved that LLM can acheive similar level as human when doing summary/survey/questionare task in Market, Chemistry... Such system is also deployed and explored in production for... (See the citation) -- why not other methods? - - domain knowledge (cite) - - unstructured data（cite） - - human expert is too expensive and impossible for such task - -What question can llm help answer but other cannot? - -- bug... - - -## How to design a survey? - -An example survey for eBPF commits: - -```yml -title: "Commit Classification Survey" -description: "A survey about the type, use cases and summary of commit in Linux eBPF." -questions: -- id: summary - type: fill_in - question: "Please provide a summary of the commit in one short sentence not longer than 30 words. Only output one sentence." - required: true - -- id: keywords - type: fill_in - question: "Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters." - required: true - -- id: commit_classification - type: single_choice - question: "What may be the main type of the commit?" - choices: - - value: It's a bug fix. - - value: It's a new feature. - - value: It's a performance optimization. - - value: It's a cleanup or refactoring in the code. - - value: It's a documentation change or typo fix. - - value: It's a test case or test infrastructure change. - - value: It's a build system or CI/CD change. - - value: It's a security fix. - - value: It's other type of commit. - -- id: commit_complexity - type: single_choice - question: "What is the estimated complexity of implementing this commit?" - choices: - - value: Simple can be used without much configuration. For example a simple helper function. - - value: Moderate requires some setup or understanding of the system. For example a new map type or a new link type. - - value: Complex needs expert knowledge or significant changes to existing systems. Like adding a completely new subsystem support or a completely new program type don't exist before. - - value: It's a merge commit not related to any of the above. - -- id: Major related implementation component - type: single_choice - question: "What major implementation component that the commit is modified on?" - choices: - - value: The eBPF verifier - - value: The eBPF JIT compiler for different architectures - - value: The helper and kfuncs - - value: The syscall interface - - value: The eBPF maps - - value: The libbpf library - - value: The bpftool utility - - value: The test cases and makefiles - - value: The attach events e.g. perf events tracepoints network HID LSM etc. This should be the modify on the event implements, e.g. change how uprobe works. - - value: Other implementation component related to eBPF but not listed above. - - value: It's a merge commit including changes to multiple implementation components. - - value: It's not related to any of the above it's not related to bpf subsystem in Linux kernel may be wrong data. - -- id: Major related logic component - type: single_choice - question: "What major logic component that the commit is related to? logic component is different to implementation component." - choices: - - value: A eBPF Instruction Logic for adding fixing or updating the way eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel. e.g. add fix optimized eBPF instructions. - - value: A eBPF Program Logic related to different eBPF program types (e.g. XDP tc kprobes) and how the kernel manages attaches and runs these programs. e.g. add eBPF program type fix things related to eBPF program. - - value: Runtime features Logic related to eBPF helper or kfunc functions which provide access to kernel resources from eBPF programs (e.g. reading from maps manipulating packet data). e.g. helpers kfuncs etc. - - value: eBPF events Logic for handling events that trigger eBPF programs such as network packet reception system calls or tracing events. e.g. add new event fix things related to XDP HID perf events tracepoint etc. - - value: Control Plane interface Logic for userspace control. This involves adding fixing or modifying syscalls that are part of the control plane interface for eBPF allowing userspace programs to interact with eBPF features in the kernel. - - value: Maps Logic for how eBPF maps (data structures shared between kernel and user space) are created accessed and managed. - - value: BPF Type Format (BTF) Logic. e.g. add fix things related to BTF, changes how eBPF programs are CO-RE, using BTF for verifier etc. - - value: It's a merge commit including changes to multiple logic components. - -- id: usecases_or_events - type: multiple_choice - question: "What eBPF usecases/events may the commit relate to and designed for?" - choices: - - value: xdp related type programs - - value: socket related type programs - - value: tc related type programs - - value: netfilter related type programs - - value: tracepoints related type programs - - value: kprobe/ftrace like type kernel dynamic probe programs - - value: uprobe/usdt like type user space dynamic probe programs - - value: profile related type programs - - value: LSM type relatde programs - - value: cgroup type related programs - - value: HID driver related type programs - - value: scheduler relatde type programs - - value: It improves the overall eBPF infrastructure (e.g. verifier runtime etc.) - - value: It's an experimental feature that doesn't fit into existing categories. - - value: It's not related to any of the above. - - value: other type of usecases/bpf programs not listed above. -``` - -## reference - -1. kernel mail - 1. [How to Communicate when Submitting Patches: An Empirical Study of the Linux Kernel](https://dl.acm.org/doi/abs/10.1145/3359210?casa_token=5CrG9X-8QNgAAAAA:mm-N0p2baZSzxgfNbBcSi5HYBF67jdM7VZlJfTbhI2ht2cv1oCHRSL_FRPmM7DHr6ISpV91szCTOEg) - 2. [Differentiating Communication Styles of Leaders on the Linux Kernel Mailing List](https://dl.acm.org/doi/abs/10.1145/2957792.2957801?casa_token=VMchS_jhea0AAAAA:EubJDL_ftM5jmV3_yzwWzDLvLq8hAsexZnss1x3j754OZr4VNENST_tSl0ijQEBnVg5AaFWpZGf3kQ) - diff --git a/docs/distribute.txt b/docs/distribute.txt index 8ca7a0c..ccb7609 100644 --- a/docs/distribute.txt +++ b/docs/distribute.txt @@ -1,4 +1,4 @@ -Total number of commits: 10567 +Total number of commits: 11013 Analyzing the distribution of all fields related to the survey to understand the overall commit characteristics and identify potential areas of focus or concern. By analyzing the commit classification distribution, we can identify the types of changes most frequently made. This helps in understanding the development priorities and ensuring that the commit classifications are consistent. @@ -13,14 +13,14 @@ Assessing the major related logic component distribution provides insights into Commit Classification Distribution: commit_classification -A bug fix. It primarily resolves a bug or issue in the code. 2320 -A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality. 2238 -A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure. 1933 -A new feature. It adds a new capability or feature that was not previously present. 1614 -It's like a merge commit. It merges changes from another branch or repository. 1309 -A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error. 534 -A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput. 276 -A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines. 263 +A bug fix. It primarily resolves a bug or issue in the code. 2419 +A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality. 2347 +A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure. 1991 +A new feature. It adds a new capability or feature that was not previously present. 1691 +It's like a merge commit. It merges changes from another branch or repository. 1368 +A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error. 551 +A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput. 287 +A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines. 279 A security fix. It resolves a security vulnerability or strengthens security measures. 46 It's other type of commit. It does not fit into any of the categories listed above. 33 I'm not sure about the type of the commit. The nature of It is unclear or uncertain. 1 @@ -28,44 +28,44 @@ Name: count, dtype: int64 Commit Complexity Distribution: commit_complexity -Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system. 5943 -Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge. 2841 -Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix. 1307 -Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge. 461 +Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system. 6191 +Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge. 2956 +Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix. 1367 +Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge. 483 Non-code or generated. The changes involve auto-generated code or dependency updates or large formatting commits. which may affect many lines but do not reflect typical code complexity. 10 -I'm not sure about the complexity of the commit. It is difficult to estimate the complexity based on the provided commit details. 5 +I'm not sure about the complexity of the commit. It is difficult to estimate the complexity based on the provided commit details. 6 Name: count, dtype: int64 Major Related Implementation Component Distribution: major_related_implementation_component -The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs. 2890 -The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications. 1349 -The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events. 1248 -It's like a merge commit. It includes significant changes across multiple components of the system. 951 -The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel. 749 -It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem. 606 -It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed. 595 -The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call. 583 -The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures. 448 -The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed. 442 -The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps. 429 -The syscall interface. It changes the system calls through which user-space programs interact with eBPF. 234 +The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs. 2976 +The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications. 1425 +The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events. 1324 +It's like a merge commit. It includes significant changes across multiple components of the system. 998 +The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel. 767 +It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem. 627 +It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed. 612 +The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call. 599 +The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed. 472 +The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures. 465 +The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps. 460 +The syscall interface. It changes the system calls through which user-space programs interact with eBPF. 245 I'm not sure about the implementation component of the commit. The component affected by It is unclear. 43 Name: count, dtype: int64 Major Related Logic Component Distribution: major_related_logic_component -The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF. 3383 -Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations. 1566 -eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs. 1147 -A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel. 1051 -It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches. 965 -It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed. 591 -Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel. 587 -Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space. 529 -BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF. 458 -It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events. 224 -I'm not sure about the logic component of the commit. The affected logic component is unclear. 66 +The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF. 3520 +Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations. 1623 +eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs. 1209 +A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel. 1075 +It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches. 1011 +Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel. 619 +It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed. 608 +Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space. 568 +BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF. 478 +It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events. 235 +I'm not sure about the logic component of the commit. The affected logic component is unclear. 67 Name: count, dtype: int64 @@ -79,7 +79,7 @@ Similarly, analyzing the logic components for merge commits helps us ensure that Merge Commit Complexity Distribution: commit_complexity -Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix. 1297 +Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix. 1356 Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge. 7 Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system. 3 I'm not sure about the complexity of the commit. It is difficult to estimate the complexity based on the provided commit details. 1 @@ -88,34 +88,34 @@ Name: count, dtype: int64 Merge Commit Implementation Component Distribution: major_related_implementation_component -It's like a merge commit. It includes significant changes across multiple components of the system. 951 -The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications. 80 -The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events. 51 +It's like a merge commit. It includes significant changes across multiple components of the system. 997 +The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications. 84 +The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events. 54 It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed. 40 The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel. 39 -The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs. 34 +The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs. 35 The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call. 26 -It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem. 21 -The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed. 20 -The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps. 14 -The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures. 13 +It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem. 22 +The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed. 21 +The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps. 16 +The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures. 14 I'm not sure about the implementation component of the commit. The component affected by It is unclear. 13 The syscall interface. It changes the system calls through which user-space programs interact with eBPF. 7 Name: count, dtype: int64 Merge Commit Logic Component Distribution: major_related_logic_component -It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches. 965 -The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF. 63 -Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations. 60 -eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs. 53 -A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel. 42 -It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed. 40 -Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space. 29 -Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel. 27 -BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF. 21 -I'm not sure about the logic component of the commit. The affected logic component is unclear. 6 -It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events. 3 +It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches. 1011 +The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF. 66 +Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations. 62 +eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs. 57 +A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel. 43 +It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed. 40 +Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space. 30 +Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel. 29 +BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF. 21 +I'm not sure about the logic component of the commit. The affected logic component is unclear. 6 +It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events. 3 Name: count, dtype: int64 @@ -127,12 +127,12 @@ Assessing the implementation in other subsystems related to eBPF events helps us Distribution of eBPF Events Related Logic: major_related_logic_component -eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs. 1147 +eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs. 1209 Name: count, dtype: int64 Distribution of Implementation in Other Subsystems Related to eBPF Events: major_related_implementation_component -The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events. 1248 +The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events. 1324 Name: count, dtype: int64 We will now delve deeper by analyzing the 'usecases_or_submodule_events' field to understand the specific use cases or events that commits relate to. This analysis helps in verifying consistency between the use cases/events and the related logic or implementation components. @@ -143,42 +143,42 @@ since this is a muplti-choice field, we will parse the string representation of By parsing the 'usecases_or_submodule_events' field, we can accurately count the occurrences of each use case or event, which is essential for understanding the distribution and ensuring consistency in classifications. Distribution of Use Cases or Submodule Events: -It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime. 5682 -Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic. 918 -It's likely a merge commit. It involves changes across multiple use cases or events. 867 -It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed. 758 -XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework. 674 -Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing. 501 -kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events. 342 -I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear. 316 -It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here. 217 -cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups). 212 -uprobe/usdt like type user-space dynamic probe programs. It impacts user-space probes for tracing user-space applications. It can be other user-space probes in perf-events. 165 -tc related type programs. It affects programs managing traffic control (tc) for queuing or prioritizing network traffic. 161 -Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems. 140 -Profile related type programs. It affects programs used for profiling system or application performance. 138 -LSM type related programs. It relates to eBPF programs used with Linux Security Modules (LSMs) for security enhancements. 114 +It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime. 5905 +Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic. 978 +It's likely a merge commit. It involves changes across multiple use cases or events. 907 +It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed. 777 +XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework. 722 +Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing. 527 +kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events. 356 +I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear. 335 +cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups). 227 +It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here. 222 +uprobe/usdt like type user-space dynamic probe programs. It impacts user-space probes for tracing user-space applications. It can be other user-space probes in perf-events. 167 +tc related type programs. It affects programs managing traffic control (tc) for queuing or prioritizing network traffic. 164 +Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems. 150 +Profile related type programs. It affects programs used for profiling system or application performance. 143 +LSM type related programs. It relates to eBPF programs used with Linux Security Modules (LSMs) for security enhancements. 118 HID driver related type programs. It relates to programs interacting with HID (Human Interface Devices) for input/output events. 113 -Netfilter related type programs. It impacts programs interacting with the Netfilter framework used in packet filtering and NAT. 82 -Scheduler related type programs. It modifies programs that interact with kernel-level scheduling mechanisms. 32 +Netfilter related type programs. It impacts programs interacting with the Netfilter framework used in packet filtering and NAT. 83 +Scheduler related type programs. It modifies programs that interact with kernel-level scheduling mechanisms. 33 Name: count, dtype: int64 Cross-analyzing the use cases with the 'eBPF events related Logic' commits to check for consistency in data labeling. Use Cases within eBPF Events Related Logic: -XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework. 307 -Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic. 287 -Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing. 211 -kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events. 153 -I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear. 143 -It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime. 90 -Profile related type programs. It affects programs used for profiling system or application performance. 83 -tc related type programs. It affects programs managing traffic control (tc) for queuing or prioritizing network traffic. 46 -Netfilter related type programs. It impacts programs interacting with the Netfilter framework used in packet filtering and NAT. 38 +XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework. 336 +Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic. 308 +Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing. 222 +kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events. 157 +I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear. 151 +It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime. 91 +Profile related type programs. It affects programs used for profiling system or application performance. 87 +tc related type programs. It affects programs managing traffic control (tc) for queuing or prioritizing network traffic. 47 +Netfilter related type programs. It impacts programs interacting with the Netfilter framework used in packet filtering and NAT. 39 HID driver related type programs. It relates to programs interacting with HID (Human Interface Devices) for input/output events. 38 -uprobe/usdt like type user-space dynamic probe programs. It impacts user-space probes for tracing user-space applications. It can be other user-space probes in perf-events. 30 +uprobe/usdt like type user-space dynamic probe programs. It impacts user-space probes for tracing user-space applications. It can be other user-space probes in perf-events. 31 +It's likely a merge commit. It involves changes across multiple use cases or events. 28 It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here. 28 -It's likely a merge commit. It involves changes across multiple use cases or events. 26 cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups). 20 LSM type related programs. It relates to eBPF programs used with Linux Security Modules (LSMs) for security enhancements. 14 Scheduler related type programs. It modifies programs that interact with kernel-level scheduling mechanisms. 13 @@ -191,31 +191,31 @@ This analysis helps us determine whether the use cases specified in the commits Similarly, cross-analyzing the use cases with commits involving Implementation in Other Subsystems related to eBPF events. Use Cases within Implementation in Other Subsystems Related to eBPF Events: -Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic. 301 -XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework. 293 -Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing. 190 -It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime. 151 -I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear. 132 -kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events. 123 -Profile related type programs. It affects programs used for profiling system or application performance. 87 +Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic. 329 +XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework. 322 +Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing. 198 +It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime. 159 +I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear. 142 +kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events. 128 +Profile related type programs. It affects programs used for profiling system or application performance. 90 HID driver related type programs. It relates to programs interacting with HID (Human Interface Devices) for input/output events. 58 It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here. 48 -cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups). 40 +cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups). 41 tc related type programs. It affects programs managing traffic control (tc) for queuing or prioritizing network traffic. 39 -Netfilter related type programs. It impacts programs interacting with the Netfilter framework used in packet filtering and NAT. 32 -It's likely a merge commit. It involves changes across multiple use cases or events. 30 -uprobe/usdt like type user-space dynamic probe programs. It impacts user-space probes for tracing user-space applications. It can be other user-space probes in perf-events. 24 -LSM type related programs. It relates to eBPF programs used with Linux Security Modules (LSMs) for security enhancements. 20 +Netfilter related type programs. It impacts programs interacting with the Netfilter framework used in packet filtering and NAT. 33 +It's likely a merge commit. It involves changes across multiple use cases or events. 32 +uprobe/usdt like type user-space dynamic probe programs. It impacts user-space probes for tracing user-space applications. It can be other user-space probes in perf-events. 25 +LSM type related programs. It relates to eBPF programs used with Linux Security Modules (LSMs) for security enhancements. 21 It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed. 18 Scheduler related type programs. It modifies programs that interact with kernel-level scheduling mechanisms. 13 -Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems. 11 +Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems. 12 Name: count, dtype: int64 By comparing these distributions, we can identify any discrepancies in data labeling and ensure that the commits are consistently classified across different fields, enhancing data correctness and reliability. Identifying any inconsistencies where commits classified as 'eBPF events related Logic' do not have corresponding event-related use cases. -Number of commits with 'eBPF events related Logic' but without corresponding event-related use cases: 124 +Number of commits with 'eBPF events related Logic' but without corresponding event-related use cases: 125 Sample commit messages of inconsistent commits: 80 selftests/bpf: Test for null-pointer-deref bug... @@ -259,8 +259,8 @@ Name: commit_message, dtype: object 5. Checking for consistency by finding commits classified as merge but not marked as merge in Implementation or Logic components. This helps in identifying any discrepancies in commit classification. -Number of mismatches in implementation: 358 (27.35% of merge commits) -Number of mismatches in logic: 344 (26.28% of merge commits) +Number of mismatches in implementation: 371 (27.12% of merge commits) +Number of mismatches in logic: 357 (26.10% of merge commits) Analyzing these mismatches helps ensure that merges are consistently classified across different fields, which is essential for data correctness and consistency. @@ -292,18 +292,18 @@ Name: commit_message, dtype: object 6. Mismatch Analysis: -Total number of commits: 10567 -Total number of merge commits: 1309 -Number of mismatches in implementation: 358 (27.35% of merge commits) -Number of mismatches in logic: 344 (26.28% of merge commits) +Total number of commits: 11013 +Total number of merge commits: 1368 +Number of mismatches in implementation: 371 (27.12% of merge commits) +Number of mismatches in logic: 357 (26.10% of merge commits) This analysis helps in quantifying the extent of inconsistencies in the data, which is crucial for improving data quality and ensuring accurate analyses. 7. 'Not related to BPF subsystem' Analysis: Calculating the number of commits marked as 'Not related to BPF subsystem' to evaluate the presence of irrelevant data that may affect the correctness of our analysis. -Number of commits marked as 'Not related to BPF subsystem' in Implementation Component: 1201 (11.37% of total commits) -Number of commits marked as 'Not related to BPF subsystem' in Logic Component: 815 (7.71% of total commits) +Number of commits marked as 'Not related to BPF subsystem' in Implementation Component: 1239 (11.25% of total commits) +Number of commits marked as 'Not related to BPF subsystem' in Logic Component: 843 (7.65% of total commits) There is a significant number of commits marked as 'Not related to BPF subsystem'. This indicates potential data quality issues and suggests that data cleaning may be necessary to improve analysis correctness. diff --git a/docs/report_ebpf.md b/docs/report_ebpf.md index a94e33d..9302c1b 100644 --- a/docs/report_ebpf.md +++ b/docs/report_ebpf.md @@ -410,13 +410,83 @@ Sample Commit Messages of 'Not related to BPF subsystem' in Implementation Compo - **Data Correction:** Unrelated commits can be excluded by refining the filtering criteria after processing and before analysis. Manual review can also help identify and remove irrelevant commits - **Conclusion:** The presence of commits not related to the BPF subsystem is due to the broad filtering method. By adjusting the filtering approach, we can exclude unrelated data and improve the accuracy of our analysis. -## Consistency Across Similar Questions +### Consistency Across Similar Questions -**Question:** Are similar questions answered consistently across different but related features or subsystems? -**Approach:** We plan to analyze the consistency of responses for similar features or subsystems. +- Are similar questions answered consistently across different but related features or subsystems? -**Method:** We will examine responses related to multiple similar features and subsystems, looking for significant contradictions or inconsistencies. If inconsistencies arise, we will investigate whether they are contextually justified or due to survey design flaws. +Our method involved selecting pairs of closely related questions and comparing the distribution of responses. Specifically, we focused on: + +- Commit classifications and their corresponding complexities. +- Major related implementation components and logic components. + +We looked for alignment in responses to assess consistency. In cases where inconsistencies were detected, we investigated whether they were contextually justified or indicative of misclassification or survey design flaws. + +See the generated `distribute.txt` as example, we have 10000+ commits: + +#### Example 1: Merge Commits + +- **Commit Classification:** "It's like a merge commit." (1,347 responses) +- **Commit Complexity:** "Merge-like. The commit merges branches." (1,346 responses) + +Responses were nearly identical, showing high consistency in identifying merge commits. + +#### Example 2: Unrelated Components + +- **Implementation Component:** "Not related to BPF. A rare case of wrong data." (606 responses) +- **Logic Component:** "Not related to BPF. A rare case of wrong data." (602 responses) + +The close match (606 vs. 602) indicates consistency in identifying unrelated components. + +Given that our dataset comprises over 10,000 commits, the observed discrepancies represent less than `0.05% misclassification` in a single iteration. Such a low rate of inconsistency suggests that the overall data quality is high. Conducting multiple iterations of the survey and averaging the results can further enhance accuracy, minimizing the impact of any outliers or misclassifications. + +Our analysis indicates that similar questions are answered consistently across different but related features or subsystems. The consistency observed in the provided examples demonstrates that respondents are reliably interpreting and classifying commits in a uniform manner. While minor inconsistencies exist, they are minimal and do not significantly affect the overall quality of the data. This consistency supports the validity of our survey design and the reliability of the conclusions drawn from the data. + +## The timeline analysis of commits + +The timeline analysis of commits provides insights into the evolution of the eBPF subsystem over time. By visualizing the distribution of commit types, complexities, and major components across different periods, we can identify trends and patterns in the development of eBPF features. + +In this step, we: + +1. clean the data and removed any irrelevant commits. +2. Smooth the data and show Avg in 3M to reduce noise and highlight long-term trends. +3. `Merge` commits related to single ccomponent are treated as regular commits. `Merge` commits across multiple ccomponent are removed(like mainline merge). and the y xis is the commit count(May be able to improve) + +### Commit Classification Over Time + +![imgs/timeline_commit_classification_smoothed.png](../imgs/timeline_commit_classification_smoothed.png) + + +### Commit related to Major Implementation Component Over Time + +![imgs/timeline_major_related_implementation_component_smoothed.png](../imgs/timeline_major_related_implementation_component_smoothed.png) + +### Commit related to Major Logic Component Over Time + +![imgs/timeline_major_related_logic_component_smoothed.png](../imgs/timeline_major_related_logic_component_smoothed.png) + +### Use cases or events Over Time + +![imgs/timeline_usecases_or_submodule_events_smoothed.png](../imgs/timeline_usecases_or_submodule_events_smoothed.png) + +### Commit Complexity Over Time + +![](../imgs/timeline_commit_complexity_smoothed.png) + +## Deeper insight Analysis + +In this section, we will delve deeper into the survey responses to identify patterns, trends, and potential areas for improvement. + + +### Verifier bugs or features related to eBPF Instruction + +By analyzing the survey responses related to the eBPF verifier, we can gain insights into the prevalence of bugs and features related to the instruction set. + +![imgs/instruction_verifier_features_bugs_over_time.png](../imgs/instruction_verifier_features_bugs_over_time.png) + +### The evolution and status of libbpf + +![imgs/timeline_libbpf_commit_classification_smoothed.png](../imgs/timeline_libbpf_commit_classification_smoothed.png) ## Coverage of Survey Questions diff --git a/imgs/instruction_verifier_features_bugs_over_time.png b/imgs/instruction_verifier_features_bugs_over_time.png index c1fa367..83fcf82 100644 Binary files a/imgs/instruction_verifier_features_bugs_over_time.png and b/imgs/instruction_verifier_features_bugs_over_time.png differ diff --git a/imgs/timeline_commit_classification_smoothed.png b/imgs/timeline_commit_classification_smoothed.png index 3c6f539..5441ff8 100644 Binary files a/imgs/timeline_commit_classification_smoothed.png and b/imgs/timeline_commit_classification_smoothed.png differ diff --git a/imgs/timeline_commit_complexity_smoothed.png b/imgs/timeline_commit_complexity_smoothed.png index 40368ff..abd295c 100644 Binary files a/imgs/timeline_commit_complexity_smoothed.png and b/imgs/timeline_commit_complexity_smoothed.png differ diff --git a/imgs/timeline_libbpf_commit_classification_smoothed.png b/imgs/timeline_libbpf_commit_classification_smoothed.png index 03525df..4871f26 100644 Binary files a/imgs/timeline_libbpf_commit_classification_smoothed.png and b/imgs/timeline_libbpf_commit_classification_smoothed.png differ diff --git a/imgs/timeline_major_related_implementation_component_smoothed.png b/imgs/timeline_major_related_implementation_component_smoothed.png index d7f0ee8..ed525d9 100644 Binary files a/imgs/timeline_major_related_implementation_component_smoothed.png and b/imgs/timeline_major_related_implementation_component_smoothed.png differ diff --git a/imgs/timeline_major_related_logic_component_smoothed.png b/imgs/timeline_major_related_logic_component_smoothed.png index 33e0a6e..033e646 100644 Binary files a/imgs/timeline_major_related_logic_component_smoothed.png and b/imgs/timeline_major_related_logic_component_smoothed.png differ diff --git a/imgs/timeline_usecases_or_submodule_events_smoothed.png b/imgs/timeline_usecases_or_submodule_events_smoothed.png index 7f072f2..ac3dfa2 100644 Binary files a/imgs/timeline_usecases_or_submodule_events_smoothed.png and b/imgs/timeline_usecases_or_submodule_events_smoothed.png differ diff --git a/output_commit_survey1.txt b/output_commit_survey1.txt index dee9d01..3e6f0bf 100644 --- a/output_commit_survey1.txt +++ b/output_commit_survey1.txt @@ -45011,3 +45011,38557 @@ new content: -------------------- -------------------- Processing Commit 346/6895 - Commit ID: 24a6034acc922f1f6292636be4ec4dc3d9b4d2d7 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 24a6034acc922f1f6292636be4ec4dc3d9b4d2d7 + Author Name: Daniel T. Lee + Author Email: danieltimlee@gmail.com + Commit Date: 1584998871 + Commit Message: + samples, bpf: Move read_trace_pipe to trace_helpers To reduce the reliance of trace samples (trace*_user) on bpf_load, move read_trace_pipe to trace_helpers. By moving this bpf_loader helper elsewhere, trace functions can be easily migrated to libbbpf. Signed-off-by: Daniel T. Lee Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200321100424.1593964-2-danieltimlee@gmail.com + Changed Files: samples/bpf/Makefile | 4 ++--; samples/bpf/bpf_load.c | 20 --------------------; samples/bpf/bpf_load.h | 1 -; samples/bpf/tracex1_user.c | 1 +; samples/bpf/tracex5_user.c | 1 +; tools/testing/selftests/bpf/trace_helpers.c | 23 +++++++++++++++++++++++; tools/testing/selftests/bpf/trace_helpers.h | 1 +; 7 files changed, 28 insertions(+), 23 deletions(-) + Parent Hashes: c9b24312040edaa89acb6fb91a9a53fb4775309e +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit moves the 'read_trace_pipe' function from 'bpf_load' to 'trace_helpers' to facilitate easier migration of trace functions to libbbpf.", + "keywords": "trace_helpers,bpf_load,libbbpf", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing." + ] +} +Rethinking... +new content: +{ + "summary": "This commit moves 'read_trace_pipe' from 'bpf_load' to 'trace_helpers' improving trace function migration to libbbpf.", + "keywords": "trace_helpers,bpf_load,libbbpf", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing." + ] +} +-------------------- +-------------------- +Processing Commit 347/6895 - Commit ID: c9b24312040edaa89acb6fb91a9a53fb4775309e +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: c9b24312040edaa89acb6fb91a9a53fb4775309e + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1584993115 + Commit Message: + bpf: Add tests for bpf_sk_storage to bpf_tcp_ca This patch adds test to exercise the bpf_sk_storage_get() and bpf_sk_storage_delete() helper from the bpf_dctcp.c. The setup and check on the sk_storage is done immediately before and after the connect(). This patch also takes this chance to move the pthread_create() after the connect() has been done. That will remove the need of the "wait_thread" label. Signed-off-by: Martin KaFai Lau Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200320152107.2169904-1-kafai@fb.com + Changed Files: .../testing/selftests/bpf/prog_tests/bpf_tcp_ca.c | 39 +++++++++++++++++-----; tools/testing/selftests/bpf/progs/bpf_dctcp.c | 16 +++++++++; 2 files changed, 47 insertions(+), 8 deletions(-) + Parent Hashes: ab14fd4ee82ead4b058034509971b8bd749862ff +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds tests for bpf_sk_storage in bpf_tcp_ca and refines their setup during connection handling.", + "keywords": "tests sk_storage bpf_tcp_ca", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds test cases for bpf_sk_storage to bpf_tcp_ca in eBPF.", + "keywords": "tests bpf_sk_storage bpf_tcp_ca", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +-------------------- +-------------------- +Processing Commit 348/6895 - Commit ID: ab14fd4ee82ead4b058034509971b8bd749862ff +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: ab14fd4ee82ead4b058034509971b8bd749862ff + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1584993115 + Commit Message: + bpf: Add bpf_sk_storage support to bpf_tcp_ca This patch adds bpf_sk_storage_get() and bpf_sk_storage_delete() helper to the bpf_tcp_ca's struct_ops. That would allow bpf-tcp-cc to: 1) share sk private data with other bpf progs. 2) use bpf_sk_storage as a private storage for a bpf-tcp-cc if the existing icsk_ca_priv is not big enough. Signed-off-by: Martin KaFai Lau Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200320152101.2169498-1-kafai@fb.com + Changed Files: net/ipv4/bpf_tcp_ca.c | 33 +++++++++++++++++++++++++++++++++; 1 file changed, 33 insertions(+) + Parent Hashes: 1440e7929392297f1578a54f372e9821bb1b0658 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds bpf_sk_storage support to bpf_tcp_ca for sharing sk private data and using private storage.", + "keywords": "bpf_sk_storage,bpf_tcp_ca,struct_ops", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit enhances bpf_tcp_ca by adding support for bpf_sk_storage to share or store private data.", + "keywords": "bpf_sk_storage,bpf_tcp_ca,struct_ops", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 349/6895 - Commit ID: 443bc639e518c6c4e8fc2e0456cccf3a04f6e77f +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 443bc639e518c6c4e8fc2e0456cccf3a04f6e77f + Author Name: Jin Yao + Author Email: yao.jin@linux.intel.com + Commit Date: 1584972509 + Commit Message: + perf report: Print al_addr when symbol is not found For branch mode, if the symbol is not found, it prints the address. For example, 0x0000555eee0365a0 in below output. Overhead Command Source Shared Object Source Symbol Target Symbol 17.55% div libc-2.27.so [.] __random [.] __random 6.11% div div [.] 0x0000555eee0365a0 [.] rand 6.10% div libc-2.27.so [.] rand [.] 0x0000555eee036769 5.80% div libc-2.27.so [.] __random_r [.] __random 5.72% div libc-2.27.so [.] __random [.] __random_r 5.62% div libc-2.27.so [.] __random_r [.] __random_r 5.38% div libc-2.27.so [.] __random [.] rand 4.56% div libc-2.27.so [.] __random [.] __random 4.49% div div [.] 0x0000555eee036779 [.] 0x0000555eee0365ff 4.25% div div [.] 0x0000555eee0365fa [.] 0x0000555eee036760 But it's not very easy to understand what the instructions are in the binary. So this patch uses the al_addr instead. With this patch, the output is Overhead Command Source Shared Object Source Symbol Target Symbol 17.55% div libc-2.27.so [.] __random [.] __random 6.11% div div [.] 0x00000000000005a0 [.] rand 6.10% div libc-2.27.so [.] rand [.] 0x0000000000000769 5.80% div libc-2.27.so [.] __random_r [.] __random 5.72% div libc-2.27.so [.] __random [.] __random_r 5.62% div libc-2.27.so [.] __random_r [.] __random_r 5.38% div libc-2.27.so [.] __random [.] rand 4.56% div libc-2.27.so [.] __random [.] __random 4.49% div div [.] 0x0000000000000779 [.] 0x00000000000005ff 4.25% div div [.] 0x00000000000005fa [.] 0x0000000000000760 Now we can use objdump to dump the object starting from 0x5a0. For example, objdump -d --start-address 0x5a0 div 00000000000005a0 : 5a0: ff 25 2a 0a 20 00 jmpq *0x200a2a(%rip) # 200fd0 <__cxa_finalize@plt+0x200a20> 5a6: 68 02 00 00 00 pushq $0x2 5ab: e9 c0 ff ff ff jmpq 570 ... Committer testing: [root@seventh ~]# perf record -a -b sleep 1 [root@seventh ~]# perf report --header-only | grep cpudesc # cpudesc : Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz [root@seventh ~]# perf evlist -v cycles: size: 120, { sample_period, sample_freq }: 4000, sample_type: IP|TID|TIME|CPU|PERIOD|BRANCH_STACK, read_format: ID, disabled: 1, inherit: 1, mmap: 1, comm: 1, freq: 1, task: 1, precise_ip: 3, sample_id_all: 1, exclude_guest: 1, mmap2: 1, comm_exec: 1, ksymbol: 1, bpf_event: 1, branch_sample_type: ANY [root@seventh ~]# Before: [root@seventh ~]# perf report --stdio --dso libsystemd-shared-241.so | head -20 # To display the perf.data header info, please use --header/--header-only options. # # # Total Lost Samples: 0 # # Samples: 2K of event 'cycles' # Event count (approx.): 2240 # # Overhead Command Source Shared Object Source Symbol Target Symbol Basic Block Cycles # ........ ............... ........................ ...................... ...................... .................. # 0.13% systemd-journal libc-2.29.so [.] cfree@GLIBC_2.2.5 [.] _int_free 1 0.09% systemd libsystemd-shared-241.so [.] 0x00007fe406465c82 [.] 0x00007fe406465d80 1 0.09% systemd libsystemd-shared-241.so [.] 0x00007fe406465ded [.] 0x00007fe406465c30 1 0.09% systemd libsystemd-shared-241.so [.] 0x00007fe406465e4e [.] 0x00007fe406465de0 1 0.09% systemd-journal systemd-journald [.] free@plt [.] cfree@GLIBC_2.2.5 1 0.09% systemd-journal libc-2.29.so [.] _int_free [.] _int_free 18 0.09% systemd-journal libc-2.29.so [.] _int_free [.] _int_free 2 0.04% systemd libsystemd-shared-241.so [.] bus_resolve@plt [.] bus_resolve 204 0.04% systemd libsystemd-shared-241.so [.] getpid_cached@plt [.] getpid_cached 7 [root@seventh ~]# After: [root@seventh ~]# perf report --stdio --dso libsystemd-shared-241.so | head -20 # To display the perf.data header info, please use --header/--header-only options. # # # Total Lost Samples: 0 # # Samples: 2K of event 'cycles' # Event count (approx.): 2240 # # Overhead Command Source Shared Object Source Symbol Target Symbol Basic Block Cycles # ........ ............... ........................ ...................... ...................... .................. # 0.13% systemd-journal libc-2.29.so [.] cfree@GLIBC_2.2.5 [.] _int_free 1 0.09% systemd libsystemd-shared-241.so [.] 0x00000000000f7c82 [.] 0x00000000000f7d80 1 0.09% systemd libsystemd-shared-241.so [.] 0x00000000000f7ded [.] 0x00000000000f7c30 1 0.09% systemd libsystemd-shared-241.so [.] 0x00000000000f7e4e [.] 0x00000000000f7de0 1 0.09% systemd-journal systemd-journald [.] free@plt [.] cfree@GLIBC_2.2.5 1 0.09% systemd-journal libc-2.29.so [.] _int_free [.] _int_free 18 0.09% systemd-journal libc-2.29.so [.] _int_free [.] _int_free 2 0.04% systemd libsystemd-shared-241.so [.] bus_resolve@plt [.] bus_resolve 204 0.04% systemd libsystemd-shared-241.so [.] getpid_cached@plt [.] getpid_cached 7 [root@seventh ~]# Lets use -v to get full paths and then try objdump on the unresolved address: [root@seventh ~]# perf report -v --stdio --dso libsystemd-shared-241.so |& grep libsystemd-shared-241.so | tail -1 0.04% systemd-journal /usr/lib/systemd/libsystemd-shared-241.so 0x80c1a B [.] 0x0000000000080c1a 0x80a95 B [.] 0x0000000000080a95 61 [root@seventh ~]# [root@seventh ~]# objdump -d --start-address 0x00000000000f7d80 /usr/lib/systemd/libsystemd-shared-241.so | head -20 /usr/lib/systemd/libsystemd-shared-241.so: file format elf64-x86-64 Disassembly of section .text: 00000000000f7d80 : f7d80: 41 39 11 cmp %edx,(%r9) f7d83: 0f 84 ff fe ff ff je f7c88 f7d89: 4c 8d 05 97 09 0c 00 lea 0xc0997(%rip),%r8 # 1b8727 f7d90: b9 49 00 00 00 mov $0x49,%ecx f7d95: 48 8d 15 c9 f5 0b 00 lea 0xbf5c9(%rip),%rdx # 1b7365 f7d9c: 31 ff xor %edi,%edi f7d9e: 48 8d 35 9b ff 0b 00 lea 0xbff9b(%rip),%rsi # 1b7d40 f7da5: e8 a6 d6 f4 ff callq 45450 f7daa: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) f7db0: 41 56 push %r14 f7db2: 41 55 push %r13 f7db4: 41 54 push %r12 f7db6: 55 push %rbp [root@seventh ~]# If we tried the the reported address before this patch: [root@seventh ~]# objdump -d --start-address 0x00007fe406465d80 /usr/lib/systemd/libsystemd-shared-241.so | head -20 /usr/lib/systemd/libsystemd-shared-241.so: file format elf64-x86-64 [root@seventh ~]# Signed-off-by: Jin Yao Tested-by: Arnaldo Carvalho de Melo Tested-by: Ravi Bangoria Acked-by: Jiri Olsa Cc: Alexander Shishkin Cc: Andi Kleen Cc: Kan Liang Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/20200227043939.4403-2-yao.jin@linux.intel.com Signed-off-by: Arnaldo Carvalho de Melo + Changed Files: tools/perf/util/sort.c | 6 ++++--; 1 file changed, 4 insertions(+), 2 deletions(-) + Parent Hashes: 7eec00a74720d35b6d89505350e5b08ecef376c0 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit updates 'perf report' to print 'al_addr' when a symbol is not found for better binary instruction traceability.", + "keywords": "perf,report,symbol", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +Rethinking... +new content: +{ + "summary": "This commit updates the 'perf report' tool to improve the handling of unresolved symbols by displaying alternative addresses.", + "keywords": "perf,report,symbol", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +-------------------- +-------------------- +Processing Commit 350/6895 - Commit ID: e28596012d1a482641a2110ed1c4c09ce98562b3 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: e28596012d1a482641a2110ed1c4c09ce98562b3 + Author Name: David S. Miller + Author Email: davem@davemloft.net + Commit Date: 1584846497 + Commit Message: + Merge branch 'net-tls-Annotate-lockless-access-to-sk_prot' Jakub Sitnicki says: ==================== net/tls: Annotate lockless access to sk_prot We have recently noticed that there is a case of lockless read/write to sk->sk_prot [0]. sockmap code on psock tear-down writes to sk->sk_prot, while holding sk_callback_lock. Concurrently, tcp can access it. Usually to read out the sk_prot pointer and invoke one of the ops, sk->sk_prot->handler(). The lockless write (lockless in regard to concurrent reads) happens on the following paths: tcp_bpf_{recvmsg|sendmsg} / sock_map_unref sk_psock_put sk_psock_drop sk_psock_restore_proto WRITE_ONCE(sk->sk_prot, proto) To prevent load/store tearing [1], and to make tooling aware of intentional shared access [2], we need to annotate sites that access sk_prot with READ_ONCE/WRITE_ONCE. This series kicks off the effort to do it. Starting with net/tls. [0] https://lore.kernel.org/bpf/a6bf279e-a998-84ab-4371-cd6c1ccbca5d@gmail.com/ [1] https://lwn.net/Articles/793253/ [2] https://github.com/google/ktsan/wiki/READ_ONCE-and-WRITE_ONCE ==================== Signed-off-by: David S. Miller + Changed Files: nan + Parent Hashes: 26922c0ef33f2b24192f567db9d01ce4fa289b54 d5bee7374b68de3c44586d46e9e61ffc97a1e886 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges changes to annotate lockless access to sk_prot in the network TLS subsystem.", + "keywords": "lockless, sk_prot, annotate", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges annotations for lockless access to sk_prot in the net/tls subsystem.", + "keywords": "net,tls,sk_prot", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 351/6895 - Commit ID: d5bee7374b68de3c44586d46e9e61ffc97a1e886 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: d5bee7374b68de3c44586d46e9e61ffc97a1e886 + Author Name: Jakub Sitnicki + Author Email: jakub@cloudflare.com + Commit Date: 1584846497 + Commit Message: + net/tls: Annotate access to sk_prot with READ_ONCE/WRITE_ONCE sockmap performs lockless writes to sk->sk_prot on the following paths: tcp_bpf_{recvmsg|sendmsg} / sock_map_unref sk_psock_put sk_psock_drop sk_psock_restore_proto WRITE_ONCE(sk->sk_prot, proto) To prevent load/store tearing [1], and to make tooling aware of intentional shared access [2], we need to annotate other sites that access sk_prot with READ_ONCE/WRITE_ONCE macros. Change done with Coccinelle with following semantic patch: @@ expression E; identifier I; struct sock *sk; identifier sk_prot =~ "^sk_prot$"; @@ ( E = -sk->sk_prot +READ_ONCE(sk->sk_prot) | -sk->sk_prot = E +WRITE_ONCE(sk->sk_prot, E) | -sk->sk_prot +READ_ONCE(sk->sk_prot) ->I ) Signed-off-by: Jakub Sitnicki Signed-off-by: David S. Miller + Changed Files: net/tls/tls_device.c | 2 +-; net/tls/tls_main.c | 9 +++++----; 2 files changed, 6 insertions(+), 5 deletions(-) + Parent Hashes: 5bb4c45d466cb28dd0a7f15f80c4cb7768054e94 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Annotate access to sk_prot with READ_ONCE/WRITE_ONCE to prevent tearing in net/tls.", + "keywords": "sk_prot, READ_ONCE, WRITE_ONCE", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "I'm not sure about the logic component of the commit. The affected logic component is unclear.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +Rethinking... +new content: +{ + "summary": "Annotate access to sk_prot with READ_ONCE/WRITE_ONCE macros in net/tls to prevent tearing.", + "keywords": "sk_prot, READ_ONCE, WRITE_ONCE", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "I'm not sure about the logic component of the commit. The affected logic component is unclear.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +-------------------- +-------------------- +Processing Commit 352/6895 - Commit ID: 1440e7929392297f1578a54f372e9821bb1b0658 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 1440e7929392297f1578a54f372e9821bb1b0658 + Author Name: Bill Wendling + Author Email: morbo@google.com + Commit Date: 1584737172 + Commit Message: + selftests/bpf: Fix mix of tabs and spaces Clang's -Wmisleading-indentation warns about misleading indentations if there's a mixture of spaces and tabs. Remove extraneous spaces. Signed-off-by: Bill Wendling Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200320201510.217169-1-morbo@google.com + Changed Files: tools/testing/selftests/bpf/prog_tests/btf_dump.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: c0fd336ea4ca82377fbb0954db09d765eb794339 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes a mixture of tabs and spaces in BPF selftest files to resolve misleading indentation warnings by Clang.", + "keywords": "tabs, spaces, indentation", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes a mix of tabs and spaces to address misleading indentation warnings in BPF selftest code.", + "keywords": "tabs, spaces, indentation", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 353/6895 - Commit ID: 5c6f25887963f15492b604dd25cb149c501bbabf +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 5c6f25887963f15492b604dd25cb149c501bbabf + Author Name: Greg Kroah-Hartman + Author Email: gregkh@linuxfoundation.org + Commit Date: 1584734722 + Commit Message: + bpf: Explicitly memset some bpf info structures declared on the stack Trying to initialize a structure with "= {};" will not always clean out all padding locations in a structure. So be explicit and call memset to initialize everything for a number of bpf information structures that are then copied from userspace, sometimes from smaller memory locations than the size of the structure. Reported-by: Daniel Borkmann Signed-off-by: Greg Kroah-Hartman Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200320162258.GA794295@kroah.com + Changed Files: kernel/bpf/btf.c | 3 ++-; kernel/bpf/syscall.c | 6 ++++--; 2 files changed, 6 insertions(+), 3 deletions(-) + Parent Hashes: 8096f229421f7b22433775e928d506f0342e5907 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes potential padding issues in bpf info structures by explicitly initializing them with memset.", + "keywords": "memset,structures,padding", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes potential padding issues in bpf info structures by explicitly initializing them using memset.", + "keywords": "memset,structures,padding", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 354/6895 - Commit ID: 8096f229421f7b22433775e928d506f0342e5907 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 8096f229421f7b22433775e928d506f0342e5907 + Author Name: Greg Kroah-Hartman + Author Email: gregkh@linuxfoundation.org + Commit Date: 1584734670 + Commit Message: + bpf: Explicitly memset the bpf_attr structure For the bpf syscall, we are relying on the compiler to properly zero out the bpf_attr union that we copy userspace data into. Unfortunately that doesn't always work properly, padding and other oddities might not be correctly zeroed, and in some tests odd things have been found when the stack is pre-initialized to other values. Fix this by explicitly memsetting the structure to 0 before using it. Reported-by: Maciej Żenczykowski Reported-by: John Stultz Reported-by: Alexander Potapenko Reported-by: Alistair Delva Signed-off-by: Greg Kroah-Hartman Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://android-review.googlesource.com/c/kernel/common/+/1235490 Link: https://lore.kernel.org/bpf/20200320094813.GA421650@kroah.com + Changed Files: kernel/bpf/syscall.c | 3 ++-; 1 file changed, 2 insertions(+), 1 deletion(-) + Parent Hashes: 8e7ae2518f5265f0ef09d561748098fde5a87ccd +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit explicitly sets the bpf_attr structure to zero to avoid issues with uninitialized memory during bpf syscall handling.", + "keywords": "bpf_attr, memset, syscall", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The syscall interface. It changes the system calls through which user-space programs interact with eBPF.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit explicitly sets the bpf_attr structure to zero to avoid issues with uninitialized memory during bpf syscall handling.", + "keywords": "bpf_attr, memset, syscall", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The syscall interface. It changes the system calls through which user-space programs interact with eBPF.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 355/6895 - Commit ID: c0fd336ea4ca82377fbb0954db09d765eb794339 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: c0fd336ea4ca82377fbb0954db09d765eb794339 + Author Name: YueHaibing + Author Email: yuehaibing@huawei.com + Commit Date: 1584716215 + Commit Message: + bpf, tcp: Make tcp_bpf_recvmsg static After commit f747632b608f ("bpf: sockmap: Move generic sockmap hooks from BPF TCP"), tcp_bpf_recvmsg() is not used out of tcp_bpf.c, so make it static and remove it from tcp.h. Also move it to BPF_STREAM_PARSER #ifdef to fix unused function warnings. Fixes: f747632b608f ("bpf: sockmap: Move generic sockmap hooks from BPF TCP") Signed-off-by: YueHaibing Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200320023426.60684-3-yuehaibing@huawei.com + Changed Files: include/net/tcp.h | 2 -; net/ipv4/tcp_bpf.c | 124 ++++++++++++++++++++++++++---------------------------; 2 files changed, 62 insertions(+), 64 deletions(-) + Parent Hashes: a26527981af2988ae0f17f6d633848c019929e38 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit makes the function tcp_bpf_recvmsg static and moves it to fix unused function warnings.", + "keywords": "tcp_bpf_recvmsg,function,static", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "The commit makes the tcp_bpf_recvmsg function static for internal use, addressing unused function warnings.", + "keywords": "static,function,warnings", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 356/6895 - Commit ID: a26527981af2988ae0f17f6d633848c019929e38 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: a26527981af2988ae0f17f6d633848c019929e38 + Author Name: YueHaibing + Author Email: yuehaibing@huawei.com + Commit Date: 1584716185 + Commit Message: + bpf, tcp: Fix unused function warnings If BPF_STREAM_PARSER is not set, gcc warns: net/ipv4/tcp_bpf.c:483:12: warning: 'tcp_bpf_sendpage' defined but not used [-Wunused-function] net/ipv4/tcp_bpf.c:395:12: warning: 'tcp_bpf_sendmsg' defined but not used [-Wunused-function] net/ipv4/tcp_bpf.c:13:13: warning: 'tcp_bpf_stream_read' defined but not used [-Wunused-function] Moves the unused functions into the #ifdef CONFIG_BPF_STREAM_PARSER. Fixes: f747632b608f ("bpf: sockmap: Move generic sockmap hooks from BPF TCP") Reported-by: Hulk Robot Signed-off-by: YueHaibing Signed-off-by: Daniel Borkmann Reviewed-by: Lorenz Bauer Reviewed-by: Jakub Sitnicki Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200320023426.60684-2-yuehaibing@huawei.com + Changed Files: net/ipv4/tcp_bpf.c | 28 ++++++++++++++--------------; 1 file changed, 14 insertions(+), 14 deletions(-) + Parent Hashes: 65c93628599dff4cd7cfb70130d1f6a2203731ea +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes unused function warnings by moving them within #ifdef CONFIG_BPF_STREAM_PARSER blocks.", + "keywords": "unused,function,warnings", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +Rethinking... +new content: +{ + "summary": "The commit addresses unused function warnings by enclosing them in #ifdef CONFIG_BPF_STREAM_PARSER blocks.", + "keywords": "unused,function,warnings", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +-------------------- +-------------------- +Processing Commit 357/6895 - Commit ID: 65c93628599dff4cd7cfb70130d1f6a2203731ea +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 65c93628599dff4cd7cfb70130d1f6a2203731ea + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1584715895 + Commit Message: + bpftool: Add struct_ops support This patch adds struct_ops support to the bpftool. To recap a bit on the recent bpf_struct_ops feature on the kernel side: It currently supports "struct tcp_congestion_ops" to be implemented in bpf. At a high level, bpf_struct_ops is struct_ops map populated with a number of bpf progs. bpf_struct_ops currently supports the "struct tcp_congestion_ops". However, the bpf_struct_ops design is generic enough that other kernel struct ops can be supported in the future. Although struct_ops is map+progs at a high lever, there are differences in details. For example, 1) After registering a struct_ops, the struct_ops is held by the kernel subsystem (e.g. tcp-cc). Thus, there is no need to pin a struct_ops map or its progs in order to keep them around. 2) To iterate all struct_ops in a system, it iterates all maps in type BPF_MAP_TYPE_STRUCT_OPS. BPF_MAP_TYPE_STRUCT_OPS is the current usual filter. In the future, it may need to filter by other struct_ops specific properties. e.g. filter by tcp_congestion_ops or other kernel subsystem ops in the future. 3) struct_ops requires the running kernel having BTF info. That allows more flexibility in handling other kernel structs. e.g. it can always dump the latest bpf_map_info. 4) Also, "struct_ops" command is not intended to repeat all features already provided by "map" or "prog". For example, if there really is a need to pin the struct_ops map, the user can use the "map" cmd to do that. While the first attempt was to reuse parts from map/prog.c, it ended up not a lot to share. The only obvious item is the map_parse_fds() but that still requires modifications to accommodate struct_ops map specific filtering (for the immediate and the future needs). Together with the earlier mentioned differences, it is better to part away from map/prog.c. The initial set of subcmds are, register, unregister, show, and dump. For register, it registers all struct_ops maps that can be found in an obj file. Option can be added in the future to specify a particular struct_ops map. Also, the common bpf_tcp_cc is stateless (e.g. bpf_cubic.c and bpf_dctcp.c). The "reuse map" feature is not implemented in this patch and it can be considered later also. For other subcmds, please see the man doc for details. A sample output of dump: [root@arch-fb-vm1 bpf]# bpftool struct_ops dump name cubic [{ "bpf_map_info": { "type": 26, "id": 64, "key_size": 4, "value_size": 256, "max_entries": 1, "map_flags": 0, "name": "cubic", "ifindex": 0, "btf_vmlinux_value_type_id": 18452, "netns_dev": 0, "netns_ino": 0, "btf_id": 52, "btf_key_type_id": 0, "btf_value_type_id": 0 } },{ "bpf_struct_ops_tcp_congestion_ops": { "refcnt": { "refs": { "counter": 1 } }, "state": "BPF_STRUCT_OPS_STATE_INUSE", "data": { "list": { "next": 0, "prev": 0 }, "key": 0, "flags": 0, "init": "void (struct sock *) bictcp_init/prog_id:138", "release": "void (struct sock *) 0", "ssthresh": "u32 (struct sock *) bictcp_recalc_ssthresh/prog_id:141", "cong_avoid": "void (struct sock *, u32, u32) bictcp_cong_avoid/prog_id:140", "set_state": "void (struct sock *, u8) bictcp_state/prog_id:142", "cwnd_event": "void (struct sock *, enum tcp_ca_event) bictcp_cwnd_event/prog_id:139", "in_ack_event": "void (struct sock *, u32) 0", "undo_cwnd": "u32 (struct sock *) tcp_reno_undo_cwnd/prog_id:144", "pkts_acked": "void (struct sock *, const struct ack_sample *) bictcp_acked/prog_id:143", "min_tso_segs": "u32 (struct sock *) 0", "sndbuf_expand": "u32 (struct sock *) 0", "cong_control": "void (struct sock *, const struct rate_sample *) 0", "get_info": "size_t (struct sock *, u32, int *, union tcp_cc_info *) 0", "name": "bpf_cubic", "owner": 0 } } } ] Signed-off-by: Martin KaFai Lau Signed-off-by: Daniel Borkmann Acked-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200318171656.129650-1-kafai@fb.com + Changed Files: .../bpftool/Documentation/bpftool-struct_ops.rst | 116 ++++; tools/bpf/bpftool/bash-completion/bpftool | 28 +; tools/bpf/bpftool/main.c | 3 +-; tools/bpf/bpftool/main.h | 1 +; tools/bpf/bpftool/struct_ops.c | 596 +++++++++++++++++++++; 5 files changed, 743 insertions(+), 1 deletion(-) + Parent Hashes: d5ae04da34a213cc518558ecd25af0f609428560 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds support for struct_ops in bpftool to facilitate handling of kernel struct operations like tcp_congestion_ops.", + "keywords": "bpftool,struct_ops,tcp_congestion_ops", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds support for struct_ops in bpftool, enhancing the ability to manage kernel struct operations like tcp_congestion_ops.", + "keywords": "bpftool,struct_ops,tcp_congestion_ops", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems." + ] +} +-------------------- +-------------------- +Processing Commit 358/6895 - Commit ID: d5ae04da34a213cc518558ecd25af0f609428560 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: d5ae04da34a213cc518558ecd25af0f609428560 + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1584715895 + Commit Message: + bpftool: Translate prog_id to its bpf prog_name The kernel struct_ops obj has kernel's func ptrs implemented by bpf_progs. The bpf prog_id is stored as the value of the func ptr for introspection purpose. In the latter patch, a struct_ops dump subcmd will be added to introspect these func ptrs. It is desired to print the actual bpf prog_name instead of only printing the prog_id. Since struct_ops is the only usecase storing prog_id in the func ptr, this patch adds a prog_id_as_func_ptr bool (default is false) to "struct btf_dumper" in order not to mis-interpret the ptr value for the other existing use-cases. While printing a func_ptr as a bpf prog_name, this patch also prefix the bpf prog_name with the ptr's func_proto. [ Note that it is the ptr's func_proto instead of the bpf prog's func_proto ] It reuses the current btf_dump_func() to obtain the ptr's func_proto string. Here is an example from the bpf_cubic.c: "void (struct sock *, u32, u32) bictcp_cong_avoid/prog_id:140" Signed-off-by: Martin KaFai Lau Signed-off-by: Daniel Borkmann Acked-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200318171650.129252-1-kafai@fb.com + Changed Files: tools/bpf/bpftool/btf_dumper.c | 118 ++++++++++++++++++++++++++++++++++++-----; tools/bpf/bpftool/main.h | 1 +; 2 files changed, 107 insertions(+), 12 deletions(-) + Parent Hashes: 30255d317579e93ca3ecf7f4ab953094123e4a8c +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit enhances bpftool to translate BPF program IDs to program names for kernel struct_ops function pointers.", + "keywords": "bpftool,prog_id,btf_dumper", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems." + ] +} +Rethinking... +new content: +{ + "summary": "This commit updates bpftool to translate BPF program IDs into program names for function pointers in kernel struct_ops introspection.", + "keywords": "bpftool,prog_id,struct_ops", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems." + ] +} +-------------------- +-------------------- +Processing Commit 359/6895 - Commit ID: 30255d317579e93ca3ecf7f4ab953094123e4a8c +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 30255d317579e93ca3ecf7f4ab953094123e4a8c + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1584715895 + Commit Message: + bpftool: Print as a string for char array A char[] is currently printed as an integer array. This patch will print it as a string when 1) The array element type is an one byte int 2) The array element type has a BTF_INT_CHAR encoding or the array element type's name is "char" 3) All characters is between (0x1f, 0x7f) and it is terminated by a null character. Signed-off-by: Martin KaFai Lau Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Acked-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200318171643.129021-1-kafai@fb.com + Changed Files: tools/bpf/bpftool/btf_dumper.c | 41 +++++++++++++++++++++++++++++++++++++++++; 1 file changed, 41 insertions(+) + Parent Hashes: ca7e6e45d108f5712aec4407e6c757af59d43d0f +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The patch modifies bpftool to print char arrays as strings instead of integer arrays.", + "keywords": "bpftool,char,array", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The patch modifies bpftool to print char arrays as strings instead of integer arrays.", + "keywords": "bpftool,char,array", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 360/6895 - Commit ID: ca7e6e45d108f5712aec4407e6c757af59d43d0f +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: ca7e6e45d108f5712aec4407e6c757af59d43d0f + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1584715895 + Commit Message: + bpftool: Print the enum's name instead of value This patch prints the enum's name if there is one found in the array of btf_enum. The commit 9eea98497951 ("bpf: fix BTF verification of enums") has details about an enum could have any power-of-2 size (up to 8 bytes). This patch also takes this chance to accommodate these non 4 byte enums. Signed-off-by: Martin KaFai Lau Signed-off-by: Daniel Borkmann Acked-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200318171637.128862-1-kafai@fb.com + Changed Files: tools/bpf/bpftool/btf_dumper.c | 40 ++++++++++++++++++++++++++++++++++++----; 1 file changed, 36 insertions(+), 4 deletions(-) + Parent Hashes: 90ceddcb495008ac8ba7a3dce297841efcd7d584 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit updates bpftool to print enum names instead of values, handling enums of varying sizes.", + "keywords": "bpftool,enum,BTF", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit updates bpftool to print enum names rather than values and accommodates enums of various sizes.", + "keywords": "bpftool,enum,BTF", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 361/6895 - Commit ID: 90ceddcb495008ac8ba7a3dce297841efcd7d584 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 90ceddcb495008ac8ba7a3dce297841efcd7d584 + Author Name: Fangrui Song + Author Email: maskray@google.com + Commit Date: 1584617558 + Commit Message: + bpf: Support llvm-objcopy for vmlinux BTF Simplify gen_btf logic to make it work with llvm-objcopy. The existing 'file format' and 'architecture' parsing logic is brittle and does not work with llvm-objcopy/llvm-objdump. 'file format' output of llvm-objdump>=11 will match GNU objdump, but 'architecture' (bfdarch) may not. .BTF in .tmp_vmlinux.btf is non-SHF_ALLOC. Add the SHF_ALLOC flag because it is part of vmlinux image used for introspection. C code can reference the section via linker script defined __start_BTF and __stop_BTF. This fixes a small problem that previous .BTF had the SHF_WRITE flag (objcopy -I binary -O elf* synthesized .data). Additionally, `objcopy -I binary` synthesized symbols _binary__btf_vmlinux_bin_start and _binary__btf_vmlinux_bin_stop (not used elsewhere) are replaced with more commonplace __start_BTF and __stop_BTF. Add 2>/dev/null because GNU objcopy (but not llvm-objcopy) warns "empty loadable segment detected at vaddr=0xffffffff81000000, is this intentional?" We use a dd command to change the e_type field in the ELF header from ET_EXEC to ET_REL so that lld will accept .btf.vmlinux.bin.o. Accepting ET_EXEC as an input file is an extremely rare GNU ld feature that lld does not intend to support, because this is error-prone. The output section description .BTF in include/asm-generic/vmlinux.lds.h avoids potential subtle orphan section placement issues and suppresses --orphan-handling=warn warnings. Fixes: df786c9b9476 ("bpf: Force .BTF section start to zero when dumping from vmlinux") Fixes: cb0cc635c7a9 ("powerpc: Include .BTF section") Reported-by: Nathan Chancellor Signed-off-by: Fangrui Song Signed-off-by: Daniel Borkmann Tested-by: Stanislav Fomichev Tested-by: Andrii Nakryiko Reviewed-by: Stanislav Fomichev Reviewed-by: Kees Cook Acked-by: Andrii Nakryiko Acked-by: Michael Ellerman (powerpc) Link: https://github.com/ClangBuiltLinux/linux/issues/871 Link: https://lore.kernel.org/bpf/20200318222746.173648-1-maskray@google.com + Changed Files: arch/powerpc/kernel/vmlinux.lds.S | 6 ------; include/asm-generic/vmlinux.lds.h | 15 +++++++++++++++; kernel/bpf/btf.c | 9 ++++-----; kernel/bpf/sysfs_btf.c | 11 +++++------; scripts/link-vmlinux.sh | 24 ++++++++++--------------; 5 files changed, 34 insertions(+), 31 deletions(-) + Parent Hashes: 483d7a30f538e2f8addd32aa9a3d2e94ae55fa65 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit simplifies BTF generation to be compatible with llvm-objcopy by addressing section flags and adjusting ELF headers.", + "keywords": "BTF, llvm-objcopy, ELF", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit updates BTF generation for compatibility with llvm-objcopy by modifying section flags and ELF headers.", + "keywords": "BTF, llvm-objcopy, ELF", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 362/6895 - Commit ID: 8e7ae2518f5265f0ef09d561748098fde5a87ccd +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 8e7ae2518f5265f0ef09d561748098fde5a87ccd + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1584474019 + Commit Message: + bpf: Sanitize the bpf_struct_ops tcp-cc name The bpf_struct_ops tcp-cc name should be sanitized in order to avoid problematic chars (e.g. whitespaces). This patch reuses the bpf_obj_name_cpy() for accepting the same set of characters in order to keep a consistent bpf programming experience. A "size" param is added. Also, the strlen is returned on success so that the caller (like the bpf_tcp_ca here) can error out on empty name. The existing callers of the bpf_obj_name_cpy() only need to change the testing statement to "if (err < 0)". For all these existing callers, the err will be overwritten later, so no extra change is needed for the new strlen return value. v3: - reverse xmas tree style v2: - Save the orig_src to avoid "end - size" (Andrii) Fixes: 0baf26b0fcd7 ("bpf: tcp: Support tcp_congestion_ops in bpf") Signed-off-by: Martin KaFai Lau Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200314010209.1131542-1-kafai@fb.com + Changed Files: include/linux/bpf.h | 1 +; kernel/bpf/syscall.c | 25 ++++++++++++++-----------; net/ipv4/bpf_tcp_ca.c | 7 ++-----; 3 files changed, 17 insertions(+), 16 deletions(-) + Parent Hashes: 32ca98feab8c9076c89c0697c5a85e46fece809d +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit sanitizes the bpf_struct_ops tcp-cc name to prevent problematic characters.", + "keywords": "sanitize, tcp-cc, characters", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit sanitizes tcp congestion control names in bpf_struct_ops to prevent issues with invalid characters.", + "keywords": "sanitize,tcp-cc,characters", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 363/6895 - Commit ID: 483d7a30f538e2f8addd32aa9a3d2e94ae55fa65 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 483d7a30f538e2f8addd32aa9a3d2e94ae55fa65 + Author Name: Wenbo Zhang + Author Email: ethercflow@gmail.com + Commit Date: 1584470020 + Commit Message: + bpf, libbpf: Fix ___bpf_kretprobe_args1(x) macro definition Use PT_REGS_RC instead of PT_REGS_RET to get ret correctly. Fixes: df8ff35311c8 ("libbpf: Merge selftests' bpf_trace_helpers.h into libbpf's bpf_tracing.h") Signed-off-by: Wenbo Zhang Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200315083252.22274-1-ethercflow@gmail.com + Changed Files: tools/lib/bpf/bpf_tracing.h | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: fd27b1835e7079d26809cd4d33ba98f84e593766 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixed a macro definition in libbpf to correctly retrieve return values using PT_REGS_RC instead of PT_REGS_RET.", + "keywords": "macro,libbpf,fix", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Fixed a macro definition in libbpf to correctly retrieve return values using PT_REGS_RC instead of PT_REGS_RET.", + "keywords": "macro,libbpf,fix", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 364/6895 - Commit ID: fd27b1835e7079d26809cd4d33ba98f84e593766 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: fd27b1835e7079d26809cd4d33ba98f84e593766 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1584469873 + Commit Message: + selftests/bpf: Reset process and thread affinity after each test/sub-test Some tests and sub-tests are setting "custom" thread/process affinity and don't reset it back. Instead of requiring each test to undo all this, ensure that thread affinity is restored by test_progs test runner itself. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200314013932.4035712-3-andriin@fb.com + Changed Files: tools/testing/selftests/bpf/test_progs.c | 42 +++++++++++++++++++++++++++++++-; tools/testing/selftests/bpf/test_progs.h | 1 +; 2 files changed, 42 insertions(+), 1 deletion(-) + Parent Hashes: fc32490bff855a539d253c8a52c5a1ba51d1325a +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Reset process and thread affinity after each test in BPF selftests.", + "keywords": "selftests, affinity, reset", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Reset process and thread affinity after each BPF selftest to ensure proper cleanup.", + "keywords": "selftests, affinity, reset", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 365/6895 - Commit ID: fc32490bff855a539d253c8a52c5a1ba51d1325a +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: fc32490bff855a539d253c8a52c5a1ba51d1325a + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1584469846 + Commit Message: + selftests/bpf: Fix test_progs's parsing of test numbers When specifying disjoint set of tests, test_progs doesn't set skipped test's array elements to false. This leads to spurious execution of tests that should have been skipped. Fix it by explicitly initializing them to false. Fixes: 3a516a0a3a7b ("selftests/bpf: add sub-tests support for test_progs") Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200314013932.4035712-2-andriin@fb.com + Changed Files: tools/testing/selftests/bpf/test_progs.c | 13 +++++++------; 1 file changed, 7 insertions(+), 6 deletions(-) + Parent Hashes: 94c2f50b61258381abcd3a33fd5f2bc87e26df11 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes incorrect execution of skipped tests in test_progs by ensuring skipped tests are properly initialized to false.", + "keywords": "fix,test_progs,skipped", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes incorrect execution of skipped tests in test_progs by ensuring skipped tests are properly initialized to false.", + "keywords": "fix,test_progs,skipped", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 366/6895 - Commit ID: 94c2f50b61258381abcd3a33fd5f2bc87e26df11 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 94c2f50b61258381abcd3a33fd5f2bc87e26df11 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1584469826 + Commit Message: + selftests/bpf: Fix race in tcp_rtt test Previous attempt to make tcp_rtt more robust introduced a new race, in which server_done might be set to true before server can actually accept any connection. Fix this by unconditionally waiting for accept(). Given socket is non-blocking, if there are any problems with client side, it should eventually close listening FD and let server thread exit with failure. Fixes: 4cd729fa022c ("selftests/bpf: Make tcp_rtt test more robust to failures") Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200314013932.4035712-1-andriin@fb.com + Changed Files: tools/testing/selftests/bpf/prog_tests/tcp_rtt.c | 4 ++--; 1 file changed, 2 insertions(+), 2 deletions(-) + Parent Hashes: 41078907eef0dd508d0999996d10683ae114c21a +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes a race condition in the tcp_rtt selftest by unconditionally waiting for accept().", + "keywords": "race,tcp_rtt,selftests", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes a race condition in the tcp_rtt selftest by unconditionally waiting for accept().", + "keywords": "race,tcp_rtt,selftests", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 367/6895 - Commit ID: 41078907eef0dd508d0999996d10683ae114c21a +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 41078907eef0dd508d0999996d10683ae114c21a + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1584469752 + Commit Message: + selftests/bpf: Fix nanosleep for real this time Amazingly, some libc implementations don't call __NR_nanosleep syscall from their nanosleep() APIs. Hammer it down with explicit syscall() call and never get back to it again. Also simplify code for timespec initialization. I verified that nanosleep is called w/ printk and in exactly same Linux image that is used in Travis CI. So it should both sleep and call correct syscall. v1->v2: - math is too hard, fix usec -> nsec convertion (Martin); - test_vmlinux has explicit nanosleep() call, convert that one as well. Fixes: 4e1fd25d19e8 ("selftests/bpf: Fix usleep() implementation") Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200314002743.3782677-1-andriin@fb.com + Changed Files: tools/testing/selftests/bpf/prog_tests/vmlinux.c | 2 +-; tools/testing/selftests/bpf/test_progs.c | 16 ++++++----------; 2 files changed, 7 insertions(+), 11 deletions(-) + Parent Hashes: cc9864a7aad9bc952d89f80dd0404a44ca591c2d +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes the nanosleep syscall implementation in BPF selftests for consistent behavior across different libc libraries.", + "keywords": "nanosleep,selftests,fix", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes the nanosleep syscall implementation in BPF selftests to ensure consistent behavior across libc implementations.", + "keywords": "nanosleep,selftests,fix", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 368/6895 - Commit ID: cc9864a7aad9bc952d89f80dd0404a44ca591c2d +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: cc9864a7aad9bc952d89f80dd0404a44ca591c2d + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1584469707 + Commit Message: + selftest/bpf: Fix compilation warning in sockmap_parse_prog.c Remove unused len variable, which causes compilation warnings. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200314001834.3727680-1-andriin@fb.com + Changed Files: tools/testing/selftests/bpf/progs/sockmap_parse_prog.c | 1 -; 1 file changed, 1 deletion(-) + Parent Hashes: 86e85bf6981c0c265c427d6bfe9e2a0111797444 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes a compilation warning by removing an unused variable in the selftest sockmap_parse_prog.c file.", + "keywords": "compilation,warning,sockmap", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes a compilation warning by removing an unused variable in the selftest sockmap_parse_prog.c file.", + "keywords": "compilation,warning,sockmap", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 369/6895 - Commit ID: 13d0f7b814d9b4c67e60d8c2820c86ea181e7d99 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 13d0f7b814d9b4c67e60d8c2820c86ea181e7d99 + Author Name: Bruno Meneguele + Author Email: bmeneg@redhat.com + Commit Date: 1584244690 + Commit Message: + net/bpfilter: fix dprintf usage for /dev/kmsg The bpfilter UMH code was recently changed to log its informative messages to /dev/kmsg, however this interface doesn't support SEEK_CUR yet, used by dprintf(). As result dprintf() returns -EINVAL and doesn't log anything. However there already had some discussions about supporting SEEK_CUR into /dev/kmsg interface in the past it wasn't concluded. Since the only user of that from userspace perspective inside the kernel is the bpfilter UMH (userspace) module it's better to correct it here instead waiting a conclusion on the interface. Fixes: 36c4357c63f3 ("net: bpfilter: print umh messages to /dev/kmsg") Signed-off-by: Bruno Meneguele Signed-off-by: David S. Miller + Changed Files: net/bpfilter/main.c | 14 ++++++++------; 1 file changed, 8 insertions(+), 6 deletions(-) + Parent Hashes: 0d1c3530e1bd38382edef72591b78e877e0edcd3 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit fixes the issue with dprintf usage in bpfilter UMH by logging to /dev/kmsg without using SEEK_CUR.", + "keywords": "bpfilter, dprintf, kmsg", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here." + ] +} +Rethinking... +new content: +{ + "summary": "This commit corrects the usage of dprintf in bpfilter UMH to properly log messages to /dev/kmsg.", + "keywords": "bpfilter, UMH, kmsg", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here." + ] +} +-------------------- +-------------------- +Processing Commit 370/6895 - Commit ID: 44ef976ab3c4ccd6c886714e5349caa53c477010 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 44ef976ab3c4ccd6c886714e5349caa53c477010 + Author Name: David S. Miller + Author Email: davem@davemloft.net + Commit Date: 1584157923 + Commit Message: + Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next Daniel Borkmann says: ==================== pull-request: bpf-next 2020-03-13 The following pull-request contains BPF updates for your *net-next* tree. We've added 86 non-merge commits during the last 12 day(s) which contain a total of 107 files changed, 5771 insertions(+), 1700 deletions(-). The main changes are: 1) Add modify_return attach type which allows to attach to a function via BPF trampoline and is run after the fentry and before the fexit programs and can pass a return code to the original caller, from KP Singh. 2) Generalize BPF's kallsyms handling and add BPF trampoline and dispatcher objects to be visible in /proc/kallsyms so they can be annotated in stack traces, from Jiri Olsa. 3) Extend BPF sockmap to allow for UDP next to existing TCP support in order in order to enable this for BPF based socket dispatch, from Lorenz Bauer. 4) Introduce a new bpftool 'prog profile' command which attaches to existing BPF programs via fentry and fexit hooks and reads out hardware counters during that period, from Song Liu. Example usage: bpftool prog profile id 337 duration 3 cycles instructions llc_misses 4228 run_cnt 3403698 cycles (84.08%) 3525294 instructions # 1.04 insn per cycle (84.05%) 13 llc_misses # 3.69 LLC misses per million isns (83.50%) 5) Batch of improvements to libbpf, bpftool and BPF selftests. Also addition of a new bpf_link abstraction to keep in particular BPF tracing programs attached even when the applicaion owning them exits, from Andrii Nakryiko. 6) New bpf_get_current_pid_tgid() helper for tracing to perform PID filtering and which returns the PID as seen by the init namespace, from Carlos Neira. 7) Refactor of RISC-V JIT code to move out common pieces and addition of a new RV32G BPF JIT compiler, from Luke Nelson. 8) Add gso_size context member to __sk_buff in order to be able to know whether a given skb is GSO or not, from Willem de Bruijn. 9) Add a new bpf_xdp_output() helper which reuses XDP's existing perf RB output implementation but can be called from tracepoint programs, from Eelco Chaudron. ==================== Signed-off-by: David S. Miller + Changed Files: nan + Parent Hashes: 48f5d5cb80b4e414cb97dd7dba43b0370bdee130 832165d225f71040a2c1fc2407752e462d00de1f +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This is a merge commit that incorporates multiple eBPF updates from the bpf-next branch into the net-next tree.", + "keywords": "merge,BPF,updates", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges multiple eBPF enhancements from the bpf-next branch into net-next.", + "keywords": "merge,eBPF,enhancements", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 371/6895 - Commit ID: 832165d225f71040a2c1fc2407752e462d00de1f +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 832165d225f71040a2c1fc2407752e462d00de1f + Author Name: Daniel Borkmann + Author Email: daniel@iogearbox.net + Commit Date: 1584138674 + Commit Message: + Merge branch 'bpf-core-fixes' Andrii Nakryiko says: ==================== This patch set fixes bug in CO-RE relocation candidate finding logic, which currently allows matching against forward declarations, functions, and other named types, even though it makes no sense to even attempt. As part of verifying the fix, add test using vmlinux.h with preserve_access_index attribute and utilizing struct pt_regs heavily to trace nanosleep syscall using 5 different types of tracing BPF programs. This test also demonstrated problems using struct pt_regs in syscall tracepoints and required a new set of macro, which were added in patch #3 into bpf_tracing.h. Patch #1 fixes annoying issue with selftest failure messages being out of sync. v1->v2: - drop unused handle__probed() function (Martin). ==================== Signed-off-by: Daniel Borkmann + Changed Files: nan + Parent Hashes: 30b4cb36b11144e29b4f837057f8ab31aac10b8a acbd06206bbbe59ffd2415c0b902dd244910e42e +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "A merge commit fixing bugs in CO-RE relocation logic while adding tests and new macros for BPF tracing.", + "keywords": "CO-RE,tracing,relocation", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +Rethinking... +new content: +{ + "summary": "A merge commit fixing bugs in CO-RE relocation logic adding tests and new macros for BPF tracing.", + "keywords": "CO-RE,tracing,relocation", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +-------------------- +-------------------- +Processing Commit 372/6895 - Commit ID: acbd06206bbbe59ffd2415c0b902dd244910e42e +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: acbd06206bbbe59ffd2415c0b902dd244910e42e + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1584138653 + Commit Message: + selftests/bpf: Add vmlinux.h selftest exercising tracing of syscalls Add vmlinux.h generation to selftest/bpf's Makefile. Use it from newly added test_vmlinux to trace nanosleep syscall using 5 different types of programs: - tracepoint; - raw tracepoint; - raw tracepoint w/ direct memory reads (tp_btf); - kprobe; - fentry. These programs are realistic variants of real-life tracing programs, excercising vmlinux.h's usage with tracing applications. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200313172336.1879637-5-andriin@fb.com + Changed Files: tools/testing/selftests/bpf/Makefile | 7 +-; tools/testing/selftests/bpf/prog_tests/vmlinux.c | 43 ++++++++++++; tools/testing/selftests/bpf/progs/test_vmlinux.c | 84 ++++++++++++++++++++++++; 3 files changed, 133 insertions(+), 1 deletion(-) + Parent Hashes: b8ebce86ffe655ac15a841bba2d645105ffe3d38 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Add a selftest for tracing syscalls using vmlinux.h with various eBPF program types.", + "keywords": "selftests,vmlinux,tracing", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Add a selftest for tracing syscalls using vmlinux.h with various eBPF program types.", + "keywords": "selftests,vmlinux,tracing", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 373/6895 - Commit ID: b8ebce86ffe655ac15a841bba2d645105ffe3d38 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: b8ebce86ffe655ac15a841bba2d645105ffe3d38 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1584138653 + Commit Message: + libbpf: Provide CO-RE variants of PT_REGS macros Syscall raw tracepoints have struct pt_regs pointer as tracepoint's first argument. After that, reading any of pt_regs fields requires bpf_probe_read(), even for tp_btf programs. Due to that, PT_REGS_PARMx macros are not usable as is. This patch adds CO-RE variants of those macros that use BPF_CORE_READ() to read necessary fields. This provides relocatable architecture-agnostic pt_regs field accesses. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200313172336.1879637-4-andriin@fb.com + Changed Files: tools/lib/bpf/bpf_tracing.h | 103 ++++++++++++++++++++++++++++++++++++++++++++; 1 file changed, 103 insertions(+) + Parent Hashes: d121e1d34b72c4975ff0340901d926c0aaf98174 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit introduces CO-RE variants of PT_REGS macros in libbpf for relocatable architecture-agnostic field access in syscall raw tracepoints.", + "keywords": "CO-RE, PT_REGS, libbpf", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit introduces CO-RE variants of PT_REGS macros in libbpf for relocatable architecture-agnostic field access in syscall raw tracepoints.", + "keywords": "CO-RE, PT_REGS, libbpf", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 374/6895 - Commit ID: d121e1d34b72c4975ff0340901d926c0aaf98174 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: d121e1d34b72c4975ff0340901d926c0aaf98174 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1584138653 + Commit Message: + libbpf: Ignore incompatible types with matching name during CO-RE relocation When finding target type candidates, ignore forward declarations, functions, and other named types of incompatible kind. Not doing this can cause false errors. See [0] for one such case (due to struct pt_regs forward declaration). [0] https://github.com/iovisor/bcc/pull/2806#issuecomment-598543645 Fixes: ddc7c3042614 ("libbpf: implement BPF CO-RE offset relocation algorithm") Reported-by: Wenbo Zhang Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200313172336.1879637-3-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.c | 4 ++++; 1 file changed, 4 insertions(+) + Parent Hashes: 3e2671fb9a95d2b46990832466383ec8384d88a3 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes incorrect type matching during CO-RE relocation in libbpf by ignoring incompatible named types.", + "keywords": "libbpf, CO-RE, relocation", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit addresses false errors in CO-RE relocation by skipping incompatible type candidates in libbpf.", + "keywords": "libbpf, CO-RE, types", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 375/6895 - Commit ID: 3e2671fb9a95d2b46990832466383ec8384d88a3 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 3e2671fb9a95d2b46990832466383ec8384d88a3 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1584138653 + Commit Message: + selftests/bpf: Ensure consistent test failure output printf() doesn't seem to honor using overwritten stdout/stderr (as part of stdio hijacking), so ensure all "standard" invocations of printf() do fprintf(stdout, ...) instead. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200313172336.1879637-2-andriin@fb.com + Changed Files: tools/testing/selftests/bpf/test_progs.c | 10 +++++-----; tools/testing/selftests/bpf/test_progs.h | 8 ++++----; 2 files changed, 9 insertions(+), 9 deletions(-) + Parent Hashes: 30b4cb36b11144e29b4f837057f8ab31aac10b8a +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit modifies test outputs in the bpf selftests to ensure consistent failure messages by using fprintf instead of printf.", + "keywords": "selftests bpf fprintf", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit modifies test outputs in the bpf selftests to ensure consistent failure messages by using fprintf instead of printf.", + "keywords": "selftests bpf fprintf", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 376/6895 - Commit ID: 30b4cb36b11144e29b4f837057f8ab31aac10b8a +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 30b4cb36b11144e29b4f837057f8ab31aac10b8a + Author Name: Jakub Sitnicki + Author Email: jakub@cloudflare.com + Commit Date: 1584131826 + Commit Message: + selftests/bpf: Fix spurious failures in accept due to EAGAIN Andrii Nakryiko reports that sockmap_listen test suite is frequently failing due to accept() calls erroring out with EAGAIN: ./test_progs:connect_accept_thread:733: accept: Resource temporarily unavailable connect_accept_thread:FAIL:733 This is because we are using a non-blocking listening TCP socket to accept() connections without polling on the socket. While at first switching to blocking mode seems like the right thing to do, this could lead to test process blocking indefinitely in face of a network issue, like loopback interface being down, as Andrii pointed out. Hence, stick to non-blocking mode for TCP listening sockets but with polling for incoming connection for a limited time before giving up. Apply this approach to all socket I/O calls in the test suite that we expect to block indefinitely, that is accept() for TCP and recv() for UDP. Fixes: 44d28be2b8d4 ("selftests/bpf: Tests for sockmap/sockhash holding listening sockets") Reported-by: Andrii Nakryiko Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200313161049.677700-1-jakub@cloudflare.com + Changed Files: .../selftests/bpf/prog_tests/sockmap_listen.c | 77 ++++++++++++++++------; 1 file changed, 58 insertions(+), 19 deletions(-) + Parent Hashes: bcd66b10b5e956b3e81f76a61abfed2501ff4038 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit fixes spurious failures in sockmap_listen selftest by using polling for non-blocking TCP sockets.", + "keywords": "selftests,bpf,EAGAIN", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "This commit fixes spurious failures in sockmap_listen selftest by using polling for non-blocking TCP sockets to handle EAGAIN errors.", + "keywords": "selftests,bpf,EAGAIN", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 377/6895 - Commit ID: bcd66b10b5e956b3e81f76a61abfed2501ff4038 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: bcd66b10b5e956b3e81f76a61abfed2501ff4038 + Author Name: Tobias Klauser + Author Email: tklauser@distanz.ch + Commit Date: 1584129394 + Commit Message: + tools/bpf: Move linux/types.h for selftests and bpftool Commit fe4eb069edb7 ("bpftool: Use linux/types.h from source tree for profiler build") added a build dependency on tools/testing/selftests/bpf to tools/bpf/bpftool. This is suboptimal with respect to a possible stand-alone build of bpftool. Fix this by moving tools/testing/selftests/bpf/include/uapi/linux/types.h to tools/include/uapi/linux/types.h. This requires an adjustment in the include search path order for the tests in tools/testing/selftests/bpf so that tools/include/linux/types.h is selected when building host binaries and tools/include/uapi/linux/types.h is selected when building bpf binaries. Verified by compiling bpftool and the bpf selftests on x86_64 with this change. Fixes: fe4eb069edb7 ("bpftool: Use linux/types.h from source tree for profiler build") Suggested-by: Andrii Nakryiko Signed-off-by: Tobias Klauser Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200313113105.6918-1-tklauser@distanz.ch + Changed Files: tools/bpf/bpftool/Makefile | 1 -; tools/include/uapi/linux/types.h | 23 ++++++++++++++++++++++; tools/testing/selftests/bpf/Makefile | 7 ++++---; .../selftests/bpf/include/uapi/linux/types.h | 23 ----------------------; 4 files changed, 27 insertions(+), 27 deletions(-) + Parent Hashes: dcce11d545cc5d04c3fb529a8e2a0da987389139 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit relocates linux/types.h to improve standalone builds of bpftool and adjusts include paths for bpftool and selftests.", + "keywords": "bpftool,selftests,types.h", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit relocates linux/types.h to improve standalone builds of bpftool and adjusts include paths for bpftool and selftests.", + "keywords": "bpftool,selftests,types.h", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 378/6895 - Commit ID: dcce11d545cc5d04c3fb529a8e2a0da987389139 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: dcce11d545cc5d04c3fb529a8e2a0da987389139 + Author Name: Jules Irenge + Author Email: jbi.octave@gmail.com + Commit Date: 1584129307 + Commit Message: + bpf: Add missing annotations for __bpf_prog_enter() and __bpf_prog_exit() Sparse reports a warning at __bpf_prog_enter() and __bpf_prog_exit() warning: context imbalance in __bpf_prog_enter() - wrong count at exit warning: context imbalance in __bpf_prog_exit() - unexpected unlock The root cause is the missing annotation at __bpf_prog_enter() and __bpf_prog_exit() Add the missing __acquires(RCU) annotation Add the missing __releases(RCU) annotation Signed-off-by: Jules Irenge Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200311010908.42366-2-jbi.octave@gmail.com + Changed Files: kernel/bpf/trampoline.c | 2 ++; 1 file changed, 2 insertions(+) + Parent Hashes: 5996a587a466fa469531272139d23a3b56e07e5c +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds missing RCU annotations to __bpf_prog_enter() and __bpf_prog_exit() to address sparse warnings about context imbalances.", + "keywords": "annotations,sparse,warnings", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds missing RCU annotations to __bpf_prog_enter() and __bpf_prog_exit() to fix sparse warnings related to context imbalance.", + "keywords": "annotations,RCU,imbalances", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 379/6895 - Commit ID: 5996a587a466fa469531272139d23a3b56e07e5c +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 5996a587a466fa469531272139d23a3b56e07e5c + Author Name: Carlos Neira + Author Email: cneirabustos@gmail.com + Commit Date: 1584129220 + Commit Message: + bpf_helpers_doc.py: Fix warning when compiling bpftool When compiling bpftool the following warning is found: "declaration of 'struct bpf_pidns_info' will not be visible outside of this function." This patch adds struct bpf_pidns_info to type_fwds array to fix this. Fixes: b4490c5c4e02 ("bpf: Added new helper bpf_get_ns_current_pid_tgid") Signed-off-by: Carlos Neira Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200313154650.13366-1-cneirabustos@gmail.com + Changed Files: scripts/bpf_helpers_doc.py | 1 +; 1 file changed, 1 insertion(+) + Parent Hashes: 4e1fd25d19e83774e41008c1ca35c6c27eb30270 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes a warning in the bpftool compilation by adding struct 'bpf_pidns_info' to a specific array.", + "keywords": "warning, bpftool, struct", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit resolves a compilation warning by adding a forward declaration for struct 'bpf_pidns_info' in bpf_helpers_doc.py.", + "keywords": "warning,bpftool,struct", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 380/6895 - Commit ID: 4e1fd25d19e83774e41008c1ca35c6c27eb30270 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 4e1fd25d19e83774e41008c1ca35c6c27eb30270 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1584128992 + Commit Message: + selftests/bpf: Fix usleep() implementation nanosleep syscall expects pointer to struct timespec, not nanoseconds directly. Current implementation fulfills its purpose of invoking nanosleep syscall, but doesn't really provide sleeping capabilities, which can cause flakiness for tests relying on usleep() to wait for something. Fixes: ec12a57b822c ("selftests/bpf: Guarantee that useep() calls nanosleep() syscall") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200313061837.3685572-1-andriin@fb.com Signed-off-by: Alexei Starovoitov + Changed Files: tools/testing/selftests/bpf/test_progs.c | 11 ++++++++++-; 1 file changed, 10 insertions(+), 1 deletion(-) + Parent Hashes: 1afbcd9466f2fd979dde57ad424524a2fc5572e3 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes the usleep() function in BPF selftests to correctly implement nanosleep syscall.", + "keywords": "selftests,bpf,nanosleep", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes the usleep() functionality in BPF selftests by correctly utilizing nanosleep syscall with a struct timespec.", + "keywords": "selftests,usleep,nanosleep", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 381/6895 - Commit ID: 1afbcd9466f2fd979dde57ad424524a2fc5572e3 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 1afbcd9466f2fd979dde57ad424524a2fc5572e3 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1584128992 + Commit Message: + Merge branch 'generalize-bpf-ksym' Jiri Olsa says: ==================== this patchset adds trampoline and dispatcher objects to be visible in /proc/kallsyms. $ sudo cat /proc/kallsyms | tail -20 ... ffffffffa050f000 t bpf_prog_5a2b06eab81b8f51 [bpf] ffffffffa0511000 t bpf_prog_6deef7357e7b4530 [bpf] ffffffffa0542000 t bpf_trampoline_13832 [bpf] ffffffffa0548000 t bpf_prog_96f1b5bf4e4cc6dc_mutex_lock [bpf] ffffffffa0572000 t bpf_prog_d1c63e29ad82c4ab_bpf_prog1 [bpf] ffffffffa0585000 t bpf_prog_e314084d332a5338__dissect [bpf] ffffffffa0587000 t bpf_prog_59785a79eac7e5d2_mutex_unlock [bpf] ffffffffa0589000 t bpf_prog_d0db6e0cac050163_mutex_lock [bpf] ffffffffa058d000 t bpf_prog_d8f047721e4d8321_bpf_prog2 [bpf] ffffffffa05df000 t bpf_trampoline_25637 [bpf] ffffffffa05e3000 t bpf_prog_d8f047721e4d8321_bpf_prog2 [bpf] ffffffffa05e5000 t bpf_prog_3b185187f1855c4c [bpf] ffffffffa05e7000 t bpf_prog_d8f047721e4d8321_bpf_prog2 [bpf] ffffffffa05eb000 t bpf_prog_93cebb259dd5c4b2_do_sys_open [bpf] ffffffffa0677000 t bpf_dispatcher_xdp [bpf] v5 changes: - keeping just 1 bpf_tree for all the objects and adding flag to recognize bpf_objects when searching for exception tables [Alexei] - no need for is_bpf_image_address call in kernel_text_address [Alexei] - removed the bpf_image tree, because it's no longer needed v4 changes: - add trampoline and dispatcher to kallsyms once the it's allocated [Alexei] - omit the symbols sorting for kallsyms [Alexei] - small title change in one patch [Song] - some function renames: bpf_get_prog_name to bpf_prog_ksym_set_name bpf_get_prog_addr_region to bpf_prog_ksym_set_addr - added acks to changelogs - I checked and there'll be conflict on perftool side with upcoming changes from Adrian Hunter (text poke events), so I think it's better if Arnaldo takes the perf changes via perf tree and we will solve all conflicts there v3 changes: - use container_of directly in bpf_get_ksym_start [Daniel] - add more changelog explanations for ksym addresses [Daniel] v2 changes: - omit extra condition in __bpf_ksym_add for sorting code (Andrii) - rename bpf_kallsyms_tree_ops to bpf_ksym_tree (Andrii) - expose only executable code in kallsyms (Andrii) - use full trampoline key as its kallsyms id (Andrii) - explained the BPF_TRAMP_REPLACE case (Andrii) - small format changes in bpf_trampoline_link_prog/bpf_trampoline_unlink_prog (Andrii) - propagate error value in bpf_dispatcher_update and update kallsym if it's successful (Andrii) - get rid of __always_inline for bpf_ksym_tree callbacks (Andrii) - added KSYMBOL notification for bpf_image add/removal - added perf tools changes to properly display trampoline/dispatcher ==================== Signed-off-by: Alexei Starovoitov + Changed Files: nan + Parent Hashes: 98868668367b24487c0b0b3298d7ca98409baf07 7ac88eba185b4d0e06a71678e54bc092edcd3af3 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit merges a branch that generalizes BPF ksym usage by adding trampoline and dispatcher objects to /proc/kallsyms.", + "keywords": "trampoline,dispatcher,kallsyms", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "The commit merges bpf-ksym generalization by including trampoline and dispatcher objects in /proc/kallsyms.", + "keywords": "trampoline,dispatcher,kallsyms", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 382/6895 - Commit ID: 7ac88eba185b4d0e06a71678e54bc092edcd3af3 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 7ac88eba185b4d0e06a71678e54bc092edcd3af3 + Author Name: Jiri Olsa + Author Email: jolsa@kernel.org + Commit Date: 1584128992 + Commit Message: + bpf: Remove bpf_image tree Now that we have all the objects (bpf_prog, bpf_trampoline, bpf_dispatcher) linked in bpf_tree, there's no need to have separate bpf_image tree for images. Reverting the bpf_image tree together with struct bpf_image, because it's no longer needed. Also removing bpf_image_alloc function and adding the original bpf_jit_alloc_exec_page interface instead. The kernel_text_address function can now rely only on is_bpf_text_address, because it checks the bpf_tree that contains all the objects. Keeping bpf_image_ksym_add and bpf_image_ksym_del because they are useful wrappers with perf's ksymbol interface calls. Signed-off-by: Jiri Olsa Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200312195610.346362-13-jolsa@kernel.org Signed-off-by: Alexei Starovoitov + Changed Files: include/linux/bpf.h | 8 +----; kernel/bpf/dispatcher.c | 4 +--; kernel/bpf/trampoline.c | 83 ++++++-------------------------------------------; kernel/extable.c | 2 --; 4 files changed, 13 insertions(+), 84 deletions(-) + Parent Hashes: 517b75e44c7be9c776aa5f7beaa85baff3868f80 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit removes the unnecessary bpf_image tree, simplifying the use of the bpf_tree for object handling in eBPF.", + "keywords": "bpf_image,bpf_tree,remove", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit removes the bpf_image tree, streamlining bpf_tree usage for eBPF object management.", + "keywords": "bpf_image,remove,bpf_tree", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 383/6895 - Commit ID: 517b75e44c7be9c776aa5f7beaa85baff3868f80 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 517b75e44c7be9c776aa5f7beaa85baff3868f80 + Author Name: Jiri Olsa + Author Email: jolsa@kernel.org + Commit Date: 1584128992 + Commit Message: + bpf: Add dispatchers to kallsyms Adding dispatchers to kallsyms. It's displayed as bpf_dispatcher_ where NAME is the name of dispatcher. Signed-off-by: Jiri Olsa Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200312195610.346362-12-jolsa@kernel.org Signed-off-by: Alexei Starovoitov + Changed Files: include/linux/bpf.h | 19 ++++++++++++-------; kernel/bpf/dispatcher.c | 1 +; 2 files changed, 13 insertions(+), 7 deletions(-) + Parent Hashes: a108f7dcfa010e3da825af90d77ac0a6a0240992 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds bpf dispatchers to kallsyms to improve symbol resolution.", + "keywords": "bpf, kallsyms, dispatchers", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds bpf dispatchers to kallsyms for improved visibility and symbol resolution.", + "keywords": "bpf,kallsyms,dispatchers", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing." + ] +} +-------------------- +-------------------- +Processing Commit 384/6895 - Commit ID: a108f7dcfa010e3da825af90d77ac0a6a0240992 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: a108f7dcfa010e3da825af90d77ac0a6a0240992 + Author Name: Jiri Olsa + Author Email: jolsa@kernel.org + Commit Date: 1584128992 + Commit Message: + bpf: Add trampolines to kallsyms Adding trampolines to kallsyms. It's displayed as bpf_trampoline_ [bpf] where ID is the BTF id of the trampoline function. Adding bpf_image_ksym_add/del functions that setup the start/end values and call KSYMBOL perf events handlers. Signed-off-by: Jiri Olsa Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200312195610.346362-11-jolsa@kernel.org Signed-off-by: Alexei Starovoitov + Changed Files: include/linux/bpf.h | 3 +++; kernel/bpf/trampoline.c | 28 ++++++++++++++++++++++++++++; 2 files changed, 31 insertions(+) + Parent Hashes: dba122fb5e122e8e07e2f11cdebc10ba4f425cf7 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Added trampolines to kallsyms allowing identification as bpf_trampoline_ with BTF id, including setup and KSYMBOL perf events handler calls.", + "keywords": "trampolines,kallsyms,KSYMBOL", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Added trampolines to kallsyms with identification via bpf_trampoline_ and integrated KSYMBOL perf events handling.", + "keywords": "trampolines,kallsyms,perf", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 385/6895 - Commit ID: dba122fb5e122e8e07e2f11cdebc10ba4f425cf7 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: dba122fb5e122e8e07e2f11cdebc10ba4f425cf7 + Author Name: Jiri Olsa + Author Email: jolsa@kernel.org + Commit Date: 1584128992 + Commit Message: + bpf: Add bpf_ksym_add/del functions Separating /proc/kallsyms add/del code and adding bpf_ksym_add/del functions for that. Moving bpf_prog_ksym_node_add/del functions to __bpf_ksym_add/del and changing their argument to 'struct bpf_ksym' object. This way we can call them for other bpf objects types like trampoline and dispatcher. Signed-off-by: Jiri Olsa Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200312195610.346362-10-jolsa@kernel.org Signed-off-by: Alexei Starovoitov + Changed Files: include/linux/bpf.h | 3 +++; kernel/bpf/core.c | 33 +++++++++++++++++++--------------; 2 files changed, 22 insertions(+), 14 deletions(-) + Parent Hashes: cbd76f8d5ac9c4e99c4ffe5e39a1e907cdf5a76f +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds bpf_ksym_add/del functions to manage kernel symbols for eBPF objects.", + "keywords": "bpf,ksym,functions", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit introduces bpf_ksym_add/del functions for better management of eBPF kernel symbols.", + "keywords": "bpf,ksym,management", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 386/6895 - Commit ID: cbd76f8d5ac9c4e99c4ffe5e39a1e907cdf5a76f +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: cbd76f8d5ac9c4e99c4ffe5e39a1e907cdf5a76f + Author Name: Jiri Olsa + Author Email: jolsa@kernel.org + Commit Date: 1584128992 + Commit Message: + bpf: Add prog flag to struct bpf_ksym object Adding 'prog' bool flag to 'struct bpf_ksym' to mark that this object belongs to bpf_prog object. This change allows having bpf_prog objects together with other types (trampolines and dispatchers) in the single bpf_tree. It's used when searching for bpf_prog exception tables by the bpf_prog_ksym_find function, where we need to get the bpf_prog pointer. >From now we can safely add bpf_ksym support for trampoline or dispatcher objects, because we can differentiate them from bpf_prog objects. Signed-off-by: Jiri Olsa Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200312195610.346362-9-jolsa@kernel.org Signed-off-by: Alexei Starovoitov + Changed Files: include/linux/bpf.h | 1 +; kernel/bpf/core.c | 22 +++++++++++-----------; 2 files changed, 12 insertions(+), 11 deletions(-) + Parent Hashes: eda0c92902b57bbde674c27882554b074e9180a6 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds a 'prog' flag to the struct bpf_ksym to differentiate bpf_prog objects from other types.", + "keywords": "prog, bpf_ksym, flag", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds a 'prog' flag to the struct bpf_ksym to differentiate bpf_prog objects from other types.", + "keywords": "prog, bpf_ksym, flag", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 387/6895 - Commit ID: 98868668367b24487c0b0b3298d7ca98409baf07 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 98868668367b24487c0b0b3298d7ca98409baf07 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1584128991 + Commit Message: + bpf: Abstract away entire bpf_link clean up procedure Instead of requiring users to do three steps for cleaning up bpf_link, its anon_inode file, and unused fd, abstract that away into bpf_link_cleanup() helper. bpf_link_defunct() is removed, as it shouldn't be needed as an individual operation anymore. v1->v2: - keep bpf_link_cleanup() static for now (Daniel). Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200313002128.2028680-1-andriin@fb.com Signed-off-by: Alexei Starovoitov + Changed Files: include/linux/bpf.h | 1 -; kernel/bpf/syscall.c | 18 +++++++++++-------; 2 files changed, 11 insertions(+), 8 deletions(-) + Parent Hashes: 4cd729fa022cb5142e5b65f25589af61c8148cf6 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit introduces a helper function to simplify the cleanup process for bpf_link in the eBPF subsystem.", + "keywords": "bpf_link, cleanup, abstract", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The syscall interface. It changes the system calls through which user-space programs interact with eBPF.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit introduces a helper function to simplify the cleanup process for bpf_link in the eBPF subsystem.", + "keywords": "bpf_link, cleanup, abstract", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The syscall interface. It changes the system calls through which user-space programs interact with eBPF.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 388/6895 - Commit ID: eda0c92902b57bbde674c27882554b074e9180a6 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: eda0c92902b57bbde674c27882554b074e9180a6 + Author Name: Jiri Olsa + Author Email: jolsa@kernel.org + Commit Date: 1584128991 + Commit Message: + bpf: Add bpf_ksym_find function Adding bpf_ksym_find function that is used bpf bpf address lookup functions: __bpf_address_lookup is_bpf_text_address while keeping bpf_prog_kallsyms_find to be used only for lookup of bpf_prog objects (will happen in following changes). Signed-off-by: Jiri Olsa Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200312195610.346362-8-jolsa@kernel.org Signed-off-by: Alexei Starovoitov + Changed Files: kernel/bpf/core.c | 22 +++++++++++++++-------; 1 file changed, 15 insertions(+), 7 deletions(-) + Parent Hashes: ca4424c920f574b7246ff1b6d83cfdfd709e42c8 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds a new function, bpf_ksym_find, for BPF address lookup by modifying bpf/core.c.", + "keywords": "bpf, ksym, lookup", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit introduces bpf_ksym_find to facilitate BPF address lookup and adjusts bpf/core.c accordingly.", + "keywords": "bpf, ksym, lookup", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 389/6895 - Commit ID: 4cd729fa022cb5142e5b65f25589af61c8148cf6 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 4cd729fa022cb5142e5b65f25589af61c8148cf6 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1584128991 + Commit Message: + selftests/bpf: Make tcp_rtt test more robust to failures Switch to non-blocking accept and wait for server thread to exit before proceeding. I noticed that sometimes tcp_rtt server thread failure would "spill over" into other tests (that would run after tcp_rtt), probably just because server thread exits much later and tcp_rtt doesn't wait for it. v1->v2: - add usleep() while waiting on initial non-blocking accept() (Stanislav); Fixes: 8a03222f508b ("selftests/bpf: test_progs: fix client/server race in tcp_rtt") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Reviewed-by: Stanislav Fomichev Link: https://lore.kernel.org/bpf/20200311222749.458015-1-andriin@fb.com Signed-off-by: Alexei Starovoitov + Changed Files: tools/testing/selftests/bpf/prog_tests/tcp_rtt.c | 32 +++++++++++++++---------; 1 file changed, 20 insertions(+), 12 deletions(-) + Parent Hashes: 2b5cf9fb74848fe5742a56e872e6847b79933c0b +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Make the BPF tcp_rtt selftest more robust by using non-blocking accept and proper server thread termination.", + "keywords": "selftests BPF tcp_rtt", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Improve robustness of the BPF tcp_rtt selftest by using non-blocking accept and ensuring server thread exits properly.", + "keywords": "tcp_rtt non-blocking robustness", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 390/6895 - Commit ID: ca4424c920f574b7246ff1b6d83cfdfd709e42c8 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: ca4424c920f574b7246ff1b6d83cfdfd709e42c8 + Author Name: Jiri Olsa + Author Email: jolsa@kernel.org + Commit Date: 1584128991 + Commit Message: + bpf: Move ksym_tnode to bpf_ksym Moving ksym_tnode list node to 'struct bpf_ksym' object, so the symbol itself can be chained and used in other objects like bpf_trampoline and bpf_dispatcher. We need bpf_ksym object to be linked both in bpf_kallsyms via lnode for /proc/kallsyms and in bpf_tree via tnode for bpf address lookup functions like __bpf_address_lookup or bpf_prog_kallsyms_find. Signed-off-by: Jiri Olsa Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200312195610.346362-7-jolsa@kernel.org Signed-off-by: Alexei Starovoitov + Changed Files: include/linux/bpf.h | 2 +-; kernel/bpf/core.c | 24 ++++++++++--------------; 2 files changed, 11 insertions(+), 15 deletions(-) + Parent Hashes: ecb60d1c670e9b205197d8e4381b19e77bc2d834 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit moves ksym_tnode to bpf_ksym for better integration with bpf_trampoline and bpf_dispatcher.", + "keywords": "ksym_tnode,bpf_ksym,bpf_kallsyms", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit integrates ksym_tnode into bpf_ksym for improved symbol chaining across various eBPF components.", + "keywords": "ksym_tnode,bpf_ksym,bpf_trampoline", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 391/6895 - Commit ID: 2b5cf9fb74848fe5742a56e872e6847b79933c0b +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 2b5cf9fb74848fe5742a56e872e6847b79933c0b + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1584128991 + Commit Message: + selftests/bpf: Guarantee that useep() calls nanosleep() syscall Some implementations of C runtime library won't call nanosleep() syscall from usleep(). But a bunch of kprobe/tracepoint selftests rely on nanosleep being called to trigger them. To make this more reliable, "override" usleep implementation and call nanosleep explicitly. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Cc: Julia Kartseva Link: https://lore.kernel.org/bpf/20200311185345.3874602-1-andriin@fb.com Signed-off-by: Alexei Starovoitov + Changed Files: tools/testing/selftests/bpf/test_progs.c | 9 +++++++++; 1 file changed, 9 insertions(+) + Parent Hashes: 6ae32b29c09ba9b99c4c7317eed029587bd2706d +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit ensures nanosleep syscall is explicitly called for kprobe/tracepoint selftests by overriding usleep implementation.", + "keywords": "nanosleep,kprobe,usleep", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events." + ] +} +Rethinking... +new content: +{ + "summary": "The commit ensures nanosleep syscall is explicitly called for kprobe/tracepoint selftests by overriding usleep implementation.", + "keywords": "nanosleep,kprobe,usleep", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events." + ] +} +-------------------- +-------------------- +Processing Commit 392/6895 - Commit ID: ecb60d1c670e9b205197d8e4381b19e77bc2d834 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: ecb60d1c670e9b205197d8e4381b19e77bc2d834 + Author Name: Jiri Olsa + Author Email: jolsa@kernel.org + Commit Date: 1584128991 + Commit Message: + bpf: Move lnode list node to struct bpf_ksym Adding lnode list node to 'struct bpf_ksym' object, so the struct bpf_ksym itself can be chained and used in other objects like bpf_trampoline and bpf_dispatcher. Changing iterator to bpf_ksym in bpf_get_kallsym function. The ksym->start is holding the prog->bpf_func value, so it's ok to use it as value in bpf_get_kallsym. Signed-off-by: Jiri Olsa Signed-off-by: Alexei Starovoitov Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200312195610.346362-6-jolsa@kernel.org Signed-off-by: Alexei Starovoitov + Changed Files: include/linux/bpf.h | 2 +-; kernel/bpf/core.c | 22 +++++++++++-----------; 2 files changed, 12 insertions(+), 12 deletions(-) + Parent Hashes: bfea9a8574f34597581f74f792d044d38497b775 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit moves the lnode list node to struct bpf_ksym for chaining in other objects like bpf_trampoline and bpf_dispatcher.", + "keywords": "lnode,struct,bpf_ksym", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds the lnode list node to struct bpf_ksym for use in bpf_trampoline and bpf_dispatcher.", + "keywords": "lnode,bpf_ksym,struct", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 393/6895 - Commit ID: 6ae32b29c09ba9b99c4c7317eed029587bd2706d +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 6ae32b29c09ba9b99c4c7317eed029587bd2706d + Author Name: Quentin Monnet + Author Email: quentin@isovalent.com + Commit Date: 1584128991 + Commit Message: + tools: bpftool: Restore message on failure to guess program type In commit 4a3d6c6a6e4d ("libbpf: Reduce log level for custom section names"), log level for messages for libbpf_attach_type_by_name() and libbpf_prog_type_by_name() was downgraded from "info" to "debug". The latter function, in particular, is used by bpftool when attempting to load programs, and this change caused bpftool to exit with no hint or error message when it fails to detect the type of the program to load (unless "-d" option was provided). To help users understand why bpftool fails to load the program, let's do a second run of the function with log level in "debug" mode in case of failure. Before: # bpftool prog load sample_ret0.o /sys/fs/bpf/sample_ret0 # echo $? 255 Or really verbose with -d flag: # bpftool -d prog load sample_ret0.o /sys/fs/bpf/sample_ret0 libbpf: loading sample_ret0.o libbpf: section(1) .strtab, size 134, link 0, flags 0, type=3 libbpf: skip section(1) .strtab libbpf: section(2) .text, size 16, link 0, flags 6, type=1 libbpf: found program .text libbpf: section(3) .debug_abbrev, size 55, link 0, flags 0, type=1 libbpf: skip section(3) .debug_abbrev libbpf: section(4) .debug_info, size 75, link 0, flags 0, type=1 libbpf: skip section(4) .debug_info libbpf: section(5) .rel.debug_info, size 32, link 14, flags 0, type=9 libbpf: skip relo .rel.debug_info(5) for section(4) libbpf: section(6) .debug_str, size 150, link 0, flags 30, type=1 libbpf: skip section(6) .debug_str libbpf: section(7) .BTF, size 155, link 0, flags 0, type=1 libbpf: section(8) .BTF.ext, size 80, link 0, flags 0, type=1 libbpf: section(9) .rel.BTF.ext, size 32, link 14, flags 0, type=9 libbpf: skip relo .rel.BTF.ext(9) for section(8) libbpf: section(10) .debug_frame, size 40, link 0, flags 0, type=1 libbpf: skip section(10) .debug_frame libbpf: section(11) .rel.debug_frame, size 16, link 14, flags 0, type=9 libbpf: skip relo .rel.debug_frame(11) for section(10) libbpf: section(12) .debug_line, size 74, link 0, flags 0, type=1 libbpf: skip section(12) .debug_line libbpf: section(13) .rel.debug_line, size 16, link 14, flags 0, type=9 libbpf: skip relo .rel.debug_line(13) for section(12) libbpf: section(14) .symtab, size 96, link 1, flags 0, type=2 libbpf: looking for externs among 4 symbols... libbpf: collected 0 externs total libbpf: failed to guess program type from ELF section '.text' libbpf: supported section(type) names are: socket sk_reuseport kprobe/ [...] After: # bpftool prog load sample_ret0.o /sys/fs/bpf/sample_ret0 libbpf: failed to guess program type from ELF section '.text' libbpf: supported section(type) names are: socket sk_reuseport kprobe/ [...] Signed-off-by: Quentin Monnet Signed-off-by: Alexei Starovoitov Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200311021205.9755-1-quentin@isovalent.com Signed-off-by: Alexei Starovoitov + Changed Files: tools/bpf/bpftool/common.c | 7 +++++++; tools/bpf/bpftool/main.c | 7 -------; tools/bpf/bpftool/main.h | 5 +++++; tools/bpf/bpftool/prog.c | 27 +++++++++++++++++++++++----; 4 files changed, 35 insertions(+), 11 deletions(-) + Parent Hashes: d831ee84bfc9173eecf30dbbc2553ae81b996c60 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit restores error messages in bpftool when failing to determine eBPF program type by running debug logs in case of failure.", + "keywords": "bpftool,error,debug", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit enhances bpftool to display error messages when it fails to determine eBPF program type by running debug logs on failure.", + "keywords": "bpftool,error,message", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 394/6895 - Commit ID: bfea9a8574f34597581f74f792d044d38497b775 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: bfea9a8574f34597581f74f792d044d38497b775 + Author Name: Jiri Olsa + Author Email: jolsa@kernel.org + Commit Date: 1584128991 + Commit Message: + bpf: Add name to struct bpf_ksym Adding name to 'struct bpf_ksym' object to carry the name of the symbol for bpf_prog, bpf_trampoline, bpf_dispatcher objects. The current benefit is that name is now generated only when the symbol is added to the list, so we don't need to generate it every time it's accessed. The future benefit is that we will have all the bpf objects symbols represented by struct bpf_ksym. Signed-off-by: Jiri Olsa Signed-off-by: Alexei Starovoitov Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200312195610.346362-5-jolsa@kernel.org Signed-off-by: Alexei Starovoitov + Changed Files: include/linux/bpf.h | 2 ++; include/linux/filter.h | 6 ------; kernel/bpf/core.c | 9 ++++++---; kernel/events/core.c | 9 ++++-----; 4 files changed, 12 insertions(+), 14 deletions(-) + Parent Hashes: 535911c80ad4f5801700e9d827a1985bbff41519 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Added name field to struct bpf_ksym for efficient symbol name generation and representation of bpf objects.", + "keywords": "bpf, ksym, symbol", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Added name field to struct bpf_ksym for efficient symbol name generation and representation of bpf objects.", + "keywords": "bpf, ksym, symbol", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 395/6895 - Commit ID: 535911c80ad4f5801700e9d827a1985bbff41519 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 535911c80ad4f5801700e9d827a1985bbff41519 + Author Name: Jiri Olsa + Author Email: jolsa@kernel.org + Commit Date: 1584128991 + Commit Message: + bpf: Add struct bpf_ksym Adding 'struct bpf_ksym' object that will carry the kallsym information for bpf symbol. Adding the start and end address to begin with. It will be used by bpf_prog, bpf_trampoline, bpf_dispatcher objects. The symbol_start/symbol_end values were originally used to sort bpf_prog objects. For the address displayed in /proc/kallsyms we are using prog->bpf_func value. I'm using the bpf_func value for program symbol start instead of the symbol_start, because it makes no difference for sorting bpf_prog objects and we can use it directly as an address to display it in /proc/kallsyms. Signed-off-by: Jiri Olsa Signed-off-by: Alexei Starovoitov Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200312195610.346362-4-jolsa@kernel.org Signed-off-by: Alexei Starovoitov + Changed Files: include/linux/bpf.h | 6 ++++++; kernel/bpf/core.c | 28 ++++++++++++----------------; 2 files changed, 18 insertions(+), 16 deletions(-) + Parent Hashes: 6a64037d4bf252bb8cf13917320c8e001da8997a +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit introduces 'struct bpf_ksym' to manage kallsym information for eBPF symbols with start and end addresses.", + "keywords": "bpf_ksym,kallsym,eBPF", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds 'struct bpf_ksym' which manages kallsym information for BPF symbols with start and end addresses.", + "keywords": "bpf_ksym,kallsym,symbol", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 396/6895 - Commit ID: 6a64037d4bf252bb8cf13917320c8e001da8997a +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 6a64037d4bf252bb8cf13917320c8e001da8997a + Author Name: Björn Töpel + Author Email: bjorn.topel@intel.com + Commit Date: 1584128991 + Commit Message: + bpf: Add bpf_trampoline_ name prefix for DECLARE_BPF_DISPATCHER Adding bpf_trampoline_ name prefix for DECLARE_BPF_DISPATCHER, so all the dispatchers have the common name prefix. And also a small '_' cleanup for bpf_dispatcher_nopfunc function name. Signed-off-by: Björn Töpel Signed-off-by: Jiri Olsa Signed-off-by: Alexei Starovoitov Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200312195610.346362-3-jolsa@kernel.org Signed-off-by: Alexei Starovoitov + Changed Files: include/linux/bpf.h | 21 +++++++++++----------; include/linux/filter.h | 9 ++++-----; net/core/filter.c | 5 ++---; 3 files changed, 17 insertions(+), 18 deletions(-) + Parent Hashes: b56cd05c55a10afd479a1877d7f6a50d92d8536e +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit prefixes dispatcher functions with 'bpf_trampoline_' for consistency and cleans up a function name.", + "keywords": "bpf_trampoline, dispatcher, cleanup", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit prefixes dispatcher functions with 'bpf_trampoline_' for consistency and cleans up a function name.", + "keywords": "bpf_trampoline, dispatcher, cleanup", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 397/6895 - Commit ID: b56cd05c55a10afd479a1877d7f6a50d92d8536e +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: b56cd05c55a10afd479a1877d7f6a50d92d8536e + Author Name: Jiri Olsa + Author Email: jolsa@kernel.org + Commit Date: 1584128991 + Commit Message: + x86/mm: Rename is_kernel_text to __is_kernel_text The kbuild test robot reported compile issue on x86 in one of the following patches that adds include into , which is picked up by init_32.c object. The problem is that defines global function is_kernel_text which colides with the static function of the same name defined in init_32.c: $ make ARCH=i386 ... >> arch/x86/mm/init_32.c:241:19: error: redefinition of 'is_kernel_text' static inline int is_kernel_text(unsigned long addr) ^~~~~~~~~~~~~~ In file included from include/linux/bpf.h:21:0, from include/linux/bpf-cgroup.h:5, from include/linux/cgroup-defs.h:22, from include/linux/cgroup.h:28, from include/linux/hugetlb.h:9, from arch/x86/mm/init_32.c:18: include/linux/kallsyms.h:31:19: note: previous definition of 'is_kernel_text' was here static inline int is_kernel_text(unsigned long addr) Renaming the init_32.c is_kernel_text function to __is_kernel_text. Reported-by: kbuild test robot Signed-off-by: Jiri Olsa Signed-off-by: Alexei Starovoitov Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200312195610.346362-2-jolsa@kernel.org Signed-off-by: Alexei Starovoitov + Changed Files: arch/x86/mm/init_32.c | 14 +++++++++-----; 1 file changed, 9 insertions(+), 5 deletions(-) + Parent Hashes: 98868668367b24487c0b0b3298d7ca98409baf07 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit renames a function in x86 init_32.c to resolve a naming conflict with a function in kallsyms.h.", + "keywords": "rename,function,conflict", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit resolves a naming conflict by renaming a function in x86 init_32.c.", + "keywords": "rename,function,conflict", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +-------------------- +-------------------- +Processing Commit 398/6895 - Commit ID: 242a6df688dcad7c55105280a79aaff83addf7ce +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 242a6df688dcad7c55105280a79aaff83addf7ce + Author Name: David S. Miller + Author Email: davem@davemloft.net + Commit Date: 1584123225 + Commit Message: + Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf Alexei Starovoitov says: ==================== pull-request: bpf 2020-03-12 The following pull-request contains BPF updates for your *net* tree. We've added 12 non-merge commits during the last 8 day(s) which contain a total of 12 files changed, 161 insertions(+), 15 deletions(-). The main changes are: 1) Andrii fixed two bugs in cgroup-bpf. 2) John fixed sockmap. 3) Luke fixed x32 jit. 4) Martin fixed two issues in struct_ops. 5) Yonghong fixed bpf_send_signal. 6) Yoshiki fixed BTF enum. ==================== Signed-off-by: David S. Miller + Changed Files: nan + Parent Hashes: 0d81a3f29c0afb18ba2b1275dcccf21e0dd4da38 90db6d772f749e38171d04619a5e3cd8804a6d02 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit merges multiple BPF updates including bug fixes in various components like cgroup-bpf and sockmap into the *net* tree.", + "keywords": "merge,BPF,fixes", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "The commit merges multiple BPF updates including bug fixes in components like cgroup-bpf and sockmap into the *net* tree.", + "keywords": "merge,BPF,fixes", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 399/6895 - Commit ID: d831ee84bfc9173eecf30dbbc2553ae81b996c60 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: d831ee84bfc9173eecf30dbbc2553ae81b996c60 + Author Name: Eelco Chaudron + Author Email: echaudro@redhat.com + Commit Date: 1584060458 + Commit Message: + bpf: Add bpf_xdp_output() helper Introduce new helper that reuses existing xdp perf_event output implementation, but can be called from raw_tracepoint programs that receive 'struct xdp_buff *' as a tracepoint argument. Signed-off-by: Eelco Chaudron Signed-off-by: Alexei Starovoitov Acked-by: John Fastabend Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/158348514556.2239.11050972434793741444.stgit@xdp-tutorial + Changed Files: include/uapi/linux/bpf.h | 26 ++++++++++-; kernel/bpf/verifier.c | 4 +-; kernel/trace/bpf_trace.c | 3 ++; net/core/filter.c | 16 ++++++-; tools/include/uapi/linux/bpf.h | 26 ++++++++++-; .../testing/selftests/bpf/prog_tests/xdp_bpf2bpf.c | 53 ++++++++++++++++++++++; .../testing/selftests/bpf/progs/test_xdp_bpf2bpf.c | 24 ++++++++++; 7 files changed, 148 insertions(+), 4 deletions(-) + Parent Hashes: 4823b7210b90a10b88b0c56198f894b27a767509 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit introduces the bpf_xdp_output() helper for raw_tracepoint programs to output perf events using xdp_buff structures.", + "keywords": "bpf_xdp_output, raw_tracepoint, xdp_buff", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit introduces a new bpf_xdp_output() helper for raw_tracepoint programs to leverage xdp_buff structures for perf event outputs.", + "keywords": "bpf_xdp_output, raw_tracepoint, xdp_buff", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 400/6895 - Commit ID: 4823b7210b90a10b88b0c56198f894b27a767509 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 4823b7210b90a10b88b0c56198f894b27a767509 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1584060062 + Commit Message: + Merge branch 'bpf_get_ns_current_pid_tgid' Carlos Neira says: ==================== Currently bpf_get_current_pid_tgid(), is used to do pid filtering in bcc's scripts but this helper returns the pid as seen by the root namespace which is fine when a bcc script is not executed inside a container. When the process of interest is inside a container, pid filtering will not work if bpf_get_current_pid_tgid() is used. This helper addresses this limitation returning the pid as it's seen by the current namespace where the script is executing. In the future different pid_ns files may belong to different devices, according to the discussion between Eric Biederman and Yonghong in 2017 Linux plumbers conference. To address that situation the helper requires inum and dev_t from /proc/self/ns/pid. This helper has the same use cases as bpf_get_current_pid_tgid() as it can be used to do pid filtering even inside a container. ==================== Signed-off-by: Alexei Starovoitov + Changed Files: nan + Parent Hashes: 132c1af0a23d049e2ec93eb6a180d9de71d3a32f 1c1052e0140af8f211c283c0a333ecff2a6edfc9 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Merges changes to allow PID filtering within container namespaces using a new bpf helper method.", + "keywords": "PID, namespaces, container", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups).", + "It's likely a merge commit. It involves changes across multiple use cases or events.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Merges changes to introduce a helper for obtaining PIDs in the current namespace for container compatibility.", + "keywords": "PID, filter, namespace", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups).", + "It's likely a merge commit. It involves changes across multiple use cases or events.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 401/6895 - Commit ID: 1c1052e0140af8f211c283c0a333ecff2a6edfc9 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 1c1052e0140af8f211c283c0a333ecff2a6edfc9 + Author Name: Carlos Neira + Author Email: cneirabustos@gmail.com + Commit Date: 1584060047 + Commit Message: + tools/testing/selftests/bpf: Add self-tests for new helper bpf_get_ns_current_pid_tgid. Self tests added for new helper bpf_get_ns_current_pid_tgid Signed-off-by: Carlos Neira Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200304204157.58695-4-cneirabustos@gmail.com + Changed Files: tools/testing/selftests/bpf/.gitignore | 1 +; tools/testing/selftests/bpf/Makefile | 3 +-; .../selftests/bpf/prog_tests/ns_current_pid_tgid.c | 88 ++++++++++++; .../selftests/bpf/progs/test_ns_current_pid_tgid.c | 37 +++++; .../selftests/bpf/test_current_pid_tgid_new_ns.c | 159 +++++++++++++++++++++; 5 files changed, 287 insertions(+), 1 deletion(-) + Parent Hashes: b4490c5c4e023f09b7d27c9a9d3e7ad7d09ea6bf +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds self-tests for the new eBPF helper bpf_get_ns_current_pid_tgid.", + "keywords": "self-tests,new helper,bpf", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds self-tests for the new eBPF helper bpf_get_ns_current_pid_tgid.", + "keywords": "self-tests,new helper,bpf", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 402/6895 - Commit ID: b4490c5c4e023f09b7d27c9a9d3e7ad7d09ea6bf +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: b4490c5c4e023f09b7d27c9a9d3e7ad7d09ea6bf + Author Name: Carlos Neira + Author Email: cneirabustos@gmail.com + Commit Date: 1584059591 + Commit Message: + bpf: Added new helper bpf_get_ns_current_pid_tgid New bpf helper bpf_get_ns_current_pid_tgid, This helper will return pid and tgid from current task which namespace matches dev_t and inode number provided, this will allows us to instrument a process inside a container. Signed-off-by: Carlos Neira Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200304204157.58695-3-cneirabustos@gmail.com + Changed Files: include/linux/bpf.h | 1 +; include/uapi/linux/bpf.h | 20 ++++++++++++++++++-; kernel/bpf/core.c | 1 +; kernel/bpf/helpers.c | 45 ++++++++++++++++++++++++++++++++++++++++++; kernel/trace/bpf_trace.c | 2 ++; scripts/bpf_helpers_doc.py | 1 +; tools/include/uapi/linux/bpf.h | 20 ++++++++++++++++++-; 7 files changed, 88 insertions(+), 2 deletions(-) + Parent Hashes: 1e2328e762548c7d17b7ba8ded9f409d05710dd1 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds a new eBPF helper function to retrieve the PID and TGID for processes in specific namespaces using device and inode criteria.", + "keywords": "helper,namespace,pid", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds a new eBPF helper function to retrieve the PID and TGID for processes in specific namespaces using device and inode criteria.", + "keywords": "helper,namespace,pid", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 403/6895 - Commit ID: 1e2328e762548c7d17b7ba8ded9f409d05710dd1 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 1e2328e762548c7d17b7ba8ded9f409d05710dd1 + Author Name: Carlos Neira + Author Email: cneirabustos@gmail.com + Commit Date: 1584059591 + Commit Message: + fs/nsfs.c: Added ns_match ns_match returns true if the namespace inode and dev_t matches the ones provided by the caller. Signed-off-by: Carlos Neira Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200304204157.58695-2-cneirabustos@gmail.com + Changed Files: fs/nsfs.c | 14 ++++++++++++++; include/linux/proc_ns.h | 2 ++; 2 files changed, 16 insertions(+) + Parent Hashes: 132c1af0a23d049e2ec93eb6a180d9de71d3a32f +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds a function to match namespace inodes and device identifiers in Linux filesystem code.", + "keywords": "ns_match, namespace, inode", + "commit_classification": "It's other type of commit. It does not fit into any of the categories listed above.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds a function to match namespace inodes and device identifiers in the Linux filesystem code.", + "keywords": "ns_match, namespace, inode", + "commit_classification": "It's other type of commit. It does not fit into any of the categories listed above.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +-------------------- +-------------------- +Processing Commit 404/6895 - Commit ID: 132c1af0a23d049e2ec93eb6a180d9de71d3a32f +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 132c1af0a23d049e2ec93eb6a180d9de71d3a32f + Author Name: Quentin Monnet + Author Email: quentin@isovalent.com + Commit Date: 1584055448 + Commit Message: + tools: bpftool: Fix minor bash completion mistakes Minor fixes for bash completion: addition of program name completion for two subcommands, and correction for program test-runs and map pinning. The completion for the following commands is fixed or improved: # bpftool prog run [TAB] # bpftool prog pin [TAB] # bpftool map pin [TAB] # bpftool net attach xdp name [TAB] Signed-off-by: Quentin Monnet Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200312184608.12050-3-quentin@isovalent.com + Changed Files: tools/bpf/bpftool/bash-completion/bpftool | 29 +++++++++++++++++++++--------; 1 file changed, 21 insertions(+), 8 deletions(-) + Parent Hashes: 75a1e792c335b5c6d7fdb1014da47aeb64c5944f +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes and improves the bash completion for bpftool subcommands related to program and map operations.", + "keywords": "bash,completion,bpftool", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit corrects and enhances bash completion for bpftool commands related to program and map operations.", + "keywords": "bash,completion,bpftool", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 405/6895 - Commit ID: 75a1e792c335b5c6d7fdb1014da47aeb64c5944f +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 75a1e792c335b5c6d7fdb1014da47aeb64c5944f + Author Name: Quentin Monnet + Author Email: quentin@isovalent.com + Commit Date: 1584055448 + Commit Message: + tools: bpftool: Allow all prog/map handles for pinning objects Documentation and interactive help for bpftool have always explained that the regular handles for programs (id|name|tag|pinned) and maps (id|name|pinned) can be passed to the utility when attempting to pin objects (bpftool prog pin PROG / bpftool map pin MAP). THIS IS A LIE!! The tool actually accepts only ids, as the parsing is done in do_pin_any() in common.c instead of reusing the parsing functions that have long been generic for program and map handles. Instead of fixing the doc, fix the code. It is trivial to reuse the generic parsing, and to simplify do_pin_any() in the process. Do not accept to pin multiple objects at the same time with prog_parse_fds() or map_parse_fds() (this would require a more complex syntax for passing multiple sysfs paths and validating that they correspond to the number of e.g. programs we find for a given name or tag). Signed-off-by: Quentin Monnet Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200312184608.12050-2-quentin@isovalent.com + Changed Files: tools/bpf/bpftool/common.c | 33 ++++-----------------------------; tools/bpf/bpftool/main.h | 2 +-; tools/bpf/bpftool/map.c | 2 +-; tools/bpf/bpftool/prog.c | 2 +-; 4 files changed, 7 insertions(+), 32 deletions(-) + Parent Hashes: b35f14f410416f06ec54d187dedc372405757290 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fix bpftool to correctly accept all supported program and map handles for pinning objects, aligning code with documentation.", + "keywords": "bpftool, parsing, pinning", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Fix bpftool to correctly accept all supported program and map handles for pinning objects, aligning code with documentation.", + "keywords": "bpftool, parsing, pinning", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 406/6895 - Commit ID: b35f14f410416f06ec54d187dedc372405757290 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: b35f14f410416f06ec54d187dedc372405757290 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1584054916 + Commit Message: + libbpf: Split BTF presence checks into libbpf- and kernel-specific parts Needs for application BTF being present differs between user-space libbpf needs and kernel needs. Currently, BTF is mandatory only in kernel only when BPF application is using STRUCT_OPS. While libbpf itself relies more heavily on presense of BTF: - for BTF-defined maps; - for Kconfig externs; - for STRUCT_OPS as well. Thus, checks for presence and validness of bpf_object's BPF needs to be performed separately, which is patch does. Fixes: 5327644614a1 ("libbpf: Relax check whether BTF is mandatory") Reported-by: Michal Rostecki Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Cc: Quentin Monnet Link: https://lore.kernel.org/bpf/20200312185033.736911-1-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.c | 17 ++++++++++++-----; 1 file changed, 12 insertions(+), 5 deletions(-) + Parent Hashes: 8d830f549dbd2f9cc4656a17704a2896682cbb5b +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Split BTF checks into libbpf and kernel-specific parts to differentiate BTF needs.", + "keywords": "libbpf, BTF, STRUCT_OPS", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems." + ] +} +Rethinking... +new content: +{ + "summary": "The commit separates BTF checks into user-space libbpf and kernel-specific requirements.", + "keywords": "libbpf, BTF, STRUCT_OPS", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems." + ] +} +-------------------- +-------------------- +Processing Commit 407/6895 - Commit ID: 8d830f549dbd2f9cc4656a17704a2896682cbb5b +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 8d830f549dbd2f9cc4656a17704a2896682cbb5b + Author Name: Song Liu + Author Email: songliubraving@fb.com + Commit Date: 1584054513 + Commit Message: + bpftool: Add _bpftool and profiler.skel.h to .gitignore These files are generated, so ignore them. Signed-off-by: Song Liu Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200312182332.3953408-4-songliubraving@fb.com + Changed Files: tools/bpf/bpftool/.gitignore | 2 ++; 1 file changed, 2 insertions(+) + Parent Hashes: 39be909c38a42543239de97087d3c93ea9272864 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds auto-generated files _bpftool and profiler.skel.h to .gitignore in bpftool.", + "keywords": "bpftool,gitignore,generated", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds auto-generated files _bpftool and profiler.skel.h to .gitignore in bpftool.", + "keywords": "bpftool,gitignore,generated", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 408/6895 - Commit ID: 39be909c38a42543239de97087d3c93ea9272864 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 39be909c38a42543239de97087d3c93ea9272864 + Author Name: Song Liu + Author Email: songliubraving@fb.com + Commit Date: 1584054513 + Commit Message: + bpftool: Skeleton should depend on libbpf Add the dependency to libbpf, to fix build errors like: In file included from skeleton/profiler.bpf.c:5: .../bpf_helpers.h:5:10: fatal error: 'bpf_helper_defs.h' file not found #include "bpf_helper_defs.h" ^~~~~~~~~~~~~~~~~~~ 1 error generated. make: *** [skeleton/profiler.bpf.o] Error 1 make: *** Waiting for unfinished jobs.... Fixes: 47c09d6a9f67 ("bpftool: Introduce "prog profile" command") Suggested-by: Quentin Monnet Signed-off-by: Song Liu Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200312182332.3953408-3-songliubraving@fb.com + Changed Files: tools/bpf/bpftool/Makefile | 5 +++--; 1 file changed, 3 insertions(+), 2 deletions(-) + Parent Hashes: 14e5728ff8176d4d5924b0bf5ab9b1c94d6b3381 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds a dependency on libbpf to the bpftool to prevent build errors.", + "keywords": "libbpf,bpftool,dependency", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds a dependency on libbpf to the bpftool to prevent build errors.", + "keywords": "libbpf,bpftool,dependency", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 409/6895 - Commit ID: 14e5728ff8176d4d5924b0bf5ab9b1c94d6b3381 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 14e5728ff8176d4d5924b0bf5ab9b1c94d6b3381 + Author Name: Song Liu + Author Email: songliubraving@fb.com + Commit Date: 1584054513 + Commit Message: + bpftool: Only build bpftool-prog-profile if supported by clang bpftool-prog-profile requires clang to generate BTF for global variables. When compared with older clang, skip this command. This is achieved by adding a new feature, clang-bpf-global-var, to tools/build/feature. Signed-off-by: Song Liu Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200312182332.3953408-2-songliubraving@fb.com + Changed Files: tools/bpf/bpftool/Makefile | 15 +++++++++++----; tools/bpf/bpftool/prog.c | 1 +; tools/build/feature/Makefile | 9 ++++++++-; tools/build/feature/test-clang-bpf-global-var.c | 4 ++++; 4 files changed, 24 insertions(+), 5 deletions(-) + Parent Hashes: fe4eb069edb7ab845160350d9e67d572c026a4a7 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit updates bpftool to only build bpftool-prog-profile if clang supports BTF generation for global variables.", + "keywords": "bpftool,clang,BTF", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit updates bpftool to only build bpftool-prog-profile if clang supports BTF generation for global variables.", + "keywords": "bpftool,clang,BTF", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 410/6895 - Commit ID: fe4eb069edb7ab845160350d9e67d572c026a4a7 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: fe4eb069edb7ab845160350d9e67d572c026a4a7 + Author Name: Tobias Klauser + Author Email: tklauser@distanz.ch + Commit Date: 1584026561 + Commit Message: + bpftool: Use linux/types.h from source tree for profiler build When compiling bpftool on a system where the /usr/include/asm symlink doesn't exist (e.g. on an Ubuntu system without gcc-multilib installed), the build fails with: CLANG skeleton/profiler.bpf.o In file included from skeleton/profiler.bpf.c:4: In file included from /usr/include/linux/bpf.h:11: /usr/include/linux/types.h:5:10: fatal error: 'asm/types.h' file not found #include ^~~~~~~~~~~~~ 1 error generated. make: *** [Makefile:123: skeleton/profiler.bpf.o] Error 1 This indicates that the build is using linux/types.h from system headers instead of source tree headers. To fix this, adjust the clang search path to include the necessary headers from tools/testing/selftests/bpf/include/uapi and tools/include/uapi. Also use __bitwise__ instead of __bitwise in skeleton/profiler.h to avoid clashing with the definition in tools/testing/selftests/bpf/include/uapi/linux/types.h. Signed-off-by: Tobias Klauser Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200312130330.32239-1-tklauser@distanz.ch + Changed Files: tools/bpf/bpftool/Makefile | 5 ++++-; tools/bpf/bpftool/skeleton/profiler.h | 17 ++++++++---------; 2 files changed, 12 insertions(+), 10 deletions(-) + Parent Hashes: 37ccc12bbcef880e6b3fdf7e03cf9e5fe9df99f2 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit fixes a header path issue in bpftool to ensure proper compilation on certain systems.", + "keywords": "bpftool,header,build", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit fixes a header file inclusion issue in bpftool to ensure proper compilation across different systems.", + "keywords": "bpftool, compilation, header", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 411/6895 - Commit ID: 37ccc12bbcef880e6b3fdf7e03cf9e5fe9df99f2 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 37ccc12bbcef880e6b3fdf7e03cf9e5fe9df99f2 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1583936259 + Commit Message: + tools/runqslower: Add BPF_F_CURRENT_CPU for running selftest on older kernels Libbpf compiles and runs subset of selftests on each PR in its Github mirror repository. To allow still building up-to-date selftests against outdated kernel images, add back BPF_F_CURRENT_CPU definitions back. N.B. BCC's runqslower version ([0]) doesn't need BPF_F_CURRENT_CPU due to use of locally checked in vmlinux.h, generated against kernel with 1aae4bdd7879 ("bpf: Switch BPF UAPI #define constants used from BPF program side to enums") applied. [0] https://github.com/iovisor/bcc/pull/2809 Fixes: 367d82f17eff (" tools/runqslower: Drop copy/pasted BPF_F_CURRENT_CPU definiton") Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200311043010.530620-1-andriin@fb.com + Changed Files: tools/bpf/runqslower/runqslower.bpf.c | 1 +; 1 file changed, 1 insertion(+) + Parent Hashes: 13fac1d851e09109096b5862bf37c3da6908fb48 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit reintroduces BPF_F_CURRENT_CPU definition to runqslower for compatibility with older kernels.", + "keywords": "runqslower,BPF_F_CURRENT_CPU,selftest", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit reintroduces BPF_F_CURRENT_CPU definition to runqslower for compatibility with older kernels in selftests.", + "keywords": "runqslower,BPF_F_CURRENT_CPU,compatibility", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 412/6895 - Commit ID: 90db6d772f749e38171d04619a5e3cd8804a6d02 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 90db6d772f749e38171d04619a5e3cd8804a6d02 + Author Name: John Fastabend + Author Email: john.fastabend@gmail.com + Commit Date: 1583932132 + Commit Message: + bpf, sockmap: Remove bucket->lock from sock_{hash|map}_free The bucket->lock is not needed in the sock_hash_free and sock_map_free calls, in fact it is causing a splat due to being inside rcu block. | BUG: sleeping function called from invalid context at net/core/sock.c:2935 | in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 62, name: kworker/0:1 | 3 locks held by kworker/0:1/62: | #0: ffff88813b019748 ((wq_completion)events){+.+.}, at: process_one_work+0x1d7/0x5e0 | #1: ffffc900000abe50 ((work_completion)(&map->work)){+.+.}, at: process_one_work+0x1d7/0x5e0 | #2: ffff8881381f6df8 (&stab->lock){+...}, at: sock_map_free+0x26/0x180 | CPU: 0 PID: 62 Comm: kworker/0:1 Not tainted 5.5.0-04008-g7b083332376e #454 | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 | Workqueue: events bpf_map_free_deferred | Call Trace: | dump_stack+0x71/0xa0 | ___might_sleep.cold+0xa6/0xb6 | lock_sock_nested+0x28/0x90 | sock_map_free+0x5f/0x180 | bpf_map_free_deferred+0x58/0x80 | process_one_work+0x260/0x5e0 | worker_thread+0x4d/0x3e0 | kthread+0x108/0x140 | ? process_one_work+0x5e0/0x5e0 | ? kthread_park+0x90/0x90 | ret_from_fork+0x3a/0x50 The reason we have stab->lock and bucket->locks in sockmap code is to handle checking EEXIST in update/delete cases. We need to be careful during an update operation that we check for EEXIST and we need to ensure that the psock object is not in some partial state of removal/insertion while we do this. So both map_update_common and sock_map_delete need to guard from being run together potentially deleting an entry we are checking, etc. But by the time we get to the tear-down code in sock_{ma[|hash}_free we have already disconnected the map and we just did synchronize_rcu() in the line above so no updates/deletes should be in flight. Because of this we can drop the bucket locks from the map free'ing code, noting no update/deletes can be in-flight. Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface") Reported-by: Jakub Sitnicki Suggested-by: Jakub Sitnicki Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/158385850787.30597.8346421465837046618.stgit@john-Precision-5820-Tower + Changed Files: net/core/sock_map.c | 12 ++++++++----; 1 file changed, 8 insertions(+), 4 deletions(-) + Parent Hashes: f7861a55b1ce35d0cacfd1f0435f46533dbc9b67 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit removes unnecessary bucket locks from sockmap free operations to fix a bug causing invalid context warnings.", + "keywords": "bucket,lock,sockmap", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "Netfilter related type programs. It impacts programs interacting with the Netfilter framework used in packet filtering and NAT.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit removes unnecessary locks from sockmap free functions to fix a context bug in eBPF socket programs.", + "keywords": "sockmap,lock,bug", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +-------------------- +-------------------- +Processing Commit 413/6895 - Commit ID: 13fac1d851e09109096b5862bf37c3da6908fb48 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 13fac1d851e09109096b5862bf37c3da6908fb48 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1583932052 + Commit Message: + bpf: Fix trampoline generation for fmod_ret programs fmod_ret progs are emitted as: start = __bpf_prog_enter(); call fmod_ret *(u64 *)(rbp - 8) = rax __bpf_prog_exit(, start); test eax, eax jne do_fexit That 'test eax, eax' is working by accident. The compiler is free to use rax inside __bpf_prog_exit() or inside functions that __bpf_prog_exit() is calling. Which caused "test_progs -t modify_return" to sporadically fail depending on compiler version and kconfig. Fix it by using 'cmp [rbp - 8], 0' instead of 'test eax, eax'. Fixes: ae24082331d9 ("bpf: Introduce BPF_MODIFY_RETURN") Reported-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Acked-by: KP Singh Link: https://lore.kernel.org/bpf/20200311003906.3643037-1-ast@kernel.org + Changed Files: arch/x86/net/bpf_jit_comp.c | 31 +++++--------------------------; 1 file changed, 5 insertions(+), 26 deletions(-) + Parent Hashes: babf3164095b0670435910340c2a1eec37757b57 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes trampoline generation for fmod_ret programs by changing a faulty instruction to prevent sporadic test failures.", + "keywords": "trampoline,fmod_ret,fix", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes trampoline generation for fmod_ret programs by changing a faulty instruction to prevent sporadic test failures.", + "keywords": "trampoline,fmod_ret,fix", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 414/6895 - Commit ID: babf3164095b0670435910340c2a1eec37757b57 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: babf3164095b0670435910340c2a1eec37757b57 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1583931768 + Commit Message: + bpf: Add bpf_link_new_file that doesn't install FD Add bpf_link_new_file() API for cases when we need to ensure anon_inode is successfully created before we proceed with expensive BPF program attachment procedure, which will require equally (if not more so) expensive and potentially failing compensation detachment procedure just because anon_inode creation failed. This API allows to simplify code by ensuring first that anon_inode is created and after BPF program is attached proceed with fd_install() that can't fail. After anon_inode file is created, link can't be just kfree()'d anymore, because its destruction will be performed by deferred file_operations->release call. For this, bpf_link API required specifying two separate operations: release() and dealloc(), former performing detachment only, while the latter frees memory used by bpf_link itself. dealloc() needs to be specified, because struct bpf_link is frequently embedded into link type-specific container struct (e.g., struct bpf_raw_tp_link), so bpf_link itself doesn't know how to properly free the memory. In case when anon_inode file was successfully created, but subsequent BPF attachment failed, bpf_link needs to be marked as "defunct", so that file's release() callback will perform only memory deallocation, but no detachment. Convert raw tracepoint and tracing attachment to new API and eliminate detachment from error handling path. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200309231051.1270337-1-andriin@fb.com + Changed Files: include/linux/bpf.h | 3 ++; kernel/bpf/syscall.c | 122 +++++++++++++++++++++++++++++++++++++--------------; 2 files changed, 91 insertions(+), 34 deletions(-) + Parent Hashes: aad32f4c76a22fa0417db083a8cbf9222d4f3d9a +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit introduces the bpf_link_new_file API to improve BPF program attachment handling and error management.", + "keywords": "bpf link api", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The syscall interface. It changes the system calls through which user-space programs interact with eBPF.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events." + ] +} +Rethinking... +new content: +{ + "summary": "This commit introduces the bpf_link_new_file API to improve BPF program attachment handling and error management.", + "keywords": "bpf link api", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The syscall interface. It changes the system calls through which user-space programs interact with eBPF.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events." + ] +} +-------------------- +-------------------- +Processing Commit 415/6895 - Commit ID: f7861a55b1ce35d0cacfd1f0435f46533dbc9b67 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: f7861a55b1ce35d0cacfd1f0435f46533dbc9b67 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1583859647 + Commit Message: + Merge branch 'fix-BTF-enum' Yoshiki Komachi says: ==================== btf_enum_check_member() checked if the size of "enum" as a struct member exceeded struct_size or not. Then, the function compared it with the size of "int". Although the size of "enum" is 4-byte by default (i.e., equivalent to "int"), the packing feature enables us to reduce it, as illustrated by the following example: struct A { char m; enum { E0, E1 } __attribute__((packed)) n; }; With such a setup above, the bpf loader gave an error attempting to load it: ------------------------------------------------------------------ ... [3] ENUM (anon) size=1 vlen=2 E0 val=0 E1 val=1 [4] STRUCT A size=2 vlen=2 m type_id=2 bits_offset=0 n type_id=3 bits_offset=8 [4] STRUCT A size=2 vlen=2 n type_id=3 bits_offset=8 Member exceeds struct_size libbpf: Error loading .BTF into kernel: -22. ------------------------------------------------------------------ The related issue was previously fixed by the commit 9eea98497951 ("bpf: fix BTF verification of enums"). On the other hand, this series fixes this issue as well, and adds a selftest program for it. Changes in v2: - change an example in commit message based on Andrii's review - add a selftest program for packed "enum" type members in struct/union ==================== Acked-by: Andrii Nakryiko Acked-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov + Changed Files: nan + Parent Hashes: 1d8006abaab4cb90f81add86e8d1bf9411add05a 6ffe559a77d1c963a3567f7a39a5419bdcdc4f1c +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges a branch fixing BTF enum size checking and adds a selftest program for packed enum types.", + "keywords": "BTF,enum,selftest", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges a branch addressing a BTF issue with enum size checking and includes a selftest for packed enums.", + "keywords": "BTF,enum,selftest", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 416/6895 - Commit ID: 6ffe559a77d1c963a3567f7a39a5419bdcdc4f1c +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 6ffe559a77d1c963a3567f7a39a5419bdcdc4f1c + Author Name: Yoshiki Komachi + Author Email: komachi.yoshiki@gmail.com + Commit Date: 1583859641 + Commit Message: + selftests/bpf: Add test for the packed enum member in struct/union Add a simple test to the existing selftest program in order to make sure that a packed enum member in struct unexceeds the struct_size. Signed-off-by: Yoshiki Komachi Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/1583825550-18606-3-git-send-email-komachi.yoshiki@gmail.com + Changed Files: tools/testing/selftests/bpf/test_btf.c | 42 ++++++++++++++++++++++++++++++++++; 1 file changed, 42 insertions(+) + Parent Hashes: da6c7faeb103c493e505e87643272f70be586635 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds a selftest to check handling of packed enum members in eBPF structs.", + "keywords": "selftest,packed,enum", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds a selftest to check handling of packed enum members in eBPF structs.", + "keywords": "selftest,packed,enum", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 417/6895 - Commit ID: da6c7faeb103c493e505e87643272f70be586635 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: da6c7faeb103c493e505e87643272f70be586635 + Author Name: Yoshiki Komachi + Author Email: komachi.yoshiki@gmail.com + Commit Date: 1583859641 + Commit Message: + bpf/btf: Fix BTF verification of enum members in struct/union btf_enum_check_member() was currently sure to recognize the size of "enum" type members in struct/union as the size of "int" even if its size was packed. This patch fixes BTF enum verification to use the correct size of member in BPF programs. Fixes: 179cde8cef7e ("bpf: btf: Check members of struct/union") Signed-off-by: Yoshiki Komachi Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/1583825550-18606-2-git-send-email-komachi.yoshiki@gmail.com + Changed Files: kernel/bpf/btf.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: 1d8006abaab4cb90f81add86e8d1bf9411add05a +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes BTF enum member size verification in struct/union for BPF programs.", + "keywords": "BTF,enum,verification", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes BTF enum member size verification in struct/union for BPF programs.", + "keywords": "BTF,enum,verification", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 418/6895 - Commit ID: d2abfbe4652d2b49d30fe77548cf663e63d2d469 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: d2abfbe4652d2b49d30fe77548cf663e63d2d469 + Author Name: Heiko Carstens + Author Email: heiko.carstens@de.ibm.com + Commit Date: 1583849785 + Commit Message: + s390: enable bpf jit by default when not built as always-on This is the s390 variant of commit 81c22041d9f1 ("bpf, x86, arm64: Enable jit by default when not built as always-on"). Acked-by: Ilya Leoshkevich Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik + Changed Files: arch/s390/Kconfig | 1 +; 1 file changed, 1 insertion(+) + Parent Hashes: d68d5d51dc898895b4e15bea52e5668ca9e76180 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Enable BPF JIT compilation by default on s390 architecture when not built as always-on.", + "keywords": "s390, JIT, default", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Enable BPF JIT compilation by default on s390 machines when not built as always-on.", + "keywords": "s390,JIT,default", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 419/6895 - Commit ID: 1d8006abaab4cb90f81add86e8d1bf9411add05a +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 1d8006abaab4cb90f81add86e8d1bf9411add05a + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1583809134 + Commit Message: + bpf: Fix cgroup ref leak in cgroup_bpf_inherit on out-of-memory There is no compensating cgroup_bpf_put() for each ancestor cgroup in cgroup_bpf_inherit(). If compute_effective_progs returns error, those cgroups won't be freed ever. Fix it by putting them in cleanup code path. Fixes: e10360f815ca ("bpf: cgroup: prevent out-of-order release of cgroup bpf") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Roman Gushchin Link: https://lore.kernel.org/bpf/20200309224017.1063297-1-andriin@fb.com + Changed Files: kernel/bpf/cgroup.c | 3 +++; 1 file changed, 3 insertions(+) + Parent Hashes: 62039c30c19dcab96621e074aeeb90da7100def7 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes a reference leak in cgroup_bpf_inherit by adding necessary cleanup code on error paths.", + "keywords": "cgroup, ref leak, cleanup", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups)." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes a reference leak in cgroup_bpf_inherit by adding necessary cleanup code on error paths.", + "keywords": "cgroup, ref leak, cleanup", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups)." + ] +} +-------------------- +-------------------- +Processing Commit 420/6895 - Commit ID: 62039c30c19dcab96621e074aeeb90da7100def7 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 62039c30c19dcab96621e074aeeb90da7100def7 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1583809008 + Commit Message: + bpf: Initialize storage pointers to NULL to prevent freeing garbage pointer Local storage array isn't initialized, so if cgroup storage allocation fails for BPF_CGROUP_STORAGE_SHARED, error handling code will attempt to free uninitialized pointer for BPF_CGROUP_STORAGE_PERCPU storage type. Avoid this by always initializing storage pointers to NULLs. Fixes: 8bad74f9840f ("bpf: extend cgroup bpf core to allow multiple cgroup storage types") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200309222756.1018737-1-andriin@fb.com + Changed Files: kernel/bpf/cgroup.c | 4 ++--; 1 file changed, 2 insertions(+), 2 deletions(-) + Parent Hashes: 93e5fbb18cec70b3b5c614f67b65388829113bdd +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit initializes storage pointers to prevent freeing uninitialized pointers in cgroup BPF storage.", + "keywords": "storage pointers,NULL,freeing", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups)." + ] +} +Rethinking... +new content: +{ + "summary": "The commit initializes storage pointers to prevent freeing uninitialized pointers in cgroup BPF storage.", + "keywords": "storage,NULL,freeing", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups)." + ] +} +-------------------- +-------------------- +Processing Commit 421/6895 - Commit ID: d3f85437ad6a55113882d730beaa75759452da8f +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: d3f85437ad6a55113882d730beaa75759452da8f + Author Name: Kan Liang + Author Email: kan.liang@linux.intel.com + Commit Date: 1583801004 + Commit Message: + perf evsel: Support PERF_SAMPLE_BRANCH_HW_INDEX A new branch sample type PERF_SAMPLE_BRANCH_HW_INDEX has been introduced in latest kernel. Enable HW_INDEX by default in LBR call stack mode. If kernel doesn't support the sample type, switching it off. Add HW_INDEX in attr_fprintf as well. User can check whether the branch sample type is set via debug information or header. Committer testing: First collect some samples with LBR callchains, system wide, for a few seconds: # perf record --call-graph lbr -a sleep 5 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.625 MB perf.data (224 samples) ] # Now lets use 'perf evlist -v' to look at the branch_sample_type: # perf evlist -v cycles: size: 120, { sample_period, sample_freq }: 4000, sample_type: IP|TID|TIME|CALLCHAIN|CPU|PERIOD|BRANCH_STACK, read_format: ID, disabled: 1, inherit: 1, mmap: 1, comm: 1, freq: 1, task: 1, precise_ip: 3, sample_id_all: 1, exclude_guest: 1, mmap2: 1, comm_exec: 1, ksymbol: 1, bpf_event: 1, branch_sample_type: USER|CALL_STACK|NO_FLAGS|NO_CYCLES|HW_INDEX # So the machine has the kernel feature, and it was correctly added to perf_event_attr.branch_sample_type, for the default 'cycles' event. If we do it in another machine, where the kernel lacks the HW_INDEX feature, we get: # perf record --call-graph lbr -a sleep 2s [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 1.690 MB perf.data (499 samples) ] # perf evlist -v cycles: size: 120, { sample_period, sample_freq }: 4000, sample_type: IP|TID|TIME|CALLCHAIN|CPU|PERIOD|BRANCH_STACK, read_format: ID, disabled: 1, inherit: 1, mmap: 1, comm: 1, freq: 1, task: 1, precise_ip: 3, sample_id_all: 1, exclude_guest: 1, mmap2: 1, comm_exec: 1, ksymbol: 1, bpf_event: 1, branch_sample_type: USER|CALL_STACK|NO_FLAGS|NO_CYCLES # No HW_INDEX in attr.branch_sample_type. Signed-off-by: Kan Liang Tested-by: Arnaldo Carvalho de Melo Cc: Adrian Hunter Cc: Alexey Budankov Cc: Andi Kleen Cc: Jiri Olsa Cc: Mathieu Poirier Cc: Michael Ellerman Cc: Namhyung Kim Cc: Pavel Gerasimov Cc: Peter Zijlstra Cc: Ravi Bangoria Cc: Stephane Eranian Cc: Vitaly Slobodskoy Link: http://lore.kernel.org/lkml/20200228163011.19358-3-kan.liang@linux.intel.com Signed-off-by: Arnaldo Carvalho de Melo + Changed Files: tools/perf/util/evsel.c | 15 ++++++++++++---; tools/perf/util/evsel.h | 1 +; tools/perf/util/perf_event_attr_fprintf.c | 1 +; 3 files changed, 14 insertions(+), 3 deletions(-) + Parent Hashes: 42bbabed09ce6208026648a71a45b4394c74585a +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds support for the new branch sample type PERF_SAMPLE_BRANCH_HW_INDEX in perf tools.", + "keywords": "perf, HW_INDEX, evsel", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds support for PERF_SAMPLE_BRANCH_HW_INDEX in perf tools to handle branch samples with hardware indexes.", + "keywords": "perf, HW_INDEX, branch", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +-------------------- +-------------------- +Processing Commit 422/6895 - Commit ID: aad32f4c76a22fa0417db083a8cbf9222d4f3d9a +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: aad32f4c76a22fa0417db083a8cbf9222d4f3d9a + Author Name: Song Liu + Author Email: songliubraving@fb.com + Commit Date: 1583795061 + Commit Message: + bpftool: Fix typo in bash-completion _bpftool_get_map_names => _bpftool_get_prog_names for prog-attach|detach. Fixes: 99f9863a0c45 ("bpftool: Match maps by name") Signed-off-by: Song Liu Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200309173218.2739965-5-songliubraving@fb.com + Changed Files: tools/bpf/bpftool/bash-completion/bpftool | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: 397692eab35cbbd83681880c6a2dbcdb9fd84386 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fix typo in bpftool bash-completion script for program attach/detach functionality.", + "keywords": "bpftool,typo,completion", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Fix typo in bpftool bash-completion script for handling program attach and detach commands.", + "keywords": "bpftool,typo,bash-completion", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 423/6895 - Commit ID: 397692eab35cbbd83681880c6a2dbcdb9fd84386 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 397692eab35cbbd83681880c6a2dbcdb9fd84386 + Author Name: Song Liu + Author Email: songliubraving@fb.com + Commit Date: 1583795059 + Commit Message: + bpftool: Bash completion for "bpftool prog profile" Add bash completion for "bpftool prog profile" command. Signed-off-by: Song Liu Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200309173218.2739965-4-songliubraving@fb.com + Changed Files: tools/bpf/bpftool/bash-completion/bpftool | 45 ++++++++++++++++++++++++++++++-; 1 file changed, 44 insertions(+), 1 deletion(-) + Parent Hashes: 319c7c1f6b78a04e72d32336787912cc1b284f25 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds bash completion support for the \"bpftool prog profile\" command.", + "keywords": "bash,completion,bpftool", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds bash completion support for the \"bpftool prog profile\" command.", + "keywords": "bash,completion,bpftool", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 424/6895 - Commit ID: 319c7c1f6b78a04e72d32336787912cc1b284f25 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 319c7c1f6b78a04e72d32336787912cc1b284f25 + Author Name: Song Liu + Author Email: songliubraving@fb.com + Commit Date: 1583795047 + Commit Message: + bpftool: Documentation for bpftool prog profile Add documentation for the new bpftool prog profile command. Signed-off-by: Song Liu Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200309173218.2739965-3-songliubraving@fb.com + Changed Files: tools/bpf/bpftool/Documentation/bpftool-prog.rst | 19 +++++++++++++++++++; 1 file changed, 19 insertions(+) + Parent Hashes: 47c09d6a9f6794caface4ad50930460b82d7c670 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds documentation for the new `bpftool prog profile` command.", + "keywords": "bpftool,documentation,profile", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds documentation for the new `bpftool prog profile` command.", + "keywords": "bpftool,documentation,profile", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 425/6895 - Commit ID: 47c09d6a9f6794caface4ad50930460b82d7c670 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 47c09d6a9f6794caface4ad50930460b82d7c670 + Author Name: Song Liu + Author Email: songliubraving@fb.com + Commit Date: 1583795047 + Commit Message: + bpftool: Introduce "prog profile" command With fentry/fexit programs, it is possible to profile BPF program with hardware counters. Introduce bpftool "prog profile", which measures key metrics of a BPF program. bpftool prog profile command creates per-cpu perf events. Then it attaches fentry/fexit programs to the target BPF program. The fentry program saves perf event value to a map. The fexit program reads the perf event again, and calculates the difference, which is the instructions/cycles used by the target program. Example input and output: ./bpftool prog profile id 337 duration 3 cycles instructions llc_misses 4228 run_cnt 3403698 cycles (84.08%) 3525294 instructions # 1.04 insn per cycle (84.05%) 13 llc_misses # 3.69 LLC misses per million isns (83.50%) This command measures cycles and instructions for BPF program with id 337 for 3 seconds. The program has triggered 4228 times. The rest of the output is similar to perf-stat. In this example, the counters were only counting ~84% of the time because of time multiplexing of perf counters. Note that, this approach measures cycles and instructions in very small increments. So the fentry/fexit programs introduce noticeable errors to the measurement results. The fentry/fexit programs are generated with BPF skeletons. Therefore, we build bpftool twice. The first time _bpftool is built without skeletons. Then, _bpftool is used to generate the skeletons. The second time, bpftool is built with skeletons. Signed-off-by: Song Liu Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200309173218.2739965-2-songliubraving@fb.com + Changed Files: tools/bpf/bpftool/Makefile | 18 ++; tools/bpf/bpftool/prog.c | 424 +++++++++++++++++++++++++++++-; tools/bpf/bpftool/skeleton/profiler.bpf.c | 119 +++++++++; tools/bpf/bpftool/skeleton/profiler.h | 47 ++++; tools/scripts/Makefile.include | 1 +; 5 files changed, 608 insertions(+), 1 deletion(-) + Parent Hashes: 7b4b73bc8a609fa9655022ed24a7a714bc8c2155 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit introduces a profiling command in bpftool for BPF programs to measure key metrics using hardware counters.", + "keywords": "bpftool,profile,program", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Profile related type programs. It affects programs used for profiling system or application performance." + ] +} +Rethinking... +new content: +{ + "summary": "The commit introduces a profiling command in bpftool for BPF programs to measure key metrics using hardware counters.", + "keywords": "bpftool,profile,program", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Profile related type programs. It affects programs used for profiling system or application performance." + ] +} +-------------------- +-------------------- +Processing Commit 426/6895 - Commit ID: 7b4b73bc8a609fa9655022ed24a7a714bc8c2155 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 7b4b73bc8a609fa9655022ed24a7a714bc8c2155 + Author Name: Lorenz Bauer + Author Email: lmb@cloudflare.com + Commit Date: 1583789699 + Commit Message: + bpf, doc: Update maintainers for L7 BPF Add Jakub and myself as maintainers for sockmap related code. Signed-off-by: Lorenz Bauer Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Sitnicki Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200309111243.6982-13-lmb@cloudflare.com + Changed Files: MAINTAINERS | 2 ++; 1 file changed, 2 insertions(+) + Parent Hashes: 1f441b35ea5453e1dcc00fac03dbd5d7e6cd4f97 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit updates MAINTAINERS to include new maintainers for sockmap related code.", + "keywords": "maintainers,sockmap,L7", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "I'm not sure about the implementation component of the commit. The component affected by It is unclear.", + "major_related_logic_component": "I'm not sure about the logic component of the commit. The affected logic component is unclear.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit updates the MAINTAINERS file to add new maintainers for sockmap related code.", + "keywords": "maintainers,sockmap,doc", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +-------------------- +-------------------- +Processing Commit 427/6895 - Commit ID: 1f441b35ea5453e1dcc00fac03dbd5d7e6cd4f97 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 1f441b35ea5453e1dcc00fac03dbd5d7e6cd4f97 + Author Name: Lorenz Bauer + Author Email: lmb@cloudflare.com + Commit Date: 1583789699 + Commit Message: + selftests: bpf: Enable UDP sockmap reuseport tests Remove the guard that disables UDP tests now that sockmap has support for them. Signed-off-by: Lorenz Bauer Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Sitnicki Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200309111243.6982-12-lmb@cloudflare.com + Changed Files: tools/testing/selftests/bpf/prog_tests/select_reuseport.c | 6 ------; 1 file changed, 6 deletions(-) + Parent Hashes: 84be2113e6a7f781bd37c0fd0159899150fdcdfb +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Enable UDP sockmap reuseport tests by removing the guard disabling them.", + "keywords": "UDP sockmap tests", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Enable UDP sockmap reuseport tests by removing the guard disabling them.", + "keywords": "UDP sockmap tests", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 428/6895 - Commit ID: 84be2113e6a7f781bd37c0fd0159899150fdcdfb +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 84be2113e6a7f781bd37c0fd0159899150fdcdfb + Author Name: Lorenz Bauer + Author Email: lmb@cloudflare.com + Commit Date: 1583789699 + Commit Message: + selftests: bpf: Add tests for UDP sockets in sockmap Expand the TCP sockmap test suite to also check UDP sockets. Signed-off-by: Jakub Sitnicki Signed-off-by: Lorenz Bauer Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200309111243.6982-11-lmb@cloudflare.com + Changed Files: .../selftests/bpf/prog_tests/sockmap_listen.c | 157 +++++++++++++++++----; 1 file changed, 127 insertions(+), 30 deletions(-) + Parent Hashes: b05fbb9f03f15134735f9d2dcc7d067092ec9dd2 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds UDP socket tests to the existing TCP sockmap test suite.", + "keywords": "UDP, tests, sockmap", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds UDP socket tests to the existing TCP sockmap test suite.", + "keywords": "UDP, tests, sockmap", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 429/6895 - Commit ID: b05fbb9f03f15134735f9d2dcc7d067092ec9dd2 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: b05fbb9f03f15134735f9d2dcc7d067092ec9dd2 + Author Name: Lorenz Bauer + Author Email: lmb@cloudflare.com + Commit Date: 1583789699 + Commit Message: + selftests: bpf: Don't listen() on UDP sockets Most tests for TCP sockmap can be adapted to UDP sockmap if the listen call is skipped. Rename listen_loopback, etc. to socket_loopback and skip listen() for SOCK_DGRAM. Signed-off-by: Lorenz Bauer Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Sitnicki Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200309111243.6982-10-lmb@cloudflare.com + Changed Files: .../selftests/bpf/prog_tests/sockmap_listen.c | 47 ++++++++++++----------; 1 file changed, 25 insertions(+), 22 deletions(-) + Parent Hashes: 7b98cd42b0492237887b62f5ba05931169bcfcf6 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit updates self-tests for BPF by adapting TCP sockmap tests for UDP sockmap, skipping the listen call.", + "keywords": "selftests,sockmap,UDP", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "The commit modifies self-tests for BPF to adapt TCP sockmap tests for UDP by skipping the listen call.", + "keywords": "selftests,sockmap,UDP", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 430/6895 - Commit ID: 7b98cd42b0492237887b62f5ba05931169bcfcf6 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 7b98cd42b0492237887b62f5ba05931169bcfcf6 + Author Name: Lorenz Bauer + Author Email: lmb@cloudflare.com + Commit Date: 1583789698 + Commit Message: + bpf: sockmap: Add UDP support Allow adding hashed UDP sockets to sockmaps. Signed-off-by: Lorenz Bauer Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200309111243.6982-9-lmb@cloudflare.com + Changed Files: net/core/sock_map.c | 37 +++++++++++++++++++++++++++++++++----; 1 file changed, 33 insertions(+), 4 deletions(-) + Parent Hashes: edc6741cc66059532ba621928e3f1b02a53a2f39 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds support for UDP sockets in sockmaps in the BPF subsystem.", + "keywords": "sockmap,UDP,support", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds UDP socket support to sockmaps in the BPF subsystem.", + "keywords": "UDP,sockmap,support", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 431/6895 - Commit ID: edc6741cc66059532ba621928e3f1b02a53a2f39 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: edc6741cc66059532ba621928e3f1b02a53a2f39 + Author Name: Lorenz Bauer + Author Email: lmb@cloudflare.com + Commit Date: 1583789698 + Commit Message: + bpf: Add sockmap hooks for UDP sockets Add basic psock hooks for UDP sockets. This allows adding and removing sockets, as well as automatic removal on unhash and close. Signed-off-by: Lorenz Bauer Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200309111243.6982-8-lmb@cloudflare.com + Changed Files: MAINTAINERS | 1 +; include/net/udp.h | 5 +++++; net/ipv4/Makefile | 1 +; net/ipv4/udp_bpf.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++++; 4 files changed, 60 insertions(+) + Parent Hashes: cb21802b39632ba1fa9b31ea134d2079a47600ef +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds basic psock hooks for managing UDP sockets in the Linux BPF subsystem.", + "keywords": "sockmap,UDP,psock", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "This commit introduces psock hooks for UDP sockets in the Linux BPF subsystem to manage socket addition and removal.", + "keywords": "sockmap,UDP,psock", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 432/6895 - Commit ID: cb21802b39632ba1fa9b31ea134d2079a47600ef +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: cb21802b39632ba1fa9b31ea134d2079a47600ef + Author Name: Lorenz Bauer + Author Email: lmb@cloudflare.com + Commit Date: 1583789698 + Commit Message: + bpf: sockmap: Simplify sock_map_init_proto We can take advantage of the fact that both callers of sock_map_init_proto are holding a RCU read lock, and have verified that psock is valid. Signed-off-by: Lorenz Bauer Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Sitnicki Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200309111243.6982-7-lmb@cloudflare.com + Changed Files: net/core/sock_map.c | 19 ++++---------------; 1 file changed, 4 insertions(+), 15 deletions(-) + Parent Hashes: f747632b608f90217a4e9ebb1deba8a37612aa32 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit simplifies the sock_map initialization by leveraging RCU read lock presence and psock validity checks in the callers.", + "keywords": "sock_map, RCU, simplify", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "The commit simplifies sock_map initialization by utilizing existing RCU locks and psock checks in the calling functions.", + "keywords": "sockmap, simplify, RCU", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 433/6895 - Commit ID: f747632b608f90217a4e9ebb1deba8a37612aa32 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: f747632b608f90217a4e9ebb1deba8a37612aa32 + Author Name: Lorenz Bauer + Author Email: lmb@cloudflare.com + Commit Date: 1583789698 + Commit Message: + bpf: sockmap: Move generic sockmap hooks from BPF TCP The init, close and unhash handlers from TCP sockmap are generic, and can be reused by UDP sockmap. Move the helpers into the sockmap code base and expose them. This requires tcp_bpf_get_proto and tcp_bpf_clone to be conditional on BPF_STREAM_PARSER. The moved functions are unmodified, except that sk_psock_unlink is renamed to sock_map_unlink to better match its behaviour. Signed-off-by: Lorenz Bauer Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Sitnicki Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200309111243.6982-6-lmb@cloudflare.com + Changed Files: include/linux/bpf.h | 4 +-; include/linux/skmsg.h | 28 -------------; include/net/tcp.h | 15 ++++---; net/core/sock_map.c | 106 +++++++++++++++++++++++++++++++++++++++++++++++---; net/ipv4/tcp_bpf.c | 84 +++------------------------------------; 5 files changed, 118 insertions(+), 119 deletions(-) + Parent Hashes: 5da0040442312a2b696748f8240243ce543a4970 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit moves generic sockmap hooks from BPF TCP to improve code reuse with UDP sockmap.", + "keywords": "sockmap, TCP, UDP", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +Rethinking... +new content: +{ + "summary": "This commit refactors sockmap hooks to be more generic for both TCP and UDP protocols.", + "keywords": "sockmap,TCP,UDP", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +-------------------- +-------------------- +Processing Commit 434/6895 - Commit ID: 5da0040442312a2b696748f8240243ce543a4970 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 5da0040442312a2b696748f8240243ce543a4970 + Author Name: Lorenz Bauer + Author Email: lmb@cloudflare.com + Commit Date: 1583789698 + Commit Message: + bpf: tcp: Guard declarations with CONFIG_NET_SOCK_MSG tcp_bpf.c is only included in the build if CONFIG_NET_SOCK_MSG is selected. The declaration should therefore be guarded as such. Signed-off-by: Lorenz Bauer Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Sitnicki Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200309111243.6982-5-lmb@cloudflare.com + Changed Files: include/net/tcp.h | 4 ++--; 1 file changed, 2 insertions(+), 2 deletions(-) + Parent Hashes: d19da360ee0f3e6c1375391db1a724b66fd43312 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit guards tcp_bpf.c declarations with CONFIG_NET_SOCK_MSG to ensure correct inclusion in the build.", + "keywords": "CONFIG_NET_SOCK_MSG, tcp_bpf.c, declaration", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds CONFIG_NET_SOCK_MSG guards to tcp_bpf.c declarations for correct building conditions.", + "keywords": "CONFIG_NET_SOCK_MSG, tcp_bpf.c, build", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 435/6895 - Commit ID: d19da360ee0f3e6c1375391db1a724b66fd43312 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: d19da360ee0f3e6c1375391db1a724b66fd43312 + Author Name: Lorenz Bauer + Author Email: lmb@cloudflare.com + Commit Date: 1583789698 + Commit Message: + bpf: tcp: Move assertions into tcp_bpf_get_proto We need to ensure that sk->sk_prot uses certain callbacks, so that code that directly calls e.g. tcp_sendmsg in certain corner cases works. To avoid spurious asserts, we must to do this only if sk_psock_update_proto has not yet been called. The same invariants apply for tcp_bpf_check_v6_needs_rebuild, so move the call as well. Doing so allows us to merge tcp_bpf_init and tcp_bpf_reinit. Signed-off-by: Lorenz Bauer Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Sitnicki Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200309111243.6982-4-lmb@cloudflare.com + Changed Files: include/net/tcp.h | 1 -; net/core/sock_map.c | 25 +++++++++----------------; net/ipv4/tcp_bpf.c | 42 ++++++++++++++++++++++--------------------; 3 files changed, 31 insertions(+), 37 deletions(-) + Parent Hashes: 1a2e20132db7bb76dd4f97b8364bd167227dd15f +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit moves assertions into tcp_bpf_get_proto to ensure compatibility with certain callbacks and consolidates tcp_bpf_init and tcp_bpf_reinit.", + "keywords": "tcp,assertions,merge", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "The commit refactors the placement of assertions within tcp_bpf_get_proto for better callback compatibility and merges related functions for tidiness.", + "keywords": "assertions,tcp,merge", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 436/6895 - Commit ID: 1a2e20132db7bb76dd4f97b8364bd167227dd15f +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 1a2e20132db7bb76dd4f97b8364bd167227dd15f + Author Name: Lorenz Bauer + Author Email: lmb@cloudflare.com + Commit Date: 1583789698 + Commit Message: + skmsg: Update saved hooks only once Only update psock->saved_* if psock->sk_proto has not been initialized yet. This allows us to get rid of tcp_bpf_reinit_sk_prot. Signed-off-by: Lorenz Bauer Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Sitnicki Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200309111243.6982-3-lmb@cloudflare.com + Changed Files: include/linux/skmsg.h | 20 ++++++++++++++++----; net/ipv4/tcp_bpf.c | 16 +---------------; 2 files changed, 17 insertions(+), 19 deletions(-) + Parent Hashes: 7b70973d7edb2f005511102d5a2e0116464a46a1 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit optimizes initialization logic for skmsg by only updating saved hooks if the socket protocol is not already initialized.", + "keywords": "skmsg,saved_hooks,psock", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "The commit optimizes skmsg initialization logic by only updating saved hooks if the socket protocol is not already set.", + "keywords": "skmsg,saved_hooks,socket", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 437/6895 - Commit ID: 7b70973d7edb2f005511102d5a2e0116464a46a1 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 7b70973d7edb2f005511102d5a2e0116464a46a1 + Author Name: Lorenz Bauer + Author Email: lmb@cloudflare.com + Commit Date: 1583789698 + Commit Message: + bpf: sockmap: Only check ULP for TCP sockets The sock map code checks that a socket does not have an active upper layer protocol before inserting it into the map. This requires casting via inet_csk, which isn't valid for UDP sockets. Guard checks for ULP by checking inet_sk(sk)->is_icsk first. Signed-off-by: Lorenz Bauer Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Sitnicki Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200309111243.6982-2-lmb@cloudflare.com + Changed Files: include/linux/skmsg.h | 8 +++++++-; include/net/inet_connection_sock.h | 6 ++++++; net/core/sock_map.c | 6 ++----; net/ipv4/tcp_ulp.c | 7 -------; 4 files changed, 15 insertions(+), 12 deletions(-) + Parent Hashes: 3e7c67d90e3ed2f34fce42699f11b150dd1d3999 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adjusts sockmap to correctly handle ULP checks for TCP sockets, avoiding invalid casts for UDP sockets.", + "keywords": "sockmap,TCP,ULP", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +Rethinking... +new content: +{ + "summary": "The commit corrects ULP checks for TCP sockets in sockmap to prevent issues with UDP sockets.", + "keywords": "sockmap,ULP,TCP", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +-------------------- +-------------------- +Processing Commit 438/6895 - Commit ID: 93e5fbb18cec70b3b5c614f67b65388829113bdd +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 93e5fbb18cec70b3b5c614f67b65388829113bdd + Author Name: Luke Nelson + Author Email: lukenels@cs.washington.edu + Commit Date: 1583500659 + Commit Message: + selftests: bpf: Add test for JMP32 JSET BPF_X with upper bits set The existing tests attempt to check that JMP32 JSET ignores the upper bits in the operand registers. However, the tests missed one such bug in the x32 JIT that is only uncovered when a previous instruction pollutes the upper 32 bits of the registers. This patch adds a new test case that catches the bug by first executing a 64-bit JSET to pollute the upper 32-bits of the temporary registers, followed by a 32-bit JSET which should ignore the upper 32 bits. Co-developed-by: Xi Wang Signed-off-by: Xi Wang Signed-off-by: Luke Nelson Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200305234416.31597-2-luke.r.nels@gmail.com + Changed Files: tools/testing/selftests/bpf/verifier/jmp32.c | 15 +++++++++++++++; 1 file changed, 15 insertions(+) + Parent Hashes: 80f1f85036355e5581ec0b99913410345ad3491b +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Adds a self-test to catch an issue in JMP32 JSET handling with upper bits set in BPF's x32 JIT.", + "keywords": "selftests,JMP32,JSET", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Adds a self-test to catch an issue in JMP32 JSET handling with upper bits set in BPF's x32 JIT.", + "keywords": "selftests,JMP32,JSET", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 439/6895 - Commit ID: 80f1f85036355e5581ec0b99913410345ad3491b +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 80f1f85036355e5581ec0b99913410345ad3491b + Author Name: Luke Nelson + Author Email: lukenels@cs.washington.edu + Commit Date: 1583500659 + Commit Message: + bpf, x32: Fix bug with JMP32 JSET BPF_X checking upper bits The current x32 BPF JIT is incorrect for JMP32 JSET BPF_X when the upper 32 bits of operand registers are non-zero in certain situations. The problem is in the following code: case BPF_JMP | BPF_JSET | BPF_X: case BPF_JMP32 | BPF_JSET | BPF_X: ... /* and dreg_lo,sreg_lo */ EMIT2(0x23, add_2reg(0xC0, sreg_lo, dreg_lo)); /* and dreg_hi,sreg_hi */ EMIT2(0x23, add_2reg(0xC0, sreg_hi, dreg_hi)); /* or dreg_lo,dreg_hi */ EMIT2(0x09, add_2reg(0xC0, dreg_lo, dreg_hi)); This code checks the upper bits of the operand registers regardless if the BPF instruction is BPF_JMP32 or BPF_JMP64. Registers dreg_hi and dreg_lo are not loaded from the stack for BPF_JMP32, however, they can still be polluted with values from previous instructions. The following BPF program demonstrates the bug. The jset64 instruction loads the temporary registers and performs the jump, since ((u64)r7 & (u64)r8) is non-zero. The jset32 should _not_ be taken, as the lower 32 bits are all zero, however, the current JIT will take the branch due the pollution of temporary registers from the earlier jset64. mov64 r0, 0 ld64 r7, 0x8000000000000000 ld64 r8, 0x8000000000000000 jset64 r7, r8, 1 exit jset32 r7, r8, 1 mov64 r0, 2 exit The expected return value of this program is 2; under the buggy x32 JIT it returns 0. The fix is to skip using the upper 32 bits for jset32 and compare the upper 32 bits for jset64 only. All tests in test_bpf.ko and selftests/bpf/test_verifier continue to pass with this change. We found this bug using our automated verification tool, Serval. Fixes: 69f827eb6e14 ("x32: bpf: implement jitting of JMP32") Co-developed-by: Xi Wang Signed-off-by: Xi Wang Signed-off-by: Luke Nelson Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200305234416.31597-1-luke.r.nels@gmail.com + Changed Files: arch/x86/net/bpf_jit_comp32.c | 10 ++++++----; 1 file changed, 6 insertions(+), 4 deletions(-) + Parent Hashes: 849b4d94582a966ecb533448415462846da1f0fa +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit fixes the bug with JMP32 JSET BPF_X by correctly handling upper bits in x32 BPF JIT.", + "keywords": "bug,JMP32,JIT", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes a bug in the x32 BPF JIT compiler related to upper bits checking in JMP32 JSET BPF_X instructions.", + "keywords": "bug,JMP32,JIT", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 440/6895 - Commit ID: 3e7c67d90e3ed2f34fce42699f11b150dd1d3999 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 3e7c67d90e3ed2f34fce42699f11b150dd1d3999 + Author Name: KP Singh + Author Email: kpsingh@google.com + Commit Date: 1583450098 + Commit Message: + bpf: Fix bpf_prog_test_run_tracing for !CONFIG_NET test_run.o is not built when CONFIG_NET is not set and bpf_prog_test_run_tracing being referenced in bpf_trace.o causes the linker error: ld: kernel/trace/bpf_trace.o:(.rodata+0x38): undefined reference to `bpf_prog_test_run_tracing' Add a __weak function in bpf_trace.c to handle this. Fixes: da00d2f117a0 ("bpf: Add test ops for BPF_PROG_TYPE_TRACING") Signed-off-by: KP Singh Reported-by: Randy Dunlap Acked-by: Randy Dunlap Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200305220127.29109-1-kpsingh@chromium.org + Changed Files: kernel/trace/bpf_trace.c | 7 +++++++; 1 file changed, 7 insertions(+) + Parent Hashes: 69191754ff299a64575003d9e2a79db190d27115 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes a linker error by adding a weak function in bpf_trace.c for non-NET configurations.", + "keywords": "linker,error,function", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes a linker error by adding a weak function in bpf_trace.c for non-NET configurations.", + "keywords": "linker,error,function", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing." + ] +} +-------------------- +-------------------- +Processing Commit 441/6895 - Commit ID: 69191754ff299a64575003d9e2a79db190d27115 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 69191754ff299a64575003d9e2a79db190d27115 + Author Name: KP Singh + Author Email: kpsingh@google.com + Commit Date: 1583447242 + Commit Message: + bpf: Remove unnecessary CAP_MAC_ADMIN check While well intentioned, checking CAP_MAC_ADMIN for attaching BPF_MODIFY_RETURN tracing programs to "security_" functions is not necessary as tracing BPF programs already require CAP_SYS_ADMIN. Fixes: 6ba43b761c41 ("bpf: Attachment verification for BPF_MODIFY_RETURN") Signed-off-by: KP Singh Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200305204955.31123-1-kpsingh@chromium.org + Changed Files: kernel/bpf/verifier.c | 13 +++----------; 1 file changed, 3 insertions(+), 10 deletions(-) + Parent Hashes: dad737c926b5b286b9c91abbda66811a8a6618e9 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit removes an unnecessary CAP_MAC_ADMIN check for BPF_MODIFY_RETURN programs, relying instead on the existing CAP_SYS_ADMIN requirement.", + "keywords": "CAP_MAC_ADMIN,CAP_SYS_ADMIN,BPF_MODIFY_RETURN", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing." + ] +} +Rethinking... +new content: +{ + "summary": "The commit removes an unnecessary CAP_MAC_ADMIN check for BPF_MODIFY_RETURN programs, relying instead on the existing CAP_SYS_ADMIN requirement.", + "keywords": "CAP_MAC_ADMIN,CAP_SYS_ADMIN,BPF_MODIFY_RETURN", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing." + ] +} +-------------------- +-------------------- +Processing Commit 442/6895 - Commit ID: 849b4d94582a966ecb533448415462846da1f0fa +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 849b4d94582a966ecb533448415462846da1f0fa + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1583446549 + Commit Message: + bpf: Do not allow map_freeze in struct_ops map struct_ops map cannot support map_freeze. Otherwise, a struct_ops cannot be unregistered from the subsystem. Fixes: 85d33df357b6 ("bpf: Introduce BPF_MAP_TYPE_STRUCT_OPS") Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200305013454.535397-1-kafai@fb.com + Changed Files: kernel/bpf/syscall.c | 5 +++++; 1 file changed, 5 insertions(+) + Parent Hashes: 8e5290e710f4ffe8e9f8813e2ed0397a94d7b2f1 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit prevents map_freeze in struct_ops maps to allow proper unregistration from subsystems.", + "keywords": "map_freeze, struct_ops, unregistration", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes a bug that prevents the freezing of maps in struct_ops to allow proper unregistration from subsystems.", + "keywords": "map_freeze, struct_ops, subsystem", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems." + ] +} +-------------------- +-------------------- +Processing Commit 443/6895 - Commit ID: 8e5290e710f4ffe8e9f8813e2ed0397a94d7b2f1 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 8e5290e710f4ffe8e9f8813e2ed0397a94d7b2f1 + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1583446548 + Commit Message: + bpf: Return better error value in delete_elem for struct_ops map The current always succeed behavior in bpf_struct_ops_map_delete_elem() is not ideal for userspace tool. It can be improved to return proper error value. If it is in TOBEFREE, it means unregistration has been already done before but it is in progress and waiting for the subsystem to clear the refcnt to zero, so -EINPROGRESS. If it is INIT, it means the struct_ops has not been registered yet, so -ENOENT. Fixes: 85d33df357b6 ("bpf: Introduce BPF_MAP_TYPE_STRUCT_OPS") Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200305013447.535326-1-kafai@fb.com + Changed Files: kernel/bpf/bpf_struct_ops.c | 14 +++++++++++---; 1 file changed, 11 insertions(+), 3 deletions(-) + Parent Hashes: a35a76faad53429b52a8937b69fdeee5b4e5f935 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit improves error handling in bpf_struct_ops_map_delete_elem by returning specific error values for different states.", + "keywords": "error,struct_ops,delete_elem", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit improves error handling in bpf_struct_ops_map_delete_elem by returning specific error values for different states.", + "keywords": "error,struct_ops,delete_elem", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 444/6895 - Commit ID: a35a76faad53429b52a8937b69fdeee5b4e5f935 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: a35a76faad53429b52a8937b69fdeee5b4e5f935 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1583446162 + Commit Message: + Merge branch 'fix_bpf_send_signal' Yonghong Song says: ==================== Commit 8b401f9ed244 ("bpf: implement bpf_send_signal() helper") introduced bpf_send_signal() helper and Commit 8482941f0906 ("bpf: Add bpf_send_signal_thread() helper") added bpf_send_signal_thread() helper. Both helpers try to send a signel to current process or thread. When bpf_prog is called with scheduler rq_lock held, a deadlock could happen since bpf_send_signal() and bpf_send_signal_thread() will call group_send_sig_info() which may ultimately want to acquire rq_lock() again. This happens in 5.2 and 4.16 based kernels in our production environment with perf_sw_event. In a different scenario, the following is also possible in the last kernel: cpu 1: do_task_stat <- holding sighand->siglock ... task_sched_runtime <- trying to grab rq_lock cpu 2: __schedule <- holding rq_lock ... do_send_sig_info <- trying to grab sighand->siglock Commit eac9153f2b58 ("bpf/stackmap: Fix deadlock with rq_lock in bpf_get_stack()") has a similar issue with above rq_lock() deadlock. This patch set addressed the issue in a similar way. Patch #1 provided kernel solution and Patch #2 added a selftest. Changelogs: v2 -> v3: . simplify selftest send_signal_sched_switch(). The previous version has mmap/munmap inherited from Song's reproducer. They are not necessary in this context. v1 -> v2: . previous fix using task_work in nmi() is incorrect. there is no nmi() involvement here. Using task_work in all cases might be a solution. But decided to use a similar fix as in Commit eac9153f2b58. ==================== Signed-off-by: Alexei Starovoitov + Changed Files: nan + Parent Hashes: 52e7c083b417417bb4352ebf3a6409988b6af238 c4ef2f3256e3bc008f98121cad39ee5467db07a6 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges a fix for a deadlock issue caused by bpf_send_signal() and bpf_send_signal_thread() helpers when called with rq_lock held.", + "keywords": "deadlock, bpf_send_signal, rq_lock", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges fixes for a deadlock issue with bpf_send_signal() and bpf_send_signal_thread() helpers affecting rq_lock in kernel scheduling.", + "keywords": "deadlock,bpf_send_signal,rq_lock", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 445/6895 - Commit ID: c4ef2f3256e3bc008f98121cad39ee5467db07a6 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: c4ef2f3256e3bc008f98121cad39ee5467db07a6 + Author Name: Yonghong Song + Author Email: yhs@fb.com + Commit Date: 1583445761 + Commit Message: + selftests/bpf: Add send_signal_sched_switch test Added one test, send_signal_sched_switch, to test bpf_send_signal() helper triggered by sched/sched_switch tracepoint. This test can be used to verify kernel deadlocks fixed by the previous commit. The test itself is heavily borrowed from Commit eac9153f2b58 ("bpf/stackmap: Fix deadlock with rq_lock in bpf_get_stack()"). Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Cc: Song Liu Link: https://lore.kernel.org/bpf/20200304191105.2796601-1-yhs@fb.com + Changed Files: .../bpf/prog_tests/send_signal_sched_switch.c | 60 ++++++++++++++++++++++; .../selftests/bpf/progs/test_send_signal_kern.c | 6 +++; 2 files changed, 66 insertions(+) + Parent Hashes: 1bc7896e9ef44fd77858b3ef0b8a6840be3a4494 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds a selftest for the bpf_send_signal() helper function triggered by sched/sched_switch tracepoint.", + "keywords": "selftests bpf kernel", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing." + ] +} +Rethinking... +new content: +{ + "summary": "This commit introduces a new selftest for the bpf_send_signal() helper using the sched/sched_switch tracepoint.", + "keywords": "selftests bpf tracepoint", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing." + ] +} +-------------------- +-------------------- +Processing Commit 446/6895 - Commit ID: 1bc7896e9ef44fd77858b3ef0b8a6840be3a4494 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 1bc7896e9ef44fd77858b3ef0b8a6840be3a4494 + Author Name: Yonghong Song + Author Email: yhs@fb.com + Commit Date: 1583445742 + Commit Message: + bpf: Fix deadlock with rq_lock in bpf_send_signal() When experimenting with bpf_send_signal() helper in our production environment (5.2 based), we experienced a deadlock in NMI mode: #5 [ffffc9002219f770] queued_spin_lock_slowpath at ffffffff8110be24 #6 [ffffc9002219f770] _raw_spin_lock_irqsave at ffffffff81a43012 #7 [ffffc9002219f780] try_to_wake_up at ffffffff810e7ecd #8 [ffffc9002219f7e0] signal_wake_up_state at ffffffff810c7b55 #9 [ffffc9002219f7f0] __send_signal at ffffffff810c8602 #10 [ffffc9002219f830] do_send_sig_info at ffffffff810ca31a #11 [ffffc9002219f868] bpf_send_signal at ffffffff8119d227 #12 [ffffc9002219f988] bpf_overflow_handler at ffffffff811d4140 #13 [ffffc9002219f9e0] __perf_event_overflow at ffffffff811d68cf #14 [ffffc9002219fa10] perf_swevent_overflow at ffffffff811d6a09 #15 [ffffc9002219fa38] ___perf_sw_event at ffffffff811e0f47 #16 [ffffc9002219fc30] __schedule at ffffffff81a3e04d #17 [ffffc9002219fc90] schedule at ffffffff81a3e219 #18 [ffffc9002219fca0] futex_wait_queue_me at ffffffff8113d1b9 #19 [ffffc9002219fcd8] futex_wait at ffffffff8113e529 #20 [ffffc9002219fdf0] do_futex at ffffffff8113ffbc #21 [ffffc9002219fec0] __x64_sys_futex at ffffffff81140d1c #22 [ffffc9002219ff38] do_syscall_64 at ffffffff81002602 #23 [ffffc9002219ff50] entry_SYSCALL_64_after_hwframe at ffffffff81c00068 The above call stack is actually very similar to an issue reported by Commit eac9153f2b58 ("bpf/stackmap: Fix deadlock with rq_lock in bpf_get_stack()") by Song Liu. The only difference is bpf_send_signal() helper instead of bpf_get_stack() helper. The above deadlock is triggered with a perf_sw_event. Similar to Commit eac9153f2b58, the below almost identical reproducer used tracepoint point sched/sched_switch so the issue can be easily caught. /* stress_test.c */ #include #include #include #include #include #include #include #define THREAD_COUNT 1000 char *filename; void *worker(void *p) { void *ptr; int fd; char *pptr; fd = open(filename, O_RDONLY); if (fd < 0) return NULL; while (1) { struct timespec ts = {0, 1000 + rand() % 2000}; ptr = mmap(NULL, 4096 * 64, PROT_READ, MAP_PRIVATE, fd, 0); usleep(1); if (ptr == MAP_FAILED) { printf("failed to mmap\n"); break; } munmap(ptr, 4096 * 64); usleep(1); pptr = malloc(1); usleep(1); pptr[0] = 1; usleep(1); free(pptr); usleep(1); nanosleep(&ts, NULL); } close(fd); return NULL; } int main(int argc, char *argv[]) { void *ptr; int i; pthread_t threads[THREAD_COUNT]; if (argc < 2) return 0; filename = argv[1]; for (i = 0; i < THREAD_COUNT; i++) { if (pthread_create(threads + i, NULL, worker, NULL)) { fprintf(stderr, "Error creating thread\n"); return 0; } } for (i = 0; i < THREAD_COUNT; i++) pthread_join(threads[i], NULL); return 0; } and the following command: 1. run `stress_test /bin/ls` in one windown 2. hack bcc trace.py with the following change: --- a/tools/trace.py +++ b/tools/trace.py @@ -513,6 +513,7 @@ BPF_PERF_OUTPUT(%s); __data.tgid = __tgid; __data.pid = __pid; bpf_get_current_comm(&__data.comm, sizeof(__data.comm)); + bpf_send_signal(10); %s %s %s.perf_submit(%s, &__data, sizeof(__data)); 3. in a different window run ./trace.py -p $(pidof stress_test) t:sched:sched_switch The deadlock can be reproduced in our production system. Similar to Song's fix, the fix is to delay sending signal if irqs is disabled to avoid deadlocks involving with rq_lock. With this change, my above stress-test in our production system won't cause deadlock any more. I also implemented a scale-down version of reproducer in the selftest (a subsequent commit). With latest bpf-next, it complains for the following potential deadlock. [ 32.832450] -> #1 (&p->pi_lock){-.-.}: [ 32.833100] _raw_spin_lock_irqsave+0x44/0x80 [ 32.833696] task_rq_lock+0x2c/0xa0 [ 32.834182] task_sched_runtime+0x59/0xd0 [ 32.834721] thread_group_cputime+0x250/0x270 [ 32.835304] thread_group_cputime_adjusted+0x2e/0x70 [ 32.835959] do_task_stat+0x8a7/0xb80 [ 32.836461] proc_single_show+0x51/0xb0 ... [ 32.839512] -> #0 (&(&sighand->siglock)->rlock){....}: [ 32.840275] __lock_acquire+0x1358/0x1a20 [ 32.840826] lock_acquire+0xc7/0x1d0 [ 32.841309] _raw_spin_lock_irqsave+0x44/0x80 [ 32.841916] __lock_task_sighand+0x79/0x160 [ 32.842465] do_send_sig_info+0x35/0x90 [ 32.842977] bpf_send_signal+0xa/0x10 [ 32.843464] bpf_prog_bc13ed9e4d3163e3_send_signal_tp_sched+0x465/0x1000 [ 32.844301] trace_call_bpf+0x115/0x270 [ 32.844809] perf_trace_run_bpf_submit+0x4a/0xc0 [ 32.845411] perf_trace_sched_switch+0x10f/0x180 [ 32.846014] __schedule+0x45d/0x880 [ 32.846483] schedule+0x5f/0xd0 ... [ 32.853148] Chain exists of: [ 32.853148] &(&sighand->siglock)->rlock --> &p->pi_lock --> &rq->lock [ 32.853148] [ 32.854451] Possible unsafe locking scenario: [ 32.854451] [ 32.855173] CPU0 CPU1 [ 32.855745] ---- ---- [ 32.856278] lock(&rq->lock); [ 32.856671] lock(&p->pi_lock); [ 32.857332] lock(&rq->lock); [ 32.857999] lock(&(&sighand->siglock)->rlock); Deadlock happens on CPU0 when it tries to acquire &sighand->siglock but it has been held by CPU1 and CPU1 tries to grab &rq->lock and cannot get it. This is not exactly the callstack in our production environment, but sympotom is similar and both locks are using spin_lock_irqsave() to acquire the lock, and both involves rq_lock. The fix to delay sending signal when irq is disabled also fixed this issue. Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Cc: Song Liu Link: https://lore.kernel.org/bpf/20200304191104.2796501-1-yhs@fb.com + Changed Files: kernel/trace/bpf_trace.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: 52e7c083b417417bb4352ebf3a6409988b6af238 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes a deadlock issue in bpf_send_signal() by delaying signal sending when IRQs are disabled.", + "keywords": "deadlock,bpf_send_signal,fix", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes a deadlock issue in bpf_send_signal() by delaying signal sending when IRQs are disabled in eBPF trace helper.", + "keywords": "deadlock,bpf_send_signal,trace", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 447/6895 - Commit ID: af33d2433b03d63ed31fcfda842f46676a5e1afc +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: af33d2433b03d63ed31fcfda842f46676a5e1afc + Author Name: Tycho Andersen + Author Email: tycho@tycho.ws + Commit Date: 1583445495 + Commit Message: + riscv: fix seccomp reject syscall code path If secure_computing() rejected a system call, we were previously setting the system call number to -1, to indicate to later code that the syscall failed. However, if something (e.g. a user notification) was sleeping, and received a signal, we may set a0 to -ERESTARTSYS and re-try the system call again. In this case, seccomp "denies" the syscall (because of the signal), and we would set a7 to -1, thus losing the value of the system call we want to restart. Instead, let's return -1 from do_syscall_trace_enter() to indicate that the syscall was rejected, so we don't clobber the value in case of -ERESTARTSYS or whatever. This commit fixes the user_notification_signal seccomp selftest on riscv to no longer hang. That test expects the system call to be re-issued after the signal, and it wasn't due to the above bug. Now that it is, everything works normally. Note that in the ptrace (tracer) case, the tracer can set the register values to whatever they want, so we still need to keep the code that handles out-of-bounds syscalls. However, we can drop the comment. We can also drop syscall_set_nr(), since it is no longer used anywhere, and the code that re-loads the value in a7 because of it. Reported in: https://lore.kernel.org/bpf/CAEn-LTp=ss0Dfv6J00=rCAy+N78U2AmhqJNjfqjr2FDpPYjxEQ@mail.gmail.com/ Reported-by: David Abdurachmanov Signed-off-by: Tycho Andersen Reviewed-by: Kees Cook Signed-off-by: Palmer Dabbelt + Changed Files: arch/riscv/include/asm/syscall.h | 7 -------; arch/riscv/kernel/entry.S | 11 +++--------; arch/riscv/kernel/ptrace.c | 11 +++++------; 3 files changed, 8 insertions(+), 21 deletions(-) + Parent Hashes: 0a91330b2af9f71ceeeed483f92774182b58f6d9 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes seccomp syscall rejection handling on RISC-V architecture to prevent missing retries on signals.", + "keywords": "seccomp,RISC-V,syscall", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes seccomp syscall rejection handling on RISC-V architecture to prevent missing retries on signals.", + "keywords": "seccomp,RISC-V,syscall", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +-------------------- +-------------------- +Processing Commit 448/6895 - Commit ID: 52e7c083b417417bb4352ebf3a6409988b6af238 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 52e7c083b417417bb4352ebf3a6409988b6af238 + Author Name: Quentin Monnet + Author Email: quentin@isovalent.com + Commit Date: 1583434989 + Commit Message: + mailmap: Update email address My Netronome address is no longer active. I am no maintainer, but get_maintainer.pl sometimes returns my name for a small number of files (BPF-related). Add an entry to .mailmap for good measure. Signed-off-by: Quentin Monnet Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200226171353.18982-1-quentin@isovalent.com Signed-off-by: Alexei Starovoitov + Changed Files: .mailmap | 1 +; 1 file changed, 1 insertion(+) + Parent Hashes: 209c65b61d94344522c41a83cd6ce51aac5fd0a4 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Update the .mailmap file to reflect a change in the author's email address for BPF-related files.", + "keywords": "mailmap,email,BPF", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +Rethinking... +new content: +{ + "summary": "Update .mailmap for author's email change to maintain BPF-related file references.", + "keywords": "mailmap,email,BPF", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +-------------------- +-------------------- +Processing Commit 449/6895 - Commit ID: dad737c926b5b286b9c91abbda66811a8a6618e9 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: dad737c926b5b286b9c91abbda66811a8a6618e9 + Author Name: Luke Nelson + Author Email: lukenels@cs.washington.edu + Commit Date: 1583421327 + Commit Message: + MAINTAINERS: Add entry for RV32G BPF JIT Add a new entry for the 32-bit RISC-V JIT to MAINTAINERS and change mailing list to netdev and bpf following the guidelines from commit e42da4c62abb ("docs/bpf: Update bpf development Q/A file"). Signed-off-by: Xi Wang Signed-off-by: Luke Nelson Signed-off-by: Daniel Borkmann Reviewed-by: Björn Töpel Acked-by: Björn Töpel Link: https://lore.kernel.org/bpf/20200305050207.4159-5-luke.r.nels@gmail.com + Changed Files: MAINTAINERS | 13 ++++++++++++-; 1 file changed, 12 insertions(+), 1 deletion(-) + Parent Hashes: 06b741521622331eb01b67123e8cdda6ca8be187 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Adds a new entry for 32-bit RISC-V JIT in MAINTAINERS and updates the mailing list according to guidelines.", + "keywords": "MAINTAINERS,RV32G,JIT", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Adds a 32-bit RISC-V JIT entry to the MAINTAINERS file and updates mailing list instructions.", + "keywords": "MAINTAINERS,RV32G,JIT", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "I'm not sure about the logic component of the commit. The affected logic component is unclear.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 450/6895 - Commit ID: 06b741521622331eb01b67123e8cdda6ca8be187 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 06b741521622331eb01b67123e8cdda6ca8be187 + Author Name: Luke Nelson + Author Email: lukenels@cs.washington.edu + Commit Date: 1583421227 + Commit Message: + bpf, doc: Add BPF JIT for RV32G to BPF documentation Update filter.txt and admin-guide to mention the BPF JIT for RV32G. Co-developed-by: Xi Wang Signed-off-by: Xi Wang Signed-off-by: Luke Nelson Signed-off-by: Daniel Borkmann Reviewed-by: Björn Töpel Acked-by: Björn Töpel Link: https://lore.kernel.org/bpf/20200305050207.4159-4-luke.r.nels@gmail.com + Changed Files: Documentation/admin-guide/sysctl/net.rst | 3 ++-; Documentation/networking/filter.txt | 2 +-; 2 files changed, 3 insertions(+), 2 deletions(-) + Parent Hashes: 5f316b65e99f109942c556dc8790abd4c75bcb34 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit updates the BPF documentation to include information about the BPF JIT for RV32G.", + "keywords": "BPF,documentation,JIT", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit updates documentation to include the BPF JIT for RV32G.", + "keywords": "BPF,documentation,JIT", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 451/6895 - Commit ID: 5f316b65e99f109942c556dc8790abd4c75bcb34 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 5f316b65e99f109942c556dc8790abd4c75bcb34 + Author Name: Luke Nelson + Author Email: lukenels@cs.washington.edu + Commit Date: 1583421227 + Commit Message: + riscv, bpf: Add RV32G eBPF JIT This is an eBPF JIT for RV32G, adapted from the JIT for RV64G and the 32-bit ARM JIT. There are two main changes required for this to work compared to the RV64 JIT. First, eBPF registers are 64-bit, while RV32G registers are 32-bit. BPF registers either map directly to 2 RISC-V registers, or reside in stack scratch space and are saved and restored when used. Second, many 64-bit ALU operations do not trivially map to 32-bit operations. Operations that move bits between high and low words, such as ADD, LSH, MUL, and others must emulate the 64-bit behavior in terms of 32-bit instructions. This patch also makes related changes to bpf_jit.h, such as adding RISC-V instructions required by the RV32 JIT. Supported features: The RV32 JIT supports the same features and instructions as the RV64 JIT, with the following exceptions: - ALU64 DIV/MOD: Requires loops to implement on 32-bit hardware. - BPF_XADD | BPF_DW: There's no 8-byte atomic instruction in RV32. These features are also unsupported on other BPF JITs for 32-bit architectures. Testing: - lib/test_bpf.c test_bpf: Summary: 378 PASSED, 0 FAILED, [349/366 JIT'ed] test_bpf: test_skb_segment: Summary: 2 PASSED, 0 FAILED The tests that are not JITed are all due to use of 64-bit div/mod or 64-bit xadd. - tools/testing/selftests/bpf/test_verifier.c Summary: 1415 PASSED, 122 SKIPPED, 43 FAILED Tested both with and without BPF JIT hardening. This is the same set of tests that pass using the BPF interpreter with the JIT disabled. Verification and synthesis: We developed the RV32 JIT using our automated verification tool, Serval. We have used Serval in the past to verify patches to the RV64 JIT. We also used Serval to superoptimize the resulting code through program synthesis. You can find the tool and a guide to the approach and results here: https://github.com/uw-unsat/serval-bpf/tree/rv32-jit-v5 Co-developed-by: Xi Wang Signed-off-by: Xi Wang Signed-off-by: Luke Nelson Signed-off-by: Daniel Borkmann Reviewed-by: Björn Töpel Acked-by: Björn Töpel Link: https://lore.kernel.org/bpf/20200305050207.4159-3-luke.r.nels@gmail.com + Changed Files: arch/riscv/Kconfig | 2 +-; arch/riscv/net/Makefile | 8 +-; arch/riscv/net/bpf_jit.h | 48 ++; arch/riscv/net/bpf_jit_comp32.c | 1310 +++++++++++++++++++++++++++++++++++++++; 4 files changed, 1366 insertions(+), 2 deletions(-) + Parent Hashes: ca6cb5447ceca6a87d6b62c9e5d41042c34f7ffa +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Add an eBPF JIT compiler for RISC-V RV32G architecture based on existing RV64G and ARM JIT implementations.", + "keywords": "eBPF JIT,RV32G,RISC-V", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Add an eBPF JIT for RISC-V RV32G architecture with adaptations from RV64G and ARM JIT implementations.", + "keywords": "eBPF JIT,RV32G,RISC-V", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 452/6895 - Commit ID: ca6cb5447ceca6a87d6b62c9e5d41042c34f7ffa +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: ca6cb5447ceca6a87d6b62c9e5d41042c34f7ffa + Author Name: Luke Nelson + Author Email: lukenels@cs.washington.edu + Commit Date: 1583421227 + Commit Message: + riscv, bpf: Factor common RISC-V JIT code This patch factors out code that can be used by both the RV64 and RV32 BPF JITs to a common bpf_jit.h and bpf_jit_core.c. Move struct definitions and macro-like functions to header. Rename rv_sb_insn/rv_uj_insn to rv_b_insn/rv_j_insn to match the RISC-V specification. Move reusable functions emit_body() and bpf_int_jit_compile() to bpf_jit_core.c with minor simplifications. Rename emit_insn() and build_{prologue,epilogue}() to be prefixed with "bpf_jit_" as they are no longer static. Rename bpf_jit_comp.c to bpf_jit_comp64.c to be more explicit. Co-developed-by: Xi Wang Signed-off-by: Xi Wang Signed-off-by: Luke Nelson Signed-off-by: Daniel Borkmann Reviewed-by: Björn Töpel Acked-by: Björn Töpel Link: https://lore.kernel.org/bpf/20200305050207.4159-2-luke.r.nels@gmail.com + Changed Files: arch/riscv/net/Makefile | 3 +-; arch/riscv/net/bpf_jit.h | 466 +++++++++++; arch/riscv/net/bpf_jit_comp.c | 1698 ---------------------------------------; arch/riscv/net/bpf_jit_comp64.c | 1103 +++++++++++++++++++++++++; arch/riscv/net/bpf_jit_core.c | 166 ++++; 5 files changed, 1737 insertions(+), 1699 deletions(-) + Parent Hashes: 9ce6010290587f4b0c57e2819481bd5ba9668349 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit refactors and consolidates common RISC-V BPF JIT code into shared files for RV64 and RV32 architectures.", + "keywords": "RISC-V,JIT,refactor", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit refactors and consolidates common RISC-V BPF JIT code into shared files for RV64 and RV32 architectures.", + "keywords": "RISC-V,JIT,refactor", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 453/6895 - Commit ID: 9ce6010290587f4b0c57e2819481bd5ba9668349 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 9ce6010290587f4b0c57e2819481bd5ba9668349 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1583358436 + Commit Message: + Merge branch 'bpf_modify_ret' KP Singh says: ==================== v3 -> v4: * Fix a memory leak noticed by Daniel. v2 -> v3: * bpf_trampoline_update_progs -> bpf_trampoline_get_progs + const qualification. * Typos in commit messages. * Added Andrii's Acks. v1 -> v2: * Adressed Andrii's feedback. * Fixed a bug that Alexei noticed about nop generation. * Rebase. This was brought up in the KRSI v4 discussion and found to be useful both for security and tracing programs. https://lore.kernel.org/bpf/20200225193108.GB22391@chromium.org/ The modify_return programs are allowed for security hooks (with an extra CAP_MAC_ADMIN check) and functions whitelisted for error injection (ALLOW_ERROR_INJECTION). The "security_" check is expected to be cleaned up with the KRSI patch series. Here is an example of how a fmod_ret program behaves: int func_to_be_attached(int a, int b) { <--- do_fentry do_fmod_ret: if (ret != 0) goto do_fexit; original_function: } <--- do_fexit ALLOW_ERROR_INJECTION(func_to_be_attached, ERRNO) The fmod_ret program attached to this function can be defined as: SEC("fmod_ret/func_to_be_attached") int BPF_PROG(func_name, int a, int b, int ret) { // This will skip the original function logic. return -1; } ==================== Signed-off-by: Alexei Starovoitov + Changed Files: nan + Parent Hashes: cc6fa771024ffdb428bdf25a94309cf21e8ef1b9 3d08b6f29cf33aeaf301553d8d3805f0aa609df7 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges a branch that includes modifications for security and tracing programs related to function return modifications and error injections in eBPF.", + "keywords": "security, tracing, error injection", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "LSM type related programs. It relates to eBPF programs used with Linux Security Modules (LSMs) for security enhancements.", + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges changes for security and tracing programs focused on function return modifications and error injections in eBPF.", + "keywords": "security, tracing, merge", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "LSM type related programs. It relates to eBPF programs used with Linux Security Modules (LSMs) for security enhancements.", + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 454/6895 - Commit ID: 3d08b6f29cf33aeaf301553d8d3805f0aa609df7 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 3d08b6f29cf33aeaf301553d8d3805f0aa609df7 + Author Name: KP Singh + Author Email: kpsingh@google.com + Commit Date: 1583358066 + Commit Message: + bpf: Add selftests for BPF_MODIFY_RETURN Test for two scenarios: * When the fmod_ret program returns 0, the original function should be called along with fentry and fexit programs. * When the fmod_ret program returns a non-zero value, the original function should not be called, no side effect should be observed and fentry and fexit programs should be called. The result from the kernel function call and whether a side-effect is observed is returned via the retval attr of the BPF_PROG_TEST_RUN (bpf) syscall. Signed-off-by: KP Singh Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Acked-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200304191853.1529-8-kpsingh@chromium.org + Changed Files: net/bpf/test_run.c | 22 +++++++-; .../selftests/bpf/prog_tests/modify_return.c | 65 ++++++++++++++++++++++; tools/testing/selftests/bpf/progs/modify_return.c | 49 ++++++++++++++++; 3 files changed, 135 insertions(+), 1 deletion(-) + Parent Hashes: da00d2f117a08fbca262db5ea422c80a568b112b +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds self-tests for BPF_MODIFY_RETURN to verify correct behavior of fmod_ret programs in different scenarios.", + "keywords": "selftests,BPF_MODIFY_RETURN,fmod_ret", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds self-tests for BPF_MODIFY_RETURN to verify correct behavior of fmod_ret programs in different scenarios.", + "keywords": "selftests,BPF_MODIFY_RETURN,fmod_ret", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 455/6895 - Commit ID: da00d2f117a08fbca262db5ea422c80a568b112b +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: da00d2f117a08fbca262db5ea422c80a568b112b + Author Name: KP Singh + Author Email: kpsingh@google.com + Commit Date: 1583358066 + Commit Message: + bpf: Add test ops for BPF_PROG_TYPE_TRACING The current fexit and fentry tests rely on a different program to exercise the functions they attach to. Instead of doing this, implement the test operations for tracing which will also be used for BPF_MODIFY_RETURN in a subsequent patch. Also, clean up the fexit test to use the generated skeleton. Signed-off-by: KP Singh Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Acked-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200304191853.1529-7-kpsingh@chromium.org + Changed Files: include/linux/bpf.h | 10 ++++; kernel/trace/bpf_trace.c | 1 +; net/bpf/test_run.c | 37 +++++++++---; .../selftests/bpf/prog_tests/fentry_fexit.c | 12 +---; .../testing/selftests/bpf/prog_tests/fentry_test.c | 14 ++---; .../testing/selftests/bpf/prog_tests/fexit_test.c | 69 +++++++---------------; 6 files changed, 67 insertions(+), 76 deletions(-) + Parent Hashes: aca228cd3387447d99d3ebaee3ebcc2b015a3e46 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Add test operations for BPF_PROG_TYPE_TRACING and clean up existing fexit and fentry tests.", + "keywords": "test, tracing, fexit", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Add test operations for BPF_PROG_TYPE_TRACING and clean up existing fexit and fentry tests.", + "keywords": "test, tracing, fexit", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 456/6895 - Commit ID: aca228cd3387447d99d3ebaee3ebcc2b015a3e46 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: aca228cd3387447d99d3ebaee3ebcc2b015a3e46 + Author Name: KP Singh + Author Email: kpsingh@google.com + Commit Date: 1583358065 + Commit Message: + tools/libbpf: Add support for BPF_MODIFY_RETURN Signed-off-by: KP Singh Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Acked-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200304191853.1529-6-kpsingh@chromium.org + Changed Files: tools/lib/bpf/libbpf.c | 4 ++++; 1 file changed, 4 insertions(+) + Parent Hashes: 6ba43b761c41349140662e223401bec0e48950e7 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds support for BPF_MODIFY_RETURN in the libbpf library.", + "keywords": "libbpf,BPF_MODIFY_RETURN,support", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds support for BPF_MODIFY_RETURN in the libbpf library.", + "keywords": "libbpf,BPF_MODIFY_RETURN,support", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 457/6895 - Commit ID: 6ba43b761c41349140662e223401bec0e48950e7 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 6ba43b761c41349140662e223401bec0e48950e7 + Author Name: KP Singh + Author Email: kpsingh@google.com + Commit Date: 1583358065 + Commit Message: + bpf: Attachment verification for BPF_MODIFY_RETURN - Allow BPF_MODIFY_RETURN attachment only to functions that are: * Whitelisted for error injection by checking within_error_injection_list. Similar discussions happened for the bpf_override_return helper. * security hooks, this is expected to be cleaned up with the LSM changes after the KRSI patches introduce the LSM_HOOK macro: https://lore.kernel.org/bpf/20200220175250.10795-1-kpsingh@chromium.org/ - The attachment is currently limited to functions that return an int. This can be extended later other types (e.g. PTR). Signed-off-by: KP Singh Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Acked-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200304191853.1529-5-kpsingh@chromium.org + Changed Files: kernel/bpf/btf.c | 28 ++++++++++++++++++++--------; kernel/bpf/verifier.c | 31 +++++++++++++++++++++++++++++++; 2 files changed, 51 insertions(+), 8 deletions(-) + Parent Hashes: ae24082331d9bbaae283aafbe930a8f0eb85605a +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds verification for BPF_MODIFY_RETURN attachment to ensure it only applies to specific functions.", + "keywords": "BPF_MODIFY_RETURN, verification, functions", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "LSM type related programs. It relates to eBPF programs used with Linux Security Modules (LSMs) for security enhancements." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds validation for BPF_MODIFY_RETURN attachments, restricting them to whitelisted functions or security hooks.", + "keywords": "BPF_MODIFY_RETURN, validation, hooks", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "LSM type related programs. It relates to eBPF programs used with Linux Security Modules (LSMs) for security enhancements." + ] +} +-------------------- +-------------------- +Processing Commit 458/6895 - Commit ID: ae24082331d9bbaae283aafbe930a8f0eb85605a +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: ae24082331d9bbaae283aafbe930a8f0eb85605a + Author Name: KP Singh + Author Email: kpsingh@google.com + Commit Date: 1583358065 + Commit Message: + bpf: Introduce BPF_MODIFY_RETURN When multiple programs are attached, each program receives the return value from the previous program on the stack and the last program provides the return value to the attached function. The fmod_ret bpf programs are run after the fentry programs and before the fexit programs. The original function is only called if all the fmod_ret programs return 0 to avoid any unintended side-effects. The success value, i.e. 0 is not currently configurable but can be made so where user-space can specify it at load time. For example: int func_to_be_attached(int a, int b) { <--- do_fentry do_fmod_ret: if (ret != 0) goto do_fexit; original_function: } <--- do_fexit The fmod_ret program attached to this function can be defined as: SEC("fmod_ret/func_to_be_attached") int BPF_PROG(func_name, int a, int b, int ret) { // This will skip the original function logic. return 1; } The first fmod_ret program is passed 0 in its return argument. Signed-off-by: KP Singh Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Acked-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200304191853.1529-4-kpsingh@chromium.org + Changed Files: arch/x86/net/bpf_jit_comp.c | 130 +++++++++++++++++++++++++++++++++++++----; include/linux/bpf.h | 1 +; include/uapi/linux/bpf.h | 1 +; kernel/bpf/btf.c | 3 +-; kernel/bpf/syscall.c | 1 +; kernel/bpf/trampoline.c | 5 +-; kernel/bpf/verifier.c | 1 +; tools/include/uapi/linux/bpf.h | 1 +; 8 files changed, 130 insertions(+), 13 deletions(-) + Parent Hashes: 7e639208e88d60abf83d48dfda4c0ad325a77b58 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Introduces BPF_MODIFY_RETURN to prevent original function execution based on fmod_ret programs' return values.", + "keywords": "BPF_MODIFY_RETURN,fmod_ret,functions", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Introduces BPF_MODIFY_RETURN feature to control execution of original functions through return values in eBPF programs.", + "keywords": "BPF_MODIFY_RETURN,fmod_ret,return", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 459/6895 - Commit ID: 7e639208e88d60abf83d48dfda4c0ad325a77b58 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 7e639208e88d60abf83d48dfda4c0ad325a77b58 + Author Name: KP Singh + Author Email: kpsingh@google.com + Commit Date: 1583358065 + Commit Message: + bpf: JIT helpers for fmod_ret progs * Split the invoke_bpf program to prepare for special handling of fmod_ret programs introduced in a subsequent patch. * Move the definition of emit_cond_near_jump and emit_nops as they are needed for fmod_ret. * Refactor branch target alignment into its own generic helper function i.e. emit_align. Signed-off-by: KP Singh Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Acked-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200304191853.1529-3-kpsingh@chromium.org + Changed Files: arch/x86/net/bpf_jit_comp.c | 148 +++++++++++++++++++++++++-------------------; 1 file changed, 85 insertions(+), 63 deletions(-) + Parent Hashes: 88fd9e5352fe05f7fe57778293aebd4cd106960b +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Refactor and prepare JIT helpers for specialized handling of fmod_ret programs in eBPF.", + "keywords": "JIT,fmod_ret,refactor", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Refactor eBPF JIT helpers for improved handling of fmod_ret programs.", + "keywords": "JIT,fmod_ret,refactor", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 460/6895 - Commit ID: 88fd9e5352fe05f7fe57778293aebd4cd106960b +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 88fd9e5352fe05f7fe57778293aebd4cd106960b + Author Name: KP Singh + Author Email: kpsingh@google.com + Commit Date: 1583358065 + Commit Message: + bpf: Refactor trampoline update code As we need to introduce a third type of attachment for trampolines, the flattened signature of arch_prepare_bpf_trampoline gets even more complicated. Refactor the prog and count argument to arch_prepare_bpf_trampoline to use bpf_tramp_progs to simplify the addition and accounting for new attachment types. Signed-off-by: KP Singh Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Acked-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200304191853.1529-2-kpsingh@chromium.org + Changed Files: arch/x86/net/bpf_jit_comp.c | 31 ++++++++++++-----------; include/linux/bpf.h | 13 ++++++++--; kernel/bpf/bpf_struct_ops.c | 10 +++++++-; kernel/bpf/trampoline.c | 62 +++++++++++++++++++++++++--------------------; 4 files changed, 71 insertions(+), 45 deletions(-) + Parent Hashes: cc6fa771024ffdb428bdf25a94309cf21e8ef1b9 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Refactor of trampoline code to facilitate new attachment types by simplifying signature with bpf_tramp_progs.", + "keywords": "trampoline, refactor, attachment", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Refactor the trampoline code to simplify addition of new attachment types using bpf_tramp_progs.", + "keywords": "trampoline, refactor, attachment", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 461/6895 - Commit ID: cc6fa771024ffdb428bdf25a94309cf21e8ef1b9 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: cc6fa771024ffdb428bdf25a94309cf21e8ef1b9 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1583352005 + Commit Message: + selftests/bpf: Support out-of-tree vmlinux builds for VMLINUX_BTF Add detection of out-of-tree built vmlinux image for the purpose of VMLINUX_BTF detection. According to Documentation/kbuild/kbuild.rst, O takes precedence over KBUILD_OUTPUT. Also ensure ~/path/to/build/dir also works by relying on wildcard's resolution first, but then applying $(abspath) at the end to also handle O=../../whatever cases. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200304184336.165766-1-andriin@fb.com + Changed Files: tools/testing/selftests/bpf/Makefile | 11 +++++++----; 1 file changed, 7 insertions(+), 4 deletions(-) + Parent Hashes: af73d78bd384aa9b8789aa6e7ddbb165f971276f +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit enhances the VMLINUX_BTF detection logic to support out-of-tree vmlinux builds in eBPF selftests.", + "keywords": "vmlinux, VMLINUX_BTF, out-of-tree", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit enhances the VMLINUX_BTF detection logic to support out-of-tree vmlinux builds in eBPF selftests.", + "keywords": "vmlinux,VMLINUX_BTF,out-of-tree", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 462/6895 - Commit ID: af73d78bd384aa9b8789aa6e7ddbb165f971276f +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: af73d78bd384aa9b8789aa6e7ddbb165f971276f + Author Name: Kees Cook + Author Email: keescook@chromium.org + Commit Date: 1583343393 + Commit Message: + kbuild: Remove debug info from kallsyms linking When CONFIG_DEBUG_INFO is enabled, the two kallsyms linking steps spend time collecting and writing the dwarf sections to the temporary output files. kallsyms does not need this information, and leaving it off halves their linking time. This is especially noticeable without CONFIG_DEBUG_INFO_REDUCED. The BTF linking stage, however, does still need those details. Refactor the BTF and kallsyms generation stages slightly for more regularized temporary names. Skip debug during kallsyms links. Additionally move "info BTF" to the correct place since commit 8959e39272d6 ("kbuild: Parameterize kallsyms generation and correct reporting"), which added "info LD ..." to vmlinux_link calls. For a full debug info build with BTF, my link time goes from 1m06s to 0m54s, saving about 12 seconds, or 18%. Signed-off-by: Kees Cook Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/202003031814.4AEA3351@keescook + Changed Files: scripts/link-vmlinux.sh | 28 +++++++++++++++++++---------; 1 file changed, 19 insertions(+), 9 deletions(-) + Parent Hashes: 0641cadac46710bf7f87fa46067194ec1d932d90 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit optimizes kallsyms linking in the build process by removing unnecessary debug info, reducing link time by 18%.", + "keywords": "kallsyms,debug,linking", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit optimizes build performance by removing unnecessary debug info during kallsyms linking, reducing link time by 18%.", + "keywords": "kallsyms,debug,optimization", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +-------------------- +-------------------- +Processing Commit 463/6895 - Commit ID: 0641cadac46710bf7f87fa46067194ec1d932d90 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 0641cadac46710bf7f87fa46067194ec1d932d90 + Author Name: Daniel Borkmann + Author Email: daniel@iogearbox.net + Commit Date: 1583337610 + Commit Message: + Merge branch 'bpf-uapi-enums' Andrii Nakryiko says: ==================== Convert BPF-related UAPI constants, currently defined as #define macro, into anonymous enums. This has no difference in terms of usage of such constants in C code (they are still could be used in all the compile-time contexts that `#define`s can), but they are recorded as part of DWARF type info, and subsequently get recorded as part of kernel's BTF type info. This allows those constants to be emitted as part of vmlinux.h auto-generated header file and be used from BPF programs. Which is especially convenient for all kinds of BPF helper flags and makes CO-RE BPF programs nicer to write. libbpf's btf_dump logic currently assumes enum values are signed 32-bit values, but that doesn't match a typical case, so switch it to emit unsigned values. Once BTF encoding of BTF_KIND_ENUM is extended to capture signedness properly, this will be made more flexible. As an immediate validation of the approach, runqslower's copy of BPF_F_CURRENT_CPU #define is dropped in favor of its enum variant from vmlinux.h. v2->v3: - convert only constants usable from BPF programs (BPF helper flags, map create flags, etc) (Alexei); v1->v2: - fix up btf_dump test to use max 32-bit unsigned value instead of negative one. ==================== Signed-off-by: Daniel Borkmann + Changed Files: nan + Parent Hashes: 320a36063e1441210106aa33997ad3770d4c86b4 367d82f17eff53cec531920eb0de9973fac89ec1 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit converts BPF-related UAPI constants from macros to anonymous enums for improved BTF integration and convenience in BPF programs.", + "keywords": "enums,UAPI,BTF", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit merges changes to convert BPF UAPI constants from macros to enums for better BTF use in BPF programs.", + "keywords": "enums,UAPI,BTF", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 464/6895 - Commit ID: 367d82f17eff53cec531920eb0de9973fac89ec1 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 367d82f17eff53cec531920eb0de9973fac89ec1 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1583337606 + Commit Message: + tools/runqslower: Drop copy/pasted BPF_F_CURRENT_CPU definiton With BPF_F_CURRENT_CPU being an enum, it is now captured in vmlinux.h and is readily usable by runqslower. So drop local copy/pasted definition in favor of the one coming from vmlinux.h. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200303003233.3496043-4-andriin@fb.com + Changed Files: tools/bpf/runqslower/runqslower.bpf.c | 3 ---; 1 file changed, 3 deletions(-) + Parent Hashes: 7cb30aaab3f277aa88e20a008faf57e0fb1119ec +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit removes a redundant local definition of BPF_F_CURRENT_CPU in runqslower, using vmlinux.h instead.", + "keywords": "BPF_F_CURRENT_CPU, runqslower, vmlinux.h", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit removes a redundant local definition of BPF_F_CURRENT_CPU in runqslower, using vmlinux.h instead.", + "keywords": "BPF_F_CURRENT_CPU, runqslower, vmlinux", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 465/6895 - Commit ID: 7cb30aaab3f277aa88e20a008faf57e0fb1119ec +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 7cb30aaab3f277aa88e20a008faf57e0fb1119ec + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1583337606 + Commit Message: + libbpf: Assume unsigned values for BTF_KIND_ENUM Currently, BTF_KIND_ENUM type doesn't record whether enum values should be interpreted as signed or unsigned. In Linux, most enums are unsigned, though, so interpreting them as unsigned matches real world better. Change btf_dump test case to test maximum 32-bit value, instead of negative value. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200303003233.3496043-3-andriin@fb.com + Changed Files: tools/lib/bpf/btf_dump.c | 8 ++++----; tools/testing/selftests/bpf/progs/btf_dump_test_case_syntax.c | 2 +-; 2 files changed, 5 insertions(+), 5 deletions(-) + Parent Hashes: 1aae4bdd787998ea331a56f3db9d8595790fe2f9 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Updated libbpf to interpret BTF_KIND_ENUM as unsigned and adjusted test cases accordingly.", + "keywords": "unsigned, enums, libbpf", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Updated libbpf to interpret BTF_KIND_ENUM as unsigned and adjusted test cases accordingly.", + "keywords": "unsigned, enums, libbpf", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 466/6895 - Commit ID: 1aae4bdd787998ea331a56f3db9d8595790fe2f9 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 1aae4bdd787998ea331a56f3db9d8595790fe2f9 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1583337605 + Commit Message: + bpf: Switch BPF UAPI #define constants used from BPF program side to enums Switch BPF UAPI constants, previously defined as #define macro, to anonymous enum values. This preserves constants values and behavior in expressions, but has added advantaged of being captured as part of DWARF and, subsequently, BTF type info. Which, in turn, greatly improves usefulness of generated vmlinux.h for BPF applications, as it will not require BPF users to copy/paste various flags and constants, which are frequently used with BPF helpers. Only those constants that are used/useful from BPF program side are converted. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200303003233.3496043-2-andriin@fb.com + Changed Files: include/uapi/linux/bpf.h | 175 +++++++++++++++++++++++++---------------; tools/include/uapi/linux/bpf.h | 177 +++++++++++++++++++++++++----------------; 2 files changed, 219 insertions(+), 133 deletions(-) + Parent Hashes: 320a36063e1441210106aa33997ad3770d4c86b4 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit modifies BPF UAPI constants to enums for improved BPF application integration and usage.", + "keywords": "BPF,enums,UAPI", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The syscall interface. It changes the system calls through which user-space programs interact with eBPF.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit refactors BPF UAPI constants to enums, enhancing vmlinux.h generation for BPF applications.", + "keywords": "BPF,UAPI,enums", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The syscall interface. It changes the system calls through which user-space programs interact with eBPF.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 467/6895 - Commit ID: 320a36063e1441210106aa33997ad3770d4c86b4 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 320a36063e1441210106aa33997ad3770d4c86b4 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1583282496 + Commit Message: + libbpf: Fix handling of optional field_name in btf_dump__emit_type_decl Internal functions, used by btf_dump__emit_type_decl(), assume field_name is never going to be NULL. Ensure it's always the case. Fixes: 9f81654eebe8 ("libbpf: Expose BTF-to-C type declaration emitting API") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200303180800.3303471-1-andriin@fb.com + Changed Files: tools/lib/bpf/btf_dump.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: 5fc40f37396cec199d40a417df74b39c8e458ca6 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes handling of optional field names in libbpf's BTF dump functionality to prevent NULL assumptions.", + "keywords": "libbpf,field_name,BTF", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes handling of optional field names in libbpf's BTF dump functionality to prevent NULL assumptions.", + "keywords": "libbpf,field_name,BTF", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 468/6895 - Commit ID: 5fc40f37396cec199d40a417df74b39c8e458ca6 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 5fc40f37396cec199d40a417df74b39c8e458ca6 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1583281444 + Commit Message: + Merge branch 'bpf_gso_size' Willem de Bruijn says: ==================== See first patch for details. Patch split across three parts { kernel feature, uapi header, tools } following the custom for such __sk_buff changes. ==================== Acked-by: Petar Penkov Signed-off-by: Alexei Starovoitov + Changed Files: nan + Parent Hashes: abbc61a5f26d52a5d3abbbe552b275360b2c6631 62511ceadf6e217f09d4ab1f9198d2bb5cc70e7c +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit merges the 'bpf_gso_size' branch, updating kernel features, UAPI headers, and tools.", + "keywords": "merge,bpf_gso_size,headers", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "The commit merges the 'bpf_gso_size' branch addressing kernel features, uapi headers, and tools related to eBPF changes.", + "keywords": "merge,bpf,gso", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 469/6895 - Commit ID: 62511ceadf6e217f09d4ab1f9198d2bb5cc70e7c +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 62511ceadf6e217f09d4ab1f9198d2bb5cc70e7c + Author Name: Willem de Bruijn + Author Email: willemb@google.com + Commit Date: 1583281439 + Commit Message: + selftests/bpf: Test new __sk_buff field gso_size Analogous to the gso_segs selftests introduced in commit d9ff286a0f59 ("bpf: allow BPF programs access skb_shared_info->gso_segs field"). Signed-off-by: Willem de Bruijn Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200303200503.226217-4-willemdebruijn.kernel@gmail.com + Changed Files: tools/testing/selftests/bpf/prog_tests/skb_ctx.c | 1 +; tools/testing/selftests/bpf/progs/test_skb_ctx.c | 2 +; tools/testing/selftests/bpf/verifier/ctx_skb.c | 47 ++++++++++++++++++++++++; 3 files changed, 50 insertions(+) + Parent Hashes: b0ac4941aa2a249bbb06de86110cd9e2e53980ca +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds a test for the new __sk_buff field gso_size in selftests for BPF.", + "keywords": "selftests,gso_size,__sk_buff", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds a test for the gso_size field in BPF selftests.", + "keywords": "selftests,gso_size,skb", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 470/6895 - Commit ID: b0ac4941aa2a249bbb06de86110cd9e2e53980ca +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: b0ac4941aa2a249bbb06de86110cd9e2e53980ca + Author Name: Willem de Bruijn + Author Email: willemb@google.com + Commit Date: 1583281439 + Commit Message: + bpf: Sync uapi bpf.h to tools/ sync tools/include/uapi/linux/bpf.h to match include/uapi/linux/bpf.h Signed-off-by: Willem de Bruijn Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200303200503.226217-3-willemdebruijn.kernel@gmail.com + Changed Files: tools/include/uapi/linux/bpf.h | 1 +; 1 file changed, 1 insertion(+) + Parent Hashes: cf62089b0edd7e74a1f474844b4d9f7b5697fb5c +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Sync uapi bpf.h file between kernel source and tools directory.", + "keywords": "sync,uapi,tools", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +Rethinking... +new content: +{ + "summary": "Sync uapi bpf.h file between kernel source and tools directory for consistency.", + "keywords": "bpf,sync,tools", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 471/6895 - Commit ID: cf62089b0edd7e74a1f474844b4d9f7b5697fb5c +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: cf62089b0edd7e74a1f474844b4d9f7b5697fb5c + Author Name: Willem de Bruijn + Author Email: willemb@google.com + Commit Date: 1583281439 + Commit Message: + bpf: Add gso_size to __sk_buff BPF programs may want to know whether an skb is gso. The canonical answer is skb_is_gso(skb), which tests that gso_size != 0. Expose this field in the same manner as gso_segs. That field itself is not a sufficient signal, as the comment in skb_shared_info makes clear: gso_segs may be zero, e.g., from dodgy sources. Also prepare net/bpf/test_run for upcoming BPF_PROG_TEST_RUN tests of the feature. Signed-off-by: Willem de Bruijn Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200303200503.226217-2-willemdebruijn.kernel@gmail.com + Changed Files: include/uapi/linux/bpf.h | 1 +; net/bpf/test_run.c | 7 +++++++; net/core/filter.c | 44 ++++++++++++++++++++++++++++++--------------; 3 files changed, 38 insertions(+), 14 deletions(-) + Parent Hashes: abbc61a5f26d52a5d3abbbe552b275360b2c6631 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds gso_size to __sk_buff and prepares test infrastructure for BPF_PROG_TEST_RUN tests of this field.", + "keywords": "gso_size,__sk_buff,BPF_PROG_TEST_RUN", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds gso_size to __sk_buff and prepares test infrastructure for BPF_PROG_TEST_RUN tests of this field.", + "keywords": "gso_size,__sk_buff,BPF_PROG_TEST_RUN", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 472/6895 - Commit ID: abbc61a5f26d52a5d3abbbe552b275360b2c6631 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: abbc61a5f26d52a5d3abbbe552b275360b2c6631 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1583216011 + Commit Message: + Merge branch 'bpf_link' Andrii Nakryiko says: ==================== This patch series adds bpf_link abstraction, analogous to libbpf's already existing bpf_link abstraction. This formalizes and makes more uniform existing bpf_link-like BPF program link (attachment) types (raw tracepoint and tracing links), which are FD-based objects that are automatically detached when last file reference is closed. These types of BPF program links are switched to using bpf_link framework. FD-based bpf_link approach provides great safety guarantees, by ensuring there is not going to be an abandoned BPF program attached, if user process suddenly exits or forgets to clean up after itself. This is especially important in production environment and is what all the recent new BPF link types followed. One of the previously existing inconveniences of FD-based approach, though, was the scenario in which user process wants to install BPF link and exit, but let attached BPF program run. Now, with bpf_link abstraction in place, it's easy to support pinning links in BPF FS, which is done as part of the same patch #1. This allows FD-based BPF program links to survive exit of a user process and original file descriptor being closed, by creating an file entry in BPF FS. This provides great safety by default, with simple way to opt out for cases where it's needed. Corresponding libbpf APIs are added in the same patch set, as well as selftests for this functionality. Other types of BPF program attachments (XDP, cgroup, perf_event, etc) are going to be converted in subsequent patches to follow similar approach. v1->v2: - use bpf_link_new_fd() uniformly (Alexei). ==================== Signed-off-by: Alexei Starovoitov + Changed Files: nan + Parent Hashes: 775a2be52da1c55fc810a5d151049f86f0fd5362 6489b8e1e3cf0eb8639e96610002837c53a677cd +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit merges the 'bpf_link' branch, introducing a bpf_link abstraction to standardize and improve bpf program link attachment and enhance safety with FD-based approach.", + "keywords": "bpf_link,abstraction,attachment", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "The commit merges the 'bpf_link' branch, introducing a bpf_link abstraction to standardize BPF program link attachment and improve safety using an FD-based approach.", + "keywords": "bpf_link,abstraction,safety", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 473/6895 - Commit ID: 6489b8e1e3cf0eb8639e96610002837c53a677cd +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 6489b8e1e3cf0eb8639e96610002837c53a677cd + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1583215587 + Commit Message: + selftests/bpf: Add link pinning selftests Add selftests validating link pinning/unpinning and associated BPF link (attachment) lifetime. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200303043159.323675-4-andriin@fb.com + Changed Files: .../selftests/bpf/prog_tests/link_pinning.c | 105 +++++++++++++++++++++; .../selftests/bpf/progs/test_link_pinning.c | 25 +++++; 2 files changed, 130 insertions(+) + Parent Hashes: c016b68edc7a2adf3db0f11fb649797c1f9216ea +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds selftests for validating link pinning and BPF link lifetime in the bpf subsystem.", + "keywords": "selftests link pinning", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds selftests for verifying BPF link pinning and attachment lifetime.", + "keywords": "selftests link pinning", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 474/6895 - Commit ID: c016b68edc7a2adf3db0f11fb649797c1f9216ea +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: c016b68edc7a2adf3db0f11fb649797c1f9216ea + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1583215587 + Commit Message: + libbpf: Add bpf_link pinning/unpinning With bpf_link abstraction supported by kernel explicitly, add pinning/unpinning API for links. Also allow to create (open) bpf_link from BPF FS file. This API allows to have an "ephemeral" FD-based BPF links (like raw tracepoint or fexit/freplace attachments) surviving user process exit, by pinning them in a BPF FS, which is an important use case for long-running BPF programs. As part of this, expose underlying FD for bpf_link. While legacy bpf_link's might not have a FD associated with them (which will be expressed as a bpf_link with fd=-1), kernel's abstraction is based around FD-based usage, so match it closely. This, subsequently, allows to have a generic pinning/unpinning API for generalized bpf_link. For some types of bpf_links kernel might not support pinning, in which case bpf_link__pin() will return error. With FD being part of generic bpf_link, also get rid of bpf_link_fd in favor of using vanialla bpf_link. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200303043159.323675-3-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.c | 131 +++++++++++++++++++++++++++++++++++++----------; tools/lib/bpf/libbpf.h | 5 ++; tools/lib/bpf/libbpf.map | 5 ++; 3 files changed, 114 insertions(+), 27 deletions(-) + Parent Hashes: 70ed506c3bbcfa846d4636b23051ca79fa4781f7 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Adds API for pinning and unpinning bpf_links to support long-running BPF programs by preserving link states across user process exits.", + "keywords": "bpf_link, pinning, API", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Adds API for pinning and unpinning bpf_links to support long-running BPF programs by preserving link states across user process exits.", + "keywords": "bpf_link, pinning, API", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 475/6895 - Commit ID: 70ed506c3bbcfa846d4636b23051ca79fa4781f7 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 70ed506c3bbcfa846d4636b23051ca79fa4781f7 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1583215587 + Commit Message: + bpf: Introduce pinnable bpf_link abstraction Introduce bpf_link abstraction, representing an attachment of BPF program to a BPF hook point (e.g., tracepoint, perf event, etc). bpf_link encapsulates ownership of attached BPF program, reference counting of a link itself, when reference from multiple anonymous inodes, as well as ensures that release callback will be called from a process context, so that users can safely take mutex locks and sleep. Additionally, with a new abstraction it's now possible to generalize pinning of a link object in BPF FS, allowing to explicitly prevent BPF program detachment on process exit by pinning it in a BPF FS and let it open from independent other process to keep working with it. Convert two existing bpf_link-like objects (raw tracepoint and tracing BPF program attachments) into utilizing bpf_link framework, making them pinnable in BPF FS. More FD-based bpf_links will be added in follow up patches. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200303043159.323675-2-andriin@fb.com + Changed Files: include/linux/bpf.h | 13 +++; kernel/bpf/inode.c | 42 +++++++++-; kernel/bpf/syscall.c | 223 +++++++++++++++++++++++++++++++++++++++++----------; 3 files changed, 232 insertions(+), 46 deletions(-) + Parent Hashes: 775a2be52da1c55fc810a5d151049f86f0fd5362 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit introduces a new bpf_link abstraction for attaching BPF programs to hook points, making them pinnable and supporting reference counting.", + "keywords": "bpf_link,pinnable,abstraction", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The syscall interface. It changes the system calls through which user-space programs interact with eBPF.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit introduces a bpf_link abstraction to represent BPF program attachments, making them pinnable and enhancing reference management.", + "keywords": "bpf_link,pinnable,abstraction", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The syscall interface. It changes the system calls through which user-space programs interact with eBPF.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 476/6895 - Commit ID: 775a2be52da1c55fc810a5d151049f86f0fd5362 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 775a2be52da1c55fc810a5d151049f86f0fd5362 + Author Name: Toke Høiland-Jørgensen + Author Email: toke@redhat.com + Commit Date: 1583197241 + Commit Message: + selftests/bpf: Declare bpf_log_buf variables as static The cgroup selftests did not declare the bpf_log_buf variable as static, leading to a linker error with GCC 10 (which defaults to -fno-common). Fix this by adding the missing static declarations. Fixes: 257c88559f36 ("selftests/bpf: Convert test_cgroup_attach to prog_tests") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Acked-by: Andrey Ignatov Link: https://lore.kernel.org/bpf/20200302145348.559177-1-toke@redhat.com + Changed Files: tools/testing/selftests/bpf/prog_tests/cgroup_attach_autodetach.c | 2 +-; tools/testing/selftests/bpf/prog_tests/cgroup_attach_multi.c | 2 +-; tools/testing/selftests/bpf/prog_tests/cgroup_attach_override.c | 2 +-; 3 files changed, 3 insertions(+), 3 deletions(-) + Parent Hashes: 441420a1f0b3031f228453697406c86f110e59d4 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds static declarations to bpf_log_buf variables in cgroup selftests to fix linker errors with GCC 10.", + "keywords": "static,declarations,cgroup", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups)." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds static declarations to bpf_log_buf variables in cgroup selftests to fix linker errors with GCC 10.", + "keywords": "static,declarations,cgroup", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups)." + ] +} +-------------------- +-------------------- +Processing Commit 477/6895 - Commit ID: 441420a1f0b3031f228453697406c86f110e59d4 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 441420a1f0b3031f228453697406c86f110e59d4 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1583196595 + Commit Message: + bpf: Reliably preserve btf_trace_xxx types btf_trace_xxx types, crucial for tp_btf BPF programs (raw tracepoint with verifier-checked direct memory access), have to be preserved in kernel BTF to allow verifier do its job and enforce type/memory safety. It was reported ([0]) that for kernels built with Clang current type-casting approach doesn't preserve these types. This patch fixes it by declaring an anonymous union for each registered tracepoint, capturing both struct bpf_raw_event_map information, as well as recording btf_trace_##call type reliably. Structurally, it's still the same content as for a plain struct bpf_raw_event_map, so no other changes are necessary. [0] https://github.com/iovisor/bcc/issues/2770#issuecomment-591007692 Fixes: e8c423fb31fa ("bpf: Add typecast to raw_tracepoints to help BTF generation") Reported-by: Wenbo Zhang Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200301081045.3491005-2-andriin@fb.com + Changed Files: include/trace/bpf_probe.h | 18 +++++++++++-------; 1 file changed, 11 insertions(+), 7 deletions(-) + Parent Hashes: 82dbbfc822cd7230c657b49da6557c8bf2f6621d +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit modifies how btf_trace_xxx types are preserved in the kernel BTF for tp_btf BPF programs by declaring anonymous unions.", + "keywords": "btf_trace_xxx, kernel BTF, tracepoint", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes the preservation of btf_trace_xxx types in kernel BTF by using anonymous unions for tp_btf BPF programs.", + "keywords": "btf_trace_xxx,kernel BTF,tracepoint", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing." + ] +} +-------------------- +-------------------- +Processing Commit 478/6895 - Commit ID: 82dbbfc822cd7230c657b49da6557c8bf2f6621d +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 82dbbfc822cd7230c657b49da6557c8bf2f6621d + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1583195122 + Commit Message: + Merge branch 'move_BPF_PROG_to_libbpf' Andrii Nakryiko says: ==================== Move BPF_PROG, BPF_KPROBE, and BPF_KRETPROBE helper macros from private selftests helpers to public libbpf ones. These helpers are extremely helpful for writing tracing BPF applications and have been requested to be exposed for easy use (e.g., [0]). As part of this move, fix up BPF_KRETPROBE to not allow for capturing input arguments (as it's unreliable and they will be often clobbered). Also, add vmlinux.h header guard to allow multi-time inclusion, if necessary; but also to let PT_REGS_PARM do proper detection of struct pt_regs field names on x86 arch. See relevant patches for more details. [0] https://github.com/iovisor/bcc/pull/2778#issue-381642907 ==================== Signed-off-by: Alexei Starovoitov + Changed Files: nan + Parent Hashes: 15070919f801348e9a9a2ea96f427d8b621f3cd5 df8ff35311c8d10d90b4604c02b32c361dc997aa +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges helper macros from private selftests to public libbpf for enhancing BPF tracing applications.", + "keywords": "libbpf,helper,macros", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges helper macros for BPF tracing applications from private selftests into the public libbpf library.", + "keywords": "merge,libbpf,tracing", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 479/6895 - Commit ID: df8ff35311c8d10d90b4604c02b32c361dc997aa +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: df8ff35311c8d10d90b4604c02b32c361dc997aa + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1583195114 + Commit Message: + libbpf: Merge selftests' bpf_trace_helpers.h into libbpf's bpf_tracing.h Move BPF_PROG, BPF_KPROBE, and BPF_KRETPROBE macro into libbpf's bpf_tracing.h header to make it available for non-selftests users. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200229231112.1240137-5-andriin@fb.com + Changed Files: tools/lib/bpf/bpf_tracing.h | 118 ++++++++++++++++++++; tools/testing/selftests/bpf/bpf_tcp_helpers.h | 2 +-; tools/testing/selftests/bpf/bpf_trace_helpers.h | 121 ---------------------; tools/testing/selftests/bpf/progs/bpf_dctcp.c | 2 +-; tools/testing/selftests/bpf/progs/fentry_test.c | 2 +-; tools/testing/selftests/bpf/progs/fexit_bpf2bpf.c | 2 +-; .../selftests/bpf/progs/fexit_bpf2bpf_simple.c | 2 +-; tools/testing/selftests/bpf/progs/fexit_test.c | 2 +-; tools/testing/selftests/bpf/progs/kfree_skb.c | 2 +-; .../selftests/bpf/progs/test_attach_probe.c | 2 +-; tools/testing/selftests/bpf/progs/test_overhead.c | 1 -; .../selftests/bpf/progs/test_perf_branches.c | 2 +-; .../testing/selftests/bpf/progs/test_perf_buffer.c | 2 +-; .../testing/selftests/bpf/progs/test_probe_user.c | 1 -; .../selftests/bpf/progs/test_trampoline_count.c | 3 +-; .../testing/selftests/bpf/progs/test_xdp_bpf2bpf.c | 2 +-; 16 files changed, 131 insertions(+), 135 deletions(-) + Parent Hashes: 396f544ed5e5a9c40de5663b774f643644cba059 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit merges bpf_trace_helpers.h into libbpf's bpf_tracing.h to make macros available to non-selftest users.", + "keywords": "libbpf, macros, tracing", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit integrates bpf_trace_helpers.h into libbpf's bpf_tracing.h to extend macro availability beyond selftests.", + "keywords": "libbpf, macros, tracing", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 480/6895 - Commit ID: 396f544ed5e5a9c40de5663b774f643644cba059 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 396f544ed5e5a9c40de5663b774f643644cba059 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1583195114 + Commit Message: + selftests/bpf: Fix BPF_KRETPROBE macro and use it in attach_probe test For kretprobes, there is no point in capturing input arguments from pt_regs, as they are going to be, most probably, clobbered by the time probed kernel function returns. So switch BPF_KRETPROBE to accept zero or one argument (optional return result). Fixes: ac065870d928 ("selftests/bpf: Add BPF_PROG, BPF_KPROBE, and BPF_KRETPROBE macros") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200229231112.1240137-4-andriin@fb.com + Changed Files: tools/testing/selftests/bpf/bpf_trace_helpers.h | 13 +++++++------; tools/testing/selftests/bpf/progs/test_attach_probe.c | 3 ++-; tools/testing/selftests/bpf/progs/test_overhead.c | 6 ++----; 3 files changed, 11 insertions(+), 11 deletions(-) + Parent Hashes: fd56e0058412fb542db0e9556f425747cf3f8366 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit fixes the BPF_KRETPROBE macro in selftests and changes its usage in the attach_probe test to handle zero or one argument.", + "keywords": "BPF_KRETPROBE,selftests,macro", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit fixes the BPF_KRETPROBE macro for kretprobes in selftests and adjusts its usage to handle arguments correctly.", + "keywords": "BPF_KRETPROBE,selftests,fix", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 481/6895 - Commit ID: fd56e0058412fb542db0e9556f425747cf3f8366 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: fd56e0058412fb542db0e9556f425747cf3f8366 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1583195114 + Commit Message: + libbpf: Fix use of PT_REGS_PARM macros with vmlinux.h Add detection of vmlinux.h to bpf_tracing.h header for PT_REGS macro. Currently, BPF applications have to define __KERNEL__ symbol to use correct definition of struct pt_regs on x86 arch. This is due to different field names under internal kernel vs UAPI conditions. To make this more transparent for users, detect vmlinux.h by checking __VMLINUX_H__ symbol. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200229231112.1240137-3-andriin@fb.com + Changed Files: tools/lib/bpf/bpf_tracing.h | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: ca7dc2791b507f842d73e46b1a0453b36b69ffc2 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fix in libbpf for detecting vmlinux.h to correctly use PT_REGS_PARM macros in BPF applications.", + "keywords": "libbpf, vmlinux.h, PT_REGS", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes PT_REGS_PARM macro usage in libbpf by adding vmlinux.h detection.", + "keywords": "libbpf, vmlinux.h, PT_REGS", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 482/6895 - Commit ID: ca7dc2791b507f842d73e46b1a0453b36b69ffc2 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: ca7dc2791b507f842d73e46b1a0453b36b69ffc2 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1583195114 + Commit Message: + bpftool: Add header guards to generated vmlinux.h Add canonical #ifndef/#define/#endif guard for generated vmlinux.h header with __VMLINUX_H__ symbol. __VMLINUX_H__ is also going to play double role of identifying whether vmlinux.h is being used, versus, say, BCC or non-CO-RE libbpf modes with dependency on kernel headers. This will make it possible to write helper macro/functions, agnostic to exact BPF program set up. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200229231112.1240137-2-andriin@fb.com + Changed Files: tools/bpf/bpftool/btf.c | 5 +++++; 1 file changed, 5 insertions(+) + Parent Hashes: 15070919f801348e9a9a2ea96f427d8b621f3cd5 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Added header guards to the generated vmlinux.h in bpftool for better compatibility and identification across BPF setups.", + "keywords": "header guards bpftool vmlinux.h", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Added header guards to the generated vmlinux.h in bpftool for better compatibility and identification across BPF setups.", + "keywords": "header guards bpftool vmlinux.h", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 483/6895 - Commit ID: 9f0ca0c1a50a7de5c71970aa452941199ed210d9 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 9f0ca0c1a50a7de5c71970aa452941199ed210d9 + Author Name: David S. Miller + Author Email: davem@davemloft.net + Commit Date: 1583020415 + Commit Message: + Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next Alexei Starovoitov says: ==================== pull-request: bpf-next 2020-02-28 The following pull-request contains BPF updates for your *net-next* tree. We've added 41 non-merge commits during the last 7 day(s) which contain a total of 49 files changed, 1383 insertions(+), 499 deletions(-). The main changes are: 1) BPF and Real-Time nicely co-exist. 2) bpftool feature improvements. 3) retrieve bpf_sk_storage via INET_DIAG. ==================== Signed-off-by: David S. Miller + Changed Files: nan + Parent Hashes: 9a834f9b04bc5ed2db27eb45b0cc6415ce7c314c 812285fa5ab129e3a55682314bf235f701564310 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges 41 non-merge commits into the net-next tree with BPF updates, including bpftool improvements and bpf_sk_storage retrieval via INET_DIAG.", + "keywords": "BPF,bpftool,INET_DIAG", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges 41 non-merge BPF-related updates into the net-next tree, including bpftool improvements and bpf_sk_storage access enhancement.", + "keywords": "BPF,bpftool,INET_DIAG", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 484/6895 - Commit ID: 812285fa5ab129e3a55682314bf235f701564310 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 812285fa5ab129e3a55682314bf235f701564310 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1582858417 + Commit Message: + Merge branch 'bpf_sk_storage_via_inet_diag' Martin KaFai Lau says: ==================== The bpf_prog can store specific info to a sk by using bpf_sk_storage. In other words, a sk can be extended by a bpf_prog. This series is to support providing bpf_sk_storage data during inet_diag's dump. The primary target is the usage like iproute2's "ss". The first two patches are refactoring works in inet_diag to make adding bpf_sk_storage support easier. The next two patches do the actual work. Please see individual patch for details. v2: - Add commit message for u16 to u32 change in min_dump_alloc in Patch 4 (Song) - Add comment to explain the !skb->len check in __inet_diag_dump in Patch 4. - Do the map->map_type check earlier in Patch 3 for readability. ==================== Signed-off-by: Alexei Starovoitov + Changed Files: nan + Parent Hashes: d7f10df86202273155a9d8f8553bc2ad28e0dd46 085c20cacf2b72991ce1c9d99a5e2f1d9e73bb68 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges bpf_sk_storage support in inet_diag for extended socket information usage like iproute2's \"ss\" command.", + "keywords": "bpf_sk_storage,inet_diag,iproute2", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges bpf_sk_storage support into inet_diag to enhance socket information retrieval like iproute2's ss command.", + "keywords": "bpf_sk_storage,inet_diag,merge", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 485/6895 - Commit ID: 085c20cacf2b72991ce1c9d99a5e2f1d9e73bb68 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 085c20cacf2b72991ce1c9d99a5e2f1d9e73bb68 + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1582858219 + Commit Message: + bpf: inet_diag: Dump bpf_sk_storages in inet_diag_dump() This patch will dump out the bpf_sk_storages of a sk if the request has the INET_DIAG_REQ_SK_BPF_STORAGES nlattr. An array of SK_DIAG_BPF_STORAGE_REQ_MAP_FD can be specified in INET_DIAG_REQ_SK_BPF_STORAGES to select which bpf_sk_storage to dump. If no map_fd is specified, all bpf_sk_storages of a sk will be dumped. bpf_sk_storages can be added to the system at runtime. It is difficult to find a proper static value for cb->min_dump_alloc. This patch learns the nlattr size required to dump the bpf_sk_storages of a sk. If it happens to be the very first nlmsg of a dump and it cannot fit the needed bpf_sk_storages, it will try to expand the skb by "pskb_expand_head()". Instead of expanding it in inet_sk_diag_fill(), it is expanded at a sleepable context in __inet_diag_dump() so __GFP_DIRECT_RECLAIM can be used. In __inet_diag_dump(), it will retry as long as the skb is empty and the cb->min_dump_alloc becomes larger than before. cb->min_dump_alloc is bounded by KMALLOC_MAX_SIZE. The min_dump_alloc is also changed from 'u16' to 'u32' to accommodate a sk that may have a few large bpf_sk_storages. The updated cb->min_dump_alloc will also be used to allocate the skb in the next dump. This logic already exists in netlink_dump(). Here is the sample output of a locally modified 'ss' and it could be made more readable by using BTF later: [root@arch-fb-vm1 ~]# ss --bpf-map-id 14 --bpf-map-id 13 -t6an 'dst [::1]:8989' State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess ESTAB 0 0 [::1]:51072 [::1]:8989 bpf_map_id:14 value:[ 3feb ] bpf_map_id:13 value:[ 3f ] ESTAB 0 0 [::1]:51070 [::1]:8989 bpf_map_id:14 value:[ 3feb ] bpf_map_id:13 value:[ 3f ] [root@arch-fb-vm1 ~]# ~/devshare/github/iproute2/misc/ss --bpf-maps -t6an 'dst [::1]:8989' State Recv-Q Send-Q Local Address:Port Peer Address:Port Process ESTAB 0 0 [::1]:51072 [::1]:8989 bpf_map_id:14 value:[ 3feb ] bpf_map_id:13 value:[ 3f ] bpf_map_id:12 value:[ 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000... total:65407 ] ESTAB 0 0 [::1]:51070 [::1]:8989 bpf_map_id:14 value:[ 3feb ] bpf_map_id:13 value:[ 3f ] bpf_map_id:12 value:[ 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000... total:65407 ] Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200225230427.1976129-1-kafai@fb.com + Changed Files: include/linux/inet_diag.h | 4 +++; include/linux/netlink.h | 4 +--; include/uapi/linux/inet_diag.h | 2 ++; net/ipv4/inet_diag.c | 74 ++++++++++++++++++++++++++++++++++++++++++; 4 files changed, 82 insertions(+), 2 deletions(-) + Parent Hashes: 1ed4d92458a969e71e7914550b6f0c730c14d84e +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Enhances inet_diag functionality to dump bpf_sk_storages when specified in netlink attributes.", + "keywords": "inet_diag,bpf_sk_storages,netlink", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Enhances socket diagnostics to support dumping eBPF storage data via netlink attributes.", + "keywords": "inet_diag,bpf_sk_storages,netlink", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 486/6895 - Commit ID: 1ed4d92458a969e71e7914550b6f0c730c14d84e +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 1ed4d92458a969e71e7914550b6f0c730c14d84e + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1582858219 + Commit Message: + bpf: INET_DIAG support in bpf_sk_storage This patch adds INET_DIAG support to bpf_sk_storage. 1. Although this series adds bpf_sk_storage diag capability to inet sk, bpf_sk_storage is in general applicable to all fullsock. Hence, the bpf_sk_storage logic will operate on SK_DIAG_* nlattr. The caller will pass in its specific nesting nlattr (e.g. INET_DIAG_*) as the argument. 2. The request will be like: INET_DIAG_REQ_SK_BPF_STORAGES (nla_nest) (defined in latter patch) SK_DIAG_BPF_STORAGE_REQ_MAP_FD (nla_put_u32) SK_DIAG_BPF_STORAGE_REQ_MAP_FD (nla_put_u32) ...... Considering there could have multiple bpf_sk_storages in a sk, instead of reusing INET_DIAG_INFO ("ss -i"), the user can select some specific bpf_sk_storage to dump by specifying an array of SK_DIAG_BPF_STORAGE_REQ_MAP_FD. If no SK_DIAG_BPF_STORAGE_REQ_MAP_FD is specified (i.e. an empty INET_DIAG_REQ_SK_BPF_STORAGES), it will dump all bpf_sk_storages of a sk. 3. The reply will be like: INET_DIAG_BPF_SK_STORAGES (nla_nest) (defined in latter patch) SK_DIAG_BPF_STORAGE (nla_nest) SK_DIAG_BPF_STORAGE_MAP_ID (nla_put_u32) SK_DIAG_BPF_STORAGE_MAP_VALUE (nla_reserve_64bit) SK_DIAG_BPF_STORAGE (nla_nest) SK_DIAG_BPF_STORAGE_MAP_ID (nla_put_u32) SK_DIAG_BPF_STORAGE_MAP_VALUE (nla_reserve_64bit) ...... 4. Unlike other INET_DIAG info of a sk which is pretty static, the size required to dump the bpf_sk_storage(s) of a sk is dynamic as the system adding more bpf_sk_storage_map. It is hard to set a static min_dump_alloc size. Hence, this series learns it at the runtime and adjust the cb->min_dump_alloc as it iterates all sk(s) of a system. The "unsigned int *res_diag_size" in bpf_sk_storage_diag_put() is for this purpose. The next patch will update the cb->min_dump_alloc as it iterates the sk(s). Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200225230421.1975729-1-kafai@fb.com + Changed Files: include/linux/bpf.h | 1 +; include/net/bpf_sk_storage.h | 27 ++++; include/uapi/linux/sock_diag.h | 26 ++++; kernel/bpf/syscall.c | 15 +++; net/core/bpf_sk_storage.c | 283 ++++++++++++++++++++++++++++++++++++++++-; 5 files changed, 346 insertions(+), 6 deletions(-) + Parent Hashes: 0df6d32842b9a5f97a29ea90c8adc5cfac38341d +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds INET_DIAG support to bpf_sk_storage, allowing dynamic adjustment of storage dump sizes as it iterates sk(s).", + "keywords": "INET_DIAG,bpf_sk_storage,sock_diag", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds INET_DIAG support for bpf_sk_storage, enabling socket diagnostics for multiple bpf_sk_storages.", + "keywords": "INET_DIAG,bpf_sk_storage,storage", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 487/6895 - Commit ID: 0df6d32842b9a5f97a29ea90c8adc5cfac38341d +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 0df6d32842b9a5f97a29ea90c8adc5cfac38341d + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1582858219 + Commit Message: + inet_diag: Move the INET_DIAG_REQ_BYTECODE nlattr to cb->data The INET_DIAG_REQ_BYTECODE nlattr is currently re-found every time when the "dump()" is re-started. In a latter patch, it will also need to parse the new INET_DIAG_REQ_SK_BPF_STORAGES nlattr to learn the map_fds. Thus, this patch takes this chance to store the parsed nlattr in cb->data during the "start" time of a dump. By doing this, the "bc" argument also becomes unnecessary and is removed. Also, the two copies of the INET_DIAG_REQ_BYTECODE parsing-audit logic between compat/current version can be consolidated to one. Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200225230415.1975555-1-kafai@fb.com + Changed Files: include/linux/inet_diag.h | 11 ++--; include/uapi/linux/inet_diag.h | 3 +-; net/dccp/diag.c | 4 +-; net/ipv4/inet_diag.c | 117 ++++++++++++++++++++++++-----------------; net/ipv4/raw_diag.c | 6 ++-; net/ipv4/tcp_diag.c | 4 +-; net/ipv4/udp_diag.c | 15 +++---; net/sctp/diag.c | 2 +-; 8 files changed, 98 insertions(+), 64 deletions(-) + Parent Hashes: 5682d393b40e1fe7426a7b8c3471f05262f42010 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit optimizes data handling in INET_DIAG by moving nlattr processing to cb->data during dump initialization.", + "keywords": "INET_DIAG,nlattr,cb->data", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here." + ] +} +Rethinking... +new content: +{ + "summary": "The commit optimizes INET_DIAG by storing parsed nlattr in cb->data during dump initialization.", + "keywords": "INET_DIAG,nlattr,cb->data", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here." + ] +} +-------------------- +-------------------- +Processing Commit 488/6895 - Commit ID: 5682d393b40e1fe7426a7b8c3471f05262f42010 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 5682d393b40e1fe7426a7b8c3471f05262f42010 + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1582858219 + Commit Message: + inet_diag: Refactor inet_sk_diag_fill(), dump(), and dump_one() In a latter patch, there is a need to update "cb->min_dump_alloc" in inet_sk_diag_fill() as it learns the diffierent bpf_sk_storages stored in a sk while dumping all sk(s) (e.g. tcp_hashinfo). The inet_sk_diag_fill() currently does not take the "cb" as an argument. One of the reason is inet_sk_diag_fill() is used by both dump_one() and dump() (which belong to the "struct inet_diag_handler". The dump_one() interface does not pass the "cb" along. This patch is to make dump_one() pass a "cb". The "cb" is created in inet_diag_cmd_exact(). The "nlh" and "in_skb" are stored in "cb" as the dump() interface does. The total number of args in inet_sk_diag_fill() is also cut from 10 to 7 and that helps many callers to pass fewer args. In particular, "struct user_namespace *user_ns", "u32 pid", and "u32 seq" can be replaced by accessing "cb->nlh" and "cb->skb". A similar argument reduction is also made to inet_twsk_diag_fill() and inet_req_diag_fill(). inet_csk_diag_dump() and inet_csk_diag_fill() are also removed. They are mostly equivalent to inet_sk_diag_fill(). Their repeated usages are very limited. Thus, inet_sk_diag_fill() is directly used in those occasions. Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200225230409.1975173-1-kafai@fb.com + Changed Files: include/linux/inet_diag.h | 12 ++---; net/dccp/diag.c | 5 +-; net/ipv4/inet_diag.c | 116 ++++++++++++++++++----------------------------; net/ipv4/raw_diag.c | 18 +++----; net/ipv4/tcp_diag.c | 4 +-; net/ipv4/udp_diag.c | 26 +++++------; net/sctp/diag.c | 5 +-; 7 files changed, 73 insertions(+), 113 deletions(-) + Parent Hashes: d7f10df86202273155a9d8f8553bc2ad28e0dd46 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Refactor inet_sk_diag_fill() and related functions to pass fewer arguments and improve code clarity.", + "keywords": "refactor, inet_sk_diag_fill, arguments", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +Rethinking... +new content: +{ + "summary": "Refactor inet_diag related functions to streamline argument passing and improve maintainability.", + "keywords": "refactor, inet_diag, maintainability", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +-------------------- +-------------------- +Processing Commit 489/6895 - Commit ID: d7f10df86202273155a9d8f8553bc2ad28e0dd46 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: d7f10df86202273155a9d8f8553bc2ad28e0dd46 + Author Name: Gustavo A. R. Silva + Author Email: gustavo@embeddedor.com + Commit Date: 1582849262 + Commit Message: + bpf: Replace zero-length array with flexible-array member The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva Signed-off-by: Daniel Borkmann Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200227001744.GA3317@embeddedor + Changed Files: include/linux/bpf-cgroup.h | 2 +-; include/linux/bpf.h | 2 +-; include/uapi/linux/bpf.h | 2 +-; kernel/bpf/bpf_struct_ops.c | 2 +-; kernel/bpf/hashtab.c | 2 +-; kernel/bpf/lpm_trie.c | 2 +-; 6 files changed, 6 insertions(+), 6 deletions(-) + Parent Hashes: 4bc988464bb193d67c93ddb2fcd1de127d815b6c +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit replaces zero-length arrays with flexible-array members in various bpf-related structures for improved safety and compliance with C99 standards.", + "keywords": "flexible-array, zero-length, C99", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit replaces zero-length arrays with flexible-array members in bpf-related structures for better safety and C99 compliance.", + "keywords": "flexible-array, zero-length, C99", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 490/6895 - Commit ID: 1eb1f43a6e37282348a41e3d68f5e9a6a4359212 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 1eb1f43a6e37282348a41e3d68f5e9a6a4359212 + Author Name: Taehee Yoo + Author Email: ap420073@gmail.com + Commit Date: 1582832707 + Commit Message: + net: rmnet: fix NULL pointer dereference in rmnet_changelink() In the rmnet_changelink(), it uses IFLA_LINK without checking NULL pointer. tb[IFLA_LINK] could be NULL pointer. So, NULL-ptr-deref could occur. rmnet already has a lower interface (real_dev). So, after this patch, rmnet_changelink() does not use IFLA_LINK anymore. Test commands: modprobe rmnet ip link add dummy0 type dummy ip link add rmnet0 link dummy0 type rmnet mux_id 1 ip link set rmnet0 type rmnet mux_id 2 Splat looks like: [ 90.578726][ T1131] general protection fault, probably for non-canonical address 0xdffffc0000000000I [ 90.581121][ T1131] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] [ 90.582380][ T1131] CPU: 2 PID: 1131 Comm: ip Not tainted 5.6.0-rc1+ #447 [ 90.584285][ T1131] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 90.587506][ T1131] RIP: 0010:rmnet_changelink+0x5a/0x8a0 [rmnet] [ 90.588546][ T1131] Code: 83 ec 20 48 c1 ea 03 80 3c 02 00 0f 85 6f 07 00 00 48 8b 5e 28 48 b8 00 00 00 00 00 0 [ 90.591447][ T1131] RSP: 0018:ffff8880ce78f1b8 EFLAGS: 00010247 [ 90.592329][ T1131] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffff8880ce78f8b0 [ 90.593253][ T1131] RDX: 0000000000000000 RSI: ffff8880ce78f4a0 RDI: 0000000000000004 [ 90.594058][ T1131] RBP: ffff8880cf543e00 R08: 0000000000000002 R09: 0000000000000002 [ 90.594859][ T1131] R10: ffffffffc0586a40 R11: 0000000000000000 R12: ffff8880ca47c000 [ 90.595690][ T1131] R13: ffff8880ca47c000 R14: ffff8880cf545000 R15: 0000000000000000 [ 90.596553][ T1131] FS: 00007f21f6c7e0c0(0000) GS:ffff8880da400000(0000) knlGS:0000000000000000 [ 90.597504][ T1131] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 90.599418][ T1131] CR2: 0000556e413db458 CR3: 00000000c917a002 CR4: 00000000000606e0 [ 90.600289][ T1131] Call Trace: [ 90.600631][ T1131] __rtnl_newlink+0x922/0x1270 [ 90.601194][ T1131] ? lock_downgrade+0x6e0/0x6e0 [ 90.601724][ T1131] ? rtnl_link_unregister+0x220/0x220 [ 90.602309][ T1131] ? lock_acquire+0x164/0x3b0 [ 90.602784][ T1131] ? is_bpf_image_address+0xff/0x1d0 [ 90.603331][ T1131] ? rtnl_newlink+0x4c/0x90 [ 90.603810][ T1131] ? kernel_text_address+0x111/0x140 [ 90.604419][ T1131] ? __kernel_text_address+0xe/0x30 [ 90.604981][ T1131] ? unwind_get_return_address+0x5f/0xa0 [ 90.605616][ T1131] ? create_prof_cpu_mask+0x20/0x20 [ 90.606304][ T1131] ? arch_stack_walk+0x83/0xb0 [ 90.606985][ T1131] ? stack_trace_save+0x82/0xb0 [ 90.607656][ T1131] ? stack_trace_consume_entry+0x160/0x160 [ 90.608503][ T1131] ? deactivate_slab.isra.78+0x2c5/0x800 [ 90.609336][ T1131] ? kasan_unpoison_shadow+0x30/0x40 [ 90.610096][ T1131] ? kmem_cache_alloc_trace+0x135/0x350 [ 90.610889][ T1131] ? rtnl_newlink+0x4c/0x90 [ 90.611512][ T1131] rtnl_newlink+0x65/0x90 [ ... ] Fixes: 23790ef12082 ("net: qualcomm: rmnet: Allow to configure flags for existing devices") Signed-off-by: Taehee Yoo Signed-off-by: David S. Miller + Changed Files: drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c | 6 ++----; 1 file changed, 2 insertions(+), 4 deletions(-) + Parent Hashes: 93b5cbfa9636d385126f211dca9efa7e3f683202 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes a null pointer dereference in the rmnet_changelink function by avoiding the use of IFLA_LINK.", + "keywords": "rmnet,NULL,pointer", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes a null pointer dereference in the rmnet_changelink function by avoiding the use of IFLA_LINK.", + "keywords": "rmnet,NULL,pointer", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +-------------------- +-------------------- +Processing Commit 491/6895 - Commit ID: 93b5cbfa9636d385126f211dca9efa7e3f683202 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 93b5cbfa9636d385126f211dca9efa7e3f683202 + Author Name: Taehee Yoo + Author Email: ap420073@gmail.com + Commit Date: 1582832707 + Commit Message: + net: rmnet: fix NULL pointer dereference in rmnet_newlink() rmnet registers IFLA_LINK interface as a lower interface. But, IFLA_LINK could be NULL. In the current code, rmnet doesn't check IFLA_LINK. So, panic would occur. Test commands: modprobe rmnet ip link add rmnet0 type rmnet mux_id 1 Splat looks like: [ 36.826109][ T1115] general protection fault, probably for non-canonical address 0xdffffc0000000000I [ 36.838817][ T1115] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] [ 36.839908][ T1115] CPU: 1 PID: 1115 Comm: ip Not tainted 5.6.0-rc1+ #447 [ 36.840569][ T1115] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 36.841408][ T1115] RIP: 0010:rmnet_newlink+0x54/0x510 [rmnet] [ 36.841986][ T1115] Code: 83 ec 18 48 c1 e9 03 80 3c 01 00 0f 85 d4 03 00 00 48 8b 6a 28 48 b8 00 00 00 00 00 c [ 36.843923][ T1115] RSP: 0018:ffff8880b7e0f1c0 EFLAGS: 00010247 [ 36.844756][ T1115] RAX: dffffc0000000000 RBX: ffff8880d14cca00 RCX: 1ffff11016fc1e99 [ 36.845859][ T1115] RDX: 0000000000000000 RSI: ffff8880c3d04000 RDI: 0000000000000004 [ 36.846961][ T1115] RBP: 0000000000000000 R08: ffff8880b7e0f8b0 R09: ffff8880b6ac2d90 [ 36.848020][ T1115] R10: ffffffffc0589a40 R11: ffffed1016d585b7 R12: ffffffff88ceaf80 [ 36.848788][ T1115] R13: ffff8880c3d04000 R14: ffff8880b7e0f8b0 R15: ffff8880c3d04000 [ 36.849546][ T1115] FS: 00007f50ab3360c0(0000) GS:ffff8880da000000(0000) knlGS:0000000000000000 [ 36.851784][ T1115] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 36.852422][ T1115] CR2: 000055871afe5ab0 CR3: 00000000ae246001 CR4: 00000000000606e0 [ 36.853181][ T1115] Call Trace: [ 36.853514][ T1115] __rtnl_newlink+0xbdb/0x1270 [ 36.853967][ T1115] ? lock_downgrade+0x6e0/0x6e0 [ 36.854420][ T1115] ? rtnl_link_unregister+0x220/0x220 [ 36.854936][ T1115] ? lock_acquire+0x164/0x3b0 [ 36.855376][ T1115] ? is_bpf_image_address+0xff/0x1d0 [ 36.855884][ T1115] ? rtnl_newlink+0x4c/0x90 [ 36.856304][ T1115] ? kernel_text_address+0x111/0x140 [ 36.856857][ T1115] ? __kernel_text_address+0xe/0x30 [ 36.857440][ T1115] ? unwind_get_return_address+0x5f/0xa0 [ 36.858063][ T1115] ? create_prof_cpu_mask+0x20/0x20 [ 36.858644][ T1115] ? arch_stack_walk+0x83/0xb0 [ 36.859171][ T1115] ? stack_trace_save+0x82/0xb0 [ 36.859710][ T1115] ? stack_trace_consume_entry+0x160/0x160 [ 36.860357][ T1115] ? deactivate_slab.isra.78+0x2c5/0x800 [ 36.860928][ T1115] ? kasan_unpoison_shadow+0x30/0x40 [ 36.861520][ T1115] ? kmem_cache_alloc_trace+0x135/0x350 [ 36.862125][ T1115] ? rtnl_newlink+0x4c/0x90 [ 36.864073][ T1115] rtnl_newlink+0x65/0x90 [ ... ] Fixes: ceed73a2cf4a ("drivers: net: ethernet: qualcomm: rmnet: Initial implementation") Signed-off-by: Taehee Yoo Signed-off-by: David S. Miller + Changed Files: drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c | 5 +++++; 1 file changed, 5 insertions(+) + Parent Hashes: b82cf17ff1957ec35eaee7dc519c365ecd06ba38 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes a NULL pointer dereference issue in the rmnet_newlink function within the Qualcomm Ethernet driver.", + "keywords": "NULL pointer, rmnet_newlink, fix", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes a NULL pointer dereference issue in the rmnet_newlink function within the Qualcomm Ethernet driver.", + "keywords": "NULL pointer, rmnet_newlink, fix", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +-------------------- +-------------------- +Processing Commit 492/6895 - Commit ID: b6f6118901d1e867ac9177bbff3b00b185bd4fdc +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: b6f6118901d1e867ac9177bbff3b00b185bd4fdc + Author Name: Eric Dumazet + Author Email: edumazet@google.com + Commit Date: 1582777258 + Commit Message: + ipv6: restrict IPV6_ADDRFORM operation IPV6_ADDRFORM is able to transform IPv6 socket to IPv4 one. While this operation sounds illogical, we have to support it. One of the things it does for TCP socket is to switch sk->sk_prot to tcp_prot. We now have other layers playing with sk->sk_prot, so we should make sure to not interfere with them. This patch makes sure sk_prot is the default pointer for TCP IPv6 socket. syzbot reported : BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD a0113067 P4D a0113067 PUD a8771067 PMD 0 Oops: 0010 [#1] PREEMPT SMP KASAN CPU: 0 PID: 10686 Comm: syz-executor.0 Not tainted 5.6.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:0x0 Code: Bad RIP value. RSP: 0018:ffffc9000281fce0 EFLAGS: 00010246 RAX: 1ffffffff15f48ac RBX: ffffffff8afa4560 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8880a69a8f40 RBP: ffffc9000281fd10 R08: ffffffff86ed9b0c R09: ffffed1014d351f5 R10: ffffed1014d351f5 R11: 0000000000000000 R12: ffff8880920d3098 R13: 1ffff1101241a613 R14: ffff8880a69a8f40 R15: 0000000000000000 FS: 00007f2ae75db700(0000) GS:ffff8880aea00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 00000000a3b85000 CR4: 00000000001406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: inet_release+0x165/0x1c0 net/ipv4/af_inet.c:427 __sock_release net/socket.c:605 [inline] sock_close+0xe1/0x260 net/socket.c:1283 __fput+0x2e4/0x740 fs/file_table.c:280 ____fput+0x15/0x20 fs/file_table.c:313 task_work_run+0x176/0x1b0 kernel/task_work.c:113 tracehook_notify_resume include/linux/tracehook.h:188 [inline] exit_to_usermode_loop arch/x86/entry/common.c:164 [inline] prepare_exit_to_usermode+0x480/0x5b0 arch/x86/entry/common.c:195 syscall_return_slowpath+0x113/0x4a0 arch/x86/entry/common.c:278 do_syscall_64+0x11f/0x1c0 arch/x86/entry/common.c:304 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x45c429 Code: ad b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f2ae75dac78 EFLAGS: 00000246 ORIG_RAX: 0000000000000036 RAX: 0000000000000000 RBX: 00007f2ae75db6d4 RCX: 000000000045c429 RDX: 0000000000000001 RSI: 000000000000011a RDI: 0000000000000004 RBP: 000000000076bf20 R08: 0000000000000038 R09: 0000000000000000 R10: 0000000020000180 R11: 0000000000000246 R12: 00000000ffffffff R13: 0000000000000a9d R14: 00000000004ccfb4 R15: 000000000076bf2c Modules linked in: CR2: 0000000000000000 ---[ end trace 82567b5207e87bae ]--- RIP: 0010:0x0 Code: Bad RIP value. RSP: 0018:ffffc9000281fce0 EFLAGS: 00010246 RAX: 1ffffffff15f48ac RBX: ffffffff8afa4560 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8880a69a8f40 RBP: ffffc9000281fd10 R08: ffffffff86ed9b0c R09: ffffed1014d351f5 R10: ffffed1014d351f5 R11: 0000000000000000 R12: ffff8880920d3098 R13: 1ffff1101241a613 R14: ffff8880a69a8f40 R15: 0000000000000000 FS: 00007f2ae75db700(0000) GS:ffff8880aea00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 00000000a3b85000 CR4: 00000000001406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface") Signed-off-by: Eric Dumazet Reported-by: syzbot+1938db17e275e85dc328@syzkaller.appspotmail.com Cc: Daniel Borkmann Signed-off-by: David S. Miller + Changed Files: net/ipv6/ipv6_sockglue.c | 10 ++++++++--; 1 file changed, 8 insertions(+), 2 deletions(-) + Parent Hashes: 51e3dfa8906ace90c809235b3d3afebc166b6433 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fix ensures IPv6 socket default protocol assignment does not interfere with TCP layer changes.", + "keywords": "IPv6,TCP,sk_prot", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +Rethinking... +new content: +{ + "summary": "Fix addresses kernel null pointer dereference issue in IPv6 to IPv4 socket transformation.", + "keywords": "IPv6,TCP,sk_prot", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +-------------------- +-------------------- +Processing Commit 493/6895 - Commit ID: 4bc988464bb193d67c93ddb2fcd1de127d815b6c +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 4bc988464bb193d67c93ddb2fcd1de127d815b6c + Author Name: Daniel Borkmann + Author Email: daniel@iogearbox.net + Commit Date: 1582738479 + Commit Message: + Merge branch 'bpf-bpftool-probes' Michal Rostecki says: ==================== Feature probes in bpftool related to bpf_probe_write_user and bpf_trace_printk helpers emit dmesg warnings which might be confusing for people running bpftool on production environments. This patch series addresses that by filtering them out by default and introducing the new positional argument "full" which enables all available probes. The main motivation behind those changes is ability the fact that some probes (for example those related to "trace" or "write_user" helpers) emit dmesg messages which might be confusing for people who are running on production environments. For details see the Cilium issue[0]. v1 -> v2: - Do not expose regex filters to users, keep filtering logic internal, expose only the "full" option for including probes which emit dmesg warnings. v2 -> v3: - Do not use regex for filtering out probes, use function IDs directly. - Fix bash completion - in v2 only "prefix" was proposed after "macros", "dev" and "kernel" were not. - Rephrase the man page paragraph, highlight helper function names. - Remove tests which parse the plain output of bpftool (except the header/macros test), focus on testing JSON output instead. - Add test which compares the output with and without "full" option. v3 -> v4: - Use enum to check for helper functions. - Make selftests compatible with older versions of Python 3.x than 3.7. [0] https://github.com/cilium/cilium/issues/10048 ==================== Signed-off-by: Daniel Borkmann + Changed Files: nan + Parent Hashes: 3494bec0f6ac8ac06e0ad7c35933db345b2c5a83 736332740e295d9b6fc524f0447448f6089911d9 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit merges changes to bpftool to filter dmesg warnings by default, streamlining testing and introducing a \"full\" option to include all probes.", + "keywords": "bpftool, probes, warnings", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit merges improvements to bpftool to handle dmesg warnings with a new \"full\" option and update tests accordingly.", + "keywords": "bpftool, probes, dmesg", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 494/6895 - Commit ID: 736332740e295d9b6fc524f0447448f6089911d9 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 736332740e295d9b6fc524f0447448f6089911d9 + Author Name: Michal Rostecki + Author Email: mrostecki@opensuse.org + Commit Date: 1582738474 + Commit Message: + selftests/bpf: Add test for "bpftool feature" command Add Python module with tests for "bpftool feature" command, which mainly checks whether the "full" option is working properly. Signed-off-by: Michal Rostecki Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200226165941.6379-6-mrostecki@opensuse.org + Changed Files: tools/testing/selftests/.gitignore | 5 +-; tools/testing/selftests/bpf/Makefile | 3 +-; tools/testing/selftests/bpf/test_bpftool.py | 178 ++++++++++++++++++++++++++++; tools/testing/selftests/bpf/test_bpftool.sh | 5 +; 4 files changed, 189 insertions(+), 2 deletions(-) + Parent Hashes: ad92b12a6e0ebfb6d32693f374ac8572f527c0c1 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds a Python test module to validate the \"bpftool feature\" command's functionality.", + "keywords": "selftests, bpftool, feature", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds tests for the \"bpftool feature\" command to ensure the correct functionality of its options.", + "keywords": "bpftool, feature, tests", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 495/6895 - Commit ID: ad92b12a6e0ebfb6d32693f374ac8572f527c0c1 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: ad92b12a6e0ebfb6d32693f374ac8572f527c0c1 + Author Name: Michal Rostecki + Author Email: mrostecki@opensuse.org + Commit Date: 1582738474 + Commit Message: + bpftool: Update bash completion for "bpftool feature" command Update bash completion for "bpftool feature" command with the new argument: "full". Signed-off-by: Michal Rostecki Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200226165941.6379-5-mrostecki@opensuse.org + Changed Files: tools/bpf/bpftool/bash-completion/bpftool | 3 ++-; 1 file changed, 2 insertions(+), 1 deletion(-) + Parent Hashes: bcdacab6e70cf90bf3d8db94ae9226ff5117a61e +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit updates bash completion for the \"bpftool feature\" command by adding a new argument \"full\".", + "keywords": "bash completion, bpftool, feature", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit updates bash completion for the \"bpftool feature\" command by adding a new argument \"full\".", + "keywords": "bash completion,bpftool,feature", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 496/6895 - Commit ID: bcdacab6e70cf90bf3d8db94ae9226ff5117a61e +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: bcdacab6e70cf90bf3d8db94ae9226ff5117a61e + Author Name: Michal Rostecki + Author Email: mrostecki@opensuse.org + Commit Date: 1582738474 + Commit Message: + bpftool: Update documentation of "bpftool feature" command Update documentation of "bpftool feature" command with information about new arguments: "full". Signed-off-by: Michal Rostecki Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200226165941.6379-4-mrostecki@opensuse.org + Changed Files: tools/bpf/bpftool/Documentation/bpftool-feature.rst | 19 ++++++++++---------; 1 file changed, 10 insertions(+), 9 deletions(-) + Parent Hashes: 368cb0e7cdb5e67ad8c0cd52f1d71341c42a7e4b +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit updates the bpftool feature command documentation with new argument information.", + "keywords": "bpftool,documentation,update", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit updates the bpftool feature command documentation with new argument information.", + "keywords": "bpftool,documentation,update", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 497/6895 - Commit ID: 368cb0e7cdb5e67ad8c0cd52f1d71341c42a7e4b +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 368cb0e7cdb5e67ad8c0cd52f1d71341c42a7e4b + Author Name: Michal Rostecki + Author Email: mrostecki@opensuse.org + Commit Date: 1582738474 + Commit Message: + bpftool: Make probes which emit dmesg warnings optional Probes related to bpf_probe_write_user and bpf_trace_printk helpers emit dmesg warnings which might be confusing for people running bpftool on production environments. This change filters them out by default and introduces the new positional argument "full" which enables all available probes. Signed-off-by: Michal Rostecki Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200226165941.6379-3-mrostecki@opensuse.org + Changed Files: tools/bpf/bpftool/feature.c | 70 +++++++++++++++++++++++++++++++--------------; 1 file changed, 49 insertions(+), 21 deletions(-) + Parent Hashes: 6b52ca44e8af2c508ffbcd03261cf849a740756a +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit makes certain bpftool probes that emit dmesg warnings optional by introducing a positional argument \"full\" to enable all probes.", + "keywords": "bpftool, probes, warnings", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit makes certain bpftool probes that emit dmesg warnings optional by introducing a positional argument \"full\" to enable all probes.", + "keywords": "bpftool, probes, warnings", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 498/6895 - Commit ID: 6b52ca44e8af2c508ffbcd03261cf849a740756a +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 6b52ca44e8af2c508ffbcd03261cf849a740756a + Author Name: Michal Rostecki + Author Email: mrostecki@opensuse.org + Commit Date: 1582738474 + Commit Message: + bpftool: Move out sections to separate functions Remove all calls of print_end_then_start_section function and for loops out from the do_probe function. Instead, provide separate functions for each section (like i.e. section_helpers) which are called in do_probe. This change is motivated by better readability. Signed-off-by: Michal Rostecki Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200226165941.6379-2-mrostecki@opensuse.org + Changed Files: tools/bpf/bpftool/feature.c | 219 +++++++++++++++++++++++++-------------------; 1 file changed, 126 insertions(+), 93 deletions(-) + Parent Hashes: 3494bec0f6ac8ac06e0ad7c35933db345b2c5a83 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit refactors bpftool code by moving section logic into separate functions for improved readability.", + "keywords": "bpftool, refactor, readability", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit refactors bpftool code by moving section logic into separate functions for better readability.", + "keywords": "bpftool, refactor, readability", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 499/6895 - Commit ID: 3494bec0f6ac8ac06e0ad7c35933db345b2c5a83 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 3494bec0f6ac8ac06e0ad7c35933db345b2c5a83 + Author Name: Andrey Ignatov + Author Email: rdna@fb.com + Commit Date: 1582731653 + Commit Message: + bpftool: Support struct_ops, tracing, ext prog types Add support for prog types that were added to kernel but not present in bpftool yet: struct_ops, tracing, ext prog types and corresponding section names. Before: # bpftool p l ... 184: type 26 name test_subprog3 tag dda135a7dc0daf54 gpl loaded_at 2020-02-25T13:28:33-0800 uid 0 xlated 112B jited 103B memlock 4096B map_ids 136 btf_id 85 185: type 28 name new_get_skb_len tag d2de5b87d8e5dc49 gpl loaded_at 2020-02-25T13:28:33-0800 uid 0 xlated 72B jited 69B memlock 4096B map_ids 136 btf_id 85 After: # bpftool p l ... 184: tracing name test_subprog3 tag dda135a7dc0daf54 gpl loaded_at 2020-02-25T13:28:33-0800 uid 0 xlated 112B jited 103B memlock 4096B map_ids 136 btf_id 85 185: ext name new_get_skb_len tag d2de5b87d8e5dc49 gpl loaded_at 2020-02-25T13:28:33-0800 uid 0 xlated 72B jited 69B memlock 4096B map_ids 136 btf_id 85 Signed-off-by: Andrey Ignatov Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200225223441.689109-1-rdna@fb.com + Changed Files: tools/bpf/bpftool/Documentation/bpftool-prog.rst | 3 ++-; tools/bpf/bpftool/bash-completion/bpftool | 3 ++-; tools/bpf/bpftool/main.h | 3 +++; tools/bpf/bpftool/prog.c | 4 ++--; 4 files changed, 9 insertions(+), 4 deletions(-) + Parent Hashes: 3cd046f182aab72b922e35461b204a2b52587946 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds support for struct_ops, tracing, and ext prog types in bpftool.", + "keywords": "struct_ops,bpftool,tracing", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds support for struct_ops, tracing, and ext prog types in bpftool.", + "keywords": "struct_ops,tracing,bpftool", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 500/6895 - Commit ID: 3cd046f182aab72b922e35461b204a2b52587946 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 3cd046f182aab72b922e35461b204a2b52587946 + Author Name: Scott Branden + Author Email: scott.branden@broadcom.com + Commit Date: 1582728141 + Commit Message: + scripts/bpf: Switch to more portable python3 shebang Change "/usr/bin/python3" to "/usr/bin/env python3" for more portable solution in bpf_helpers_doc.py. Signed-off-by: Scott Branden Signed-off-by: Daniel Borkmann Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200225205426.6975-1-scott.branden@broadcom.com + Changed Files: scripts/bpf_helpers_doc.py | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: 503d539a6e417b018616bf3060e0b5814fafce47 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit updates the shebang in bpf_helpers_doc.py to use a more portable Python 3 solution.", + "keywords": "shebang, python3, portable", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here." + ] +} +Rethinking... +new content: +{ + "summary": "The commit updates the Python3 shebang in bpf_helpers_doc.py for better portability.", + "keywords": "shebang, python3, portability", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 501/6895 - Commit ID: 4c45945aa418f5e2f31cdaf0b1484e146e29f72f +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 4c45945aa418f5e2f31cdaf0b1484e146e29f72f + Author Name: Ingo Molnar + Author Email: mingo@kernel.org + Commit Date: 1582726685 + Commit Message: + Merge tag 'perf-urgent-for-mingo-5.6-20200220' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent Pull perf/urgent fixes from Arnaldo Carvalho de Melo: auxtrace: Adrian Hunter: - Fix endless record after being terminated on arm-spe. Wei Li: - Fix endless record after being terminated on Intel PT and BTS and on ARM's cs-etm. perf test: Thomas Richter - Fix test trace+probe_vfs_getname.sh on s390 PowerPC: Arnaldo Carvalho de Melo: - Sync powerpc syscall.tbl with the kernel sources. BPF: Arnaldo Carvalho de Melo: - Remove extraneous bpf/ subdir from bpf.h headers used to build bpf events. Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Ingo Molnar + Changed Files: nan + Parent Hashes: c5f86891185c408b2241ba9a82ae8622d8386aff b103de53e09f20d645eb313477f52d1993347605 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Merge commit fixing perf/urgent issues including BPF header path correction.", + "keywords": "perf, merge, BPF", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "Merge commit addressing perf/urgent fixes including BPF header path adjustment.", + "keywords": "perf, merge, fixes", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 502/6895 - Commit ID: 503d539a6e417b018616bf3060e0b5814fafce47 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 503d539a6e417b018616bf3060e0b5814fafce47 + Author Name: Yuya Kusakabe + Author Email: yuya.kusakabe@gmail.com + Commit Date: 1582667455 + Commit Message: + virtio_net: Add XDP meta data support Implement support for transferring XDP meta data into skb for virtio_net driver; before calling into the program, xdp.data_meta points to xdp.data, where on program return with pass verdict, we call into skb_metadata_set(). Tested with the script at https://github.com/higebu/virtio_net-xdp-metadata-test. Signed-off-by: Yuya Kusakabe Signed-off-by: Daniel Borkmann Acked-by: Jason Wang Acked-by: Michael S. Tsirkin Link: https://lore.kernel.org/bpf/20200225033212.437563-2-yuya.kusakabe@gmail.com + Changed Files: drivers/net/virtio_net.c | 52 +++++++++++++++++++++++++++++-------------------; 1 file changed, 32 insertions(+), 20 deletions(-) + Parent Hashes: f1d4884d6871ded0592604b0e72e4a7bd292eab9 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds support for XDP metadata handling in the virtio_net driver, enabling metadata transfer to skb within the XDP framework.", + "keywords": "XDP,metadata,virtio_net", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds support for XDP metadata handling in the virtio_net driver, enabling metadata transfer to skb within the XDP framework.", + "keywords": "XDP,metadata,virtio_net", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +-------------------- +-------------------- +Processing Commit 503/6895 - Commit ID: f1d4884d6871ded0592604b0e72e4a7bd292eab9 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: f1d4884d6871ded0592604b0e72e4a7bd292eab9 + Author Name: Yuya Kusakabe + Author Email: yuya.kusakabe@gmail.com + Commit Date: 1582667455 + Commit Message: + virtio_net: Keep vnet header zeroed if XDP is loaded for small buffer We do not want to care about the vnet header in receive_small() if XDP is loaded, since we can not know whether or not the packet is modified by XDP. Fixes: f6b10209b90d ("virtio-net: switch to use build_skb() for small buffer") Signed-off-by: Yuya Kusakabe Signed-off-by: Daniel Borkmann Acked-by: Jason Wang Acked-by: Michael S. Tsirkin Link: https://lore.kernel.org/bpf/20200225033212.437563-1-yuya.kusakabe@gmail.com + Changed Files: drivers/net/virtio_net.c | 4 ++--; 1 file changed, 2 insertions(+), 2 deletions(-) + Parent Hashes: 9fb156bb82a33f01708fbbb8828836a4219efc3d +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit ensures the vnet header remains zeroed when XDP is loaded in virtio_net for small buffer to handle potential packet modifications by XDP.", + "keywords": "vnet header,XDP,virtio_net", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +Rethinking... +new content: +{ + "summary": "The commit ensures the vnet header remains zeroed when XDP is loaded in virtio_net for small buffer to handle potential packet modifications by XDP.", + "keywords": "vnet header,XDP,virtio_net", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +-------------------- +-------------------- +Processing Commit 504/6895 - Commit ID: 9fb156bb82a33f01708fbbb8828836a4219efc3d +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 9fb156bb82a33f01708fbbb8828836a4219efc3d + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1582666982 + Commit Message: + selftests/bpf: Print backtrace on SIGSEGV in test_progs Due to various bugs in tests clean up code (usually), if host system is misconfigured, it happens that test_progs will just crash in the middle of running a test with little to no indication of where and why the crash happened. For cases where coredump is not readily available (e.g., inside a CI), it's very helpful to have a stack trace, which lead to crash, to be printed out. This change adds a signal handler that will capture and print out symbolized backtrace: $ sudo ./test_progs -t mmap test_mmap:PASS:skel_open_and_load 0 nsec test_mmap:PASS:bss_mmap 0 nsec test_mmap:PASS:data_mmap 0 nsec Caught signal #11! Stack trace: ./test_progs(crash_handler+0x18)[0x42a888] /lib64/libpthread.so.0(+0xf5d0)[0x7f2aab5175d0] ./test_progs(test_mmap+0x3c0)[0x41f0a0] ./test_progs(main+0x160)[0x407d10] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7f2aab15d3d5] ./test_progs[0x407ebc] [1] 1988412 segmentation fault (core dumped) sudo ./test_progs -t mmap Unfortunately, glibc's symbolization support is unable to symbolize static functions, only global ones will be present in stack trace. But it's still a step forward without adding extra libraries to get a better symbolization. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200225000847.3965188-1-andriin@fb.com + Changed Files: tools/testing/selftests/bpf/Makefile | 2 +-; tools/testing/selftests/bpf/test_progs.c | 25 +++++++++++++++++++++++++; 2 files changed, 26 insertions(+), 1 deletion(-) + Parent Hashes: e0360423d0204eb22f97ed89ba56da496bb9a094 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Add signal handler to print stack trace on test_progs SIGSEGV for better debugging.", + "keywords": "SIGSEGV,backtrace,selftests", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Add signal handler to print stack trace on test_progs SEGFAULT for debugging.", + "keywords": "signal,backtrace,selftests", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 505/6895 - Commit ID: e0360423d0204eb22f97ed89ba56da496bb9a094 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: e0360423d0204eb22f97ed89ba56da496bb9a094 + Author Name: Jakub Sitnicki + Author Email: jakub@cloudflare.com + Commit Date: 1582590916 + Commit Message: + selftests/bpf: Run SYN cookies with reuseport BPF test only for TCP Currently we run SYN cookies test for all socket types and mark the test as skipped if socket type is not compatible. This causes confusion because skipped test might indicate a problem with the testing environment. Instead, run the test only for the socket type which supports SYN cookies. Also, switch to using designated initializers when setting up tests, so that we can tweak only some test parameters, leaving the rest initialized to default values. Fixes: eecd618b4516 ("selftests/bpf: Mark SYN cookie test skipped for UDP sockets") Reported-by: Alexei Starovoitov Signed-off-by: Jakub Sitnicki Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200224135327.121542-2-jakub@cloudflare.com + Changed Files: .../testing/selftests/bpf/prog_tests/select_reuseport.c | 17 +++++++++--------; 1 file changed, 9 insertions(+), 8 deletions(-) + Parent Hashes: 779e422d11985e408fc148f0cca0f4b403f6c5fa +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Adjusts SYN cookies test in selftests to run for TCP only and improves test initialization.", + "keywords": "SYN,cookies,tests", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "Adjusts SYN cookies test in selftests to run exclusively for supported TCP socket type and refines test setup.", + "keywords": "SYN,cookies,test", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 506/6895 - Commit ID: 779e422d11985e408fc148f0cca0f4b403f6c5fa +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 779e422d11985e408fc148f0cca0f4b403f6c5fa + Author Name: Jakub Sitnicki + Author Email: jakub@cloudflare.com + Commit Date: 1582590916 + Commit Message: + selftests/bpf: Run reuseport tests only with supported socket types SOCKMAP and SOCKHASH map types can be used with reuseport BPF programs but don't support yet storing UDP sockets. Instead of marking UDP tests with SOCK{MAP,HASH} as skipped, don't run them at all. Skipped test might signal that the test environment is not suitable for running the test, while in reality the functionality is not implemented in the kernel yet. Before: sh# ./test_progs -t select_reuseport … #40 select_reuseport:OK Summary: 1/126 PASSED, 30 SKIPPED, 0 FAILED After: sh# ./test_progs -t select_reuseport … #40 select_reuseport:OK Summary: 1/98 PASSED, 2 SKIPPED, 0 FAILED The remaining two skipped tests are SYN cookies tests, which will be addressed in the subsequent patch. Fixes: 11318ba8cafd ("selftests/bpf: Extend SK_REUSEPORT tests to cover SOCKMAP/SOCKHASH") Reported-by: Alexei Starovoitov Signed-off-by: Jakub Sitnicki Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200224135327.121542-1-jakub@cloudflare.com + Changed Files: tools/testing/selftests/bpf/prog_tests/select_reuseport.c | 13 ++++++-------; 1 file changed, 6 insertions(+), 7 deletions(-) + Parent Hashes: 80a836c2506b2b249a9934fbe373eb7a4a98db86 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit modifies the BPF reuseport self-tests to exclude unsupported UDP socket types for SOCKMAP and SOCKHASH.", + "keywords": "reuseport, self-tests, SOCKMAP", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "This commit modifies BPF reuseport self-tests to avoid running unsupported UDP tests with SOCKMAP and SOCKHASH.", + "keywords": "reuseport,self-tests,SOCKMAP", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 507/6895 - Commit ID: 80a836c2506b2b249a9934fbe373eb7a4a98db86 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 80a836c2506b2b249a9934fbe373eb7a4a98db86 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1582590010 + Commit Message: + Merge branch 'BPF_and_RT' Thomas Gleixner says: ==================== This is the third version of the BPF/RT patch set which makes both coexist nicely. The long explanation can be found in the cover letter of the V1 submission: https://lore.kernel.org/r/20200214133917.304937432@linutronix.de V2 is here: https://lore.kernel.org/r/20200220204517.863202864@linutronix.de The following changes vs. V2 have been made: - Rebased to bpf-next, adjusted to the lock changes in the hashmap code. - Split the preallocation enforcement patch for instrumentation type BPF programs into two pieces: 1) Emit a one-time warning on !RT kernels when any instrumentation type BPF program uses run-time allocation. Emit also a corresponding warning in the verifier log. But allow the program to run for backward compatibility sake. After a grace period this should be enforced. 2) On RT reject such programs because on RT the memory allocator cannot be called from truly atomic contexts. - Fixed the fallout from V2 as reported by Alexei and 0-day - Removed the redundant preempt_disable() from trace_call_bpf() - Removed the unused export of trace_call_bpf() ==================== Signed-off-by: Alexei Starovoitov + Changed Files: nan + Parent Hashes: 8eece07c011f88da0ccf4127fca9a4e4faaf58ae 099bfaa731ec347d3f16a463ae53b88a1700c0af +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges updates for improved BPF and RT coexistence, including changes to locks and memory allocation warnings.", + "keywords": "BPF,merge,RT", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges updates for better coexistence of BPF and RT, including lock and memory allocation changes.", + "keywords": "BPF,merge,RT", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 508/6895 - Commit ID: 099bfaa731ec347d3f16a463ae53b88a1700c0af +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 099bfaa731ec347d3f16a463ae53b88a1700c0af + Author Name: David Miller + Author Email: davem@davemloft.net + Commit Date: 1582590010 + Commit Message: + bpf/stackmap: Dont trylock mmap_sem with PREEMPT_RT and interrupts disabled In a RT kernel down_read_trylock() cannot be used from NMI context and up_read_non_owner() is another problematic issue. So in such a configuration, simply elide the annotated stackmap and just report the raw IPs. In the longer term, it might be possible to provide a atomic friendly versions of the page cache traversal which will at least provide the info if the pages are resident and don't need to be paged in. [ tglx: Use IS_ENABLED() to avoid the #ifdeffery, fixup the irq work callback and add a comment ] Signed-off-by: David S. Miller Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145644.708960317@linutronix.de + Changed Files: kernel/bpf/stackmap.c | 18 +++++++++++++++---; 1 file changed, 15 insertions(+), 3 deletions(-) + Parent Hashes: 66150d0dde030c5ee68ccd93e4c54a73c47ebebd +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes an issue in stackmap handling in RT kernels by avoiding trylock usage in NMI context.", + "keywords": "stackmap NMI trylock", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes stackmap handling in RT kernels by avoiding trylock usage in NMI context.", + "keywords": "stackmap RT NMI", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 509/6895 - Commit ID: 66150d0dde030c5ee68ccd93e4c54a73c47ebebd +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 66150d0dde030c5ee68ccd93e4c54a73c47ebebd + Author Name: Thomas Gleixner + Author Email: tglx@linutronix.de + Commit Date: 1582590010 + Commit Message: + bpf, lpm: Make locking RT friendly The LPM trie map cannot be used in contexts like perf, kprobes and tracing as this map type dynamically allocates memory. The memory allocation happens with a raw spinlock held which is a truly spinning lock on a PREEMPT RT enabled kernel which disables preemption and interrupts. As RT does not allow memory allocation from such a section for various reasons, convert the raw spinlock to a regular spinlock. On a RT enabled kernel these locks are substituted by 'sleeping' spinlocks which provide the proper protection but keep the code preemptible. On a non-RT kernel regular spinlocks map to raw spinlocks, i.e. this does not cause any functional change. Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145644.602129531@linutronix.de + Changed Files: kernel/bpf/lpm_trie.c | 12 ++++++------; 1 file changed, 6 insertions(+), 6 deletions(-) + Parent Hashes: 7f805d17f1523c7b2c0da319ddb427d6c5d94ff1 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit changes lock type in the LPM trie map to make it real-time kernel friendly.", + "keywords": "LPM, spinlock, RT", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit modifies lock type in the LPM trie map to suit real-time kernel constraints.", + "keywords": "LPM, spinlock, RT", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 510/6895 - Commit ID: 7f805d17f1523c7b2c0da319ddb427d6c5d94ff1 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 7f805d17f1523c7b2c0da319ddb427d6c5d94ff1 + Author Name: Thomas Gleixner + Author Email: tglx@linutronix.de + Commit Date: 1582590010 + Commit Message: + bpf: Prepare hashtab locking for PREEMPT_RT PREEMPT_RT forbids certain operations like memory allocations (even with GFP_ATOMIC) from atomic contexts. This is required because even with GFP_ATOMIC the memory allocator calls into code pathes which acquire locks with long held lock sections. To ensure the deterministic behaviour these locks are regular spinlocks, which are converted to 'sleepable' spinlocks on RT. The only true atomic contexts on an RT kernel are the low level hardware handling, scheduling, low level interrupt handling, NMIs etc. None of these contexts should ever do memory allocations. As regular device interrupt handlers and soft interrupts are forced into thread context, the existing code which does spin_lock*(); alloc(GPF_ATOMIC); spin_unlock*(); just works. In theory the BPF locks could be converted to regular spinlocks as well, but the bucket locks and percpu_freelist locks can be taken from arbitrary contexts (perf, kprobes, tracepoints) which are required to be atomic contexts even on RT. These mechanisms require preallocated maps, so there is no need to invoke memory allocations within the lock held sections. BPF maps which need dynamic allocation are only used from (forced) thread context on RT and can therefore use regular spinlocks which in turn allows to invoke memory allocations from the lock held section. To achieve this make the hash bucket lock a union of a raw and a regular spinlock and initialize and lock/unlock either the raw spinlock for preallocated maps or the regular variant for maps which require memory allocations. On a non RT kernel this distinction is neither possible nor required. spinlock maps to raw_spinlock and the extra code and conditional is optimized out by the compiler. No functional change. Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145644.509685912@linutronix.de + Changed Files: kernel/bpf/hashtab.c | 65 ++++++++++++++++++++++++++++++++++++++++++++--------; 1 file changed, 56 insertions(+), 9 deletions(-) + Parent Hashes: d01f9b198ca985b49717d8cd0b1f57806cb1319a +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Adjusts BPF hash table locking to accommodate real-time kernel requirements without functional changes.", + "keywords": "PREEMPT_RT,spinlocks,hashtab", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Adjusts BPF hash table locking to accommodate real-time kernel requirements without functional changes.", + "keywords": "PREEMPT_RT,spinlocks,hashtab", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 511/6895 - Commit ID: d01f9b198ca985b49717d8cd0b1f57806cb1319a +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: d01f9b198ca985b49717d8cd0b1f57806cb1319a + Author Name: Thomas Gleixner + Author Email: tglx@linutronix.de + Commit Date: 1582590010 + Commit Message: + bpf: Factor out hashtab bucket lock operations As a preparation for making the BPF locking RT friendly, factor out the hash bucket lock operations into inline functions. This allows to do the necessary RT modification in one place instead of sprinkling it all over the place. No functional change. The now unused htab argument of the lock/unlock functions will be used in the next step which adds PREEMPT_RT support. Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145644.420416916@linutronix.de + Changed Files: kernel/bpf/hashtab.c | 69 ++++++++++++++++++++++++++++++++++------------------; 1 file changed, 46 insertions(+), 23 deletions(-) + Parent Hashes: b6e5dae15a61b0cc9219799926813baad0b58967 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit factors out hash bucket lock operations into inline functions for RT friendliness without functional changes.", + "keywords": "hashbucket,lock,RT", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit factors out hash bucket lock operations into inline functions for RT friendliness without functional changes.", + "keywords": "hashbucket,lock,RT", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 512/6895 - Commit ID: b6e5dae15a61b0cc9219799926813baad0b58967 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: b6e5dae15a61b0cc9219799926813baad0b58967 + Author Name: Thomas Gleixner + Author Email: tglx@linutronix.de + Commit Date: 1582590010 + Commit Message: + bpf: Replace open coded recursion prevention in sys_bpf() The required protection is that the caller cannot be migrated to a different CPU as these functions end up in places which take either a hash bucket lock or might trigger a kprobe inside the memory allocator. Both scenarios can lead to deadlocks. The deadlock prevention is per CPU by incrementing a per CPU variable which temporarily blocks the invocation of BPF programs from perf and kprobes. Replace the open coded preempt_[dis|en]able and __this_cpu_[inc|dec] pairs with the new helper functions. These functions are already prepared to make BPF work on PREEMPT_RT enabled kernels. No functional change for !RT kernels. Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145644.317843926@linutronix.de + Changed Files: kernel/bpf/syscall.c | 27 ++++++++-------------------; 1 file changed, 8 insertions(+), 19 deletions(-) + Parent Hashes: 085fee1a72a9fba101a4a68a2c02fa8bd2b6f913 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Replaces custom recursion prevention code in sys_bpf with helper functions for PREEMPT_RT compatibility.", + "keywords": "recursion,prevention,helper", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The syscall interface. It changes the system calls through which user-space programs interact with eBPF.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Refactors sys_bpf by replacing custom recursion prevention with helper functions for enhanced RT kernel compatibility.", + "keywords": "recursion,prevention,sys_bpf", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The syscall interface. It changes the system calls through which user-space programs interact with eBPF.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 513/6895 - Commit ID: 085fee1a72a9fba101a4a68a2c02fa8bd2b6f913 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 085fee1a72a9fba101a4a68a2c02fa8bd2b6f913 + Author Name: Thomas Gleixner + Author Email: tglx@linutronix.de + Commit Date: 1582590010 + Commit Message: + bpf: Use recursion prevention helpers in hashtab code The required protection is that the caller cannot be migrated to a different CPU as these places take either a hash bucket lock or might trigger a kprobe inside the memory allocator. Both scenarios can lead to deadlocks. The deadlock prevention is per CPU by incrementing a per CPU variable which temporarily blocks the invocation of BPF programs from perf and kprobes. Replace the open coded preempt_disable/enable() and this_cpu_inc/dec() pairs with the new recursion prevention helpers to prepare BPF to work on PREEMPT_RT enabled kernels. On a non-RT kernel the migrate disable/enable in the helpers map to preempt_disable/enable(), i.e. no functional change. Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145644.211208533@linutronix.de + Changed Files: kernel/bpf/hashtab.c | 12 ++++--------; 1 file changed, 4 insertions(+), 8 deletions(-) + Parent Hashes: c518cfa0c5ad75ddf3d743f1e35b9cf5fc2c346e +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit replaces open-coded methods with recursion prevention helpers in bpf hashtab for PREEMPT_RT kernel preparation.", + "keywords": "recursion prevention, PREEMPT_RT, hashtab", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit updates bpf hashtab code using recursion prevention helpers to enhance PREEMPT_RT kernel compatibility.", + "keywords": "recursion prevention, kernel compatibility, hashtab", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 514/6895 - Commit ID: c518cfa0c5ad75ddf3d743f1e35b9cf5fc2c346e +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: c518cfa0c5ad75ddf3d743f1e35b9cf5fc2c346e + Author Name: Thomas Gleixner + Author Email: tglx@linutronix.de + Commit Date: 1582590009 + Commit Message: + bpf: Provide recursion prevention helpers The places which need to prevent the execution of trace type BPF programs to prevent deadlocks on the hash bucket lock do this open coded. Provide two inline functions, bpf_disable/enable_instrumentation() to replace these open coded protection constructs. Use migrate_disable/enable() instead of preempt_disable/enable() right away so this works on RT enabled kernels. On a !RT kernel migrate_disable / enable() are mapped to preempt_disable/enable(). These helpers use this_cpu_inc/dec() instead of __this_cpu_inc/dec() on an RT enabled kernel because migrate disabled regions are preemptible and preemption might hit in the middle of a RMW operation which can lead to inconsistent state. Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145644.103910133@linutronix.de + Changed Files: include/linux/bpf.h | 30 ++++++++++++++++++++++++++++++; 1 file changed, 30 insertions(+) + Parent Hashes: 2a916f2f546ca1c1e3323e2a4269307f6d9890eb +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit introduces inline functions for recursion prevention in trace type BPF programs to avoid deadlocks.", + "keywords": "recursion,trace,deadlock", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds inline functions to prevent deadlocks in trace type BPF programs by managing recursion prevention and instrumentation.", + "keywords": "recursion, helpers, deadlocks", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.", + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 515/6895 - Commit ID: 2a916f2f546ca1c1e3323e2a4269307f6d9890eb +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 2a916f2f546ca1c1e3323e2a4269307f6d9890eb + Author Name: David Miller + Author Email: davem@davemloft.net + Commit Date: 1582590009 + Commit Message: + bpf: Use migrate_disable/enable in array macros and cgroup/lirc code. Replace the preemption disable/enable with migrate_disable/enable() to reflect the actual requirement and to allow PREEMPT_RT to substitute it with an actual migration disable mechanism which does not disable preemption. Including the code paths that go via __bpf_prog_run_save_cb(). Signed-off-by: David S. Miller Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145643.998293311@linutronix.de + Changed Files: include/linux/bpf.h | 8 ++++----; include/linux/filter.h | 5 +++--; 2 files changed, 7 insertions(+), 6 deletions(-) + Parent Hashes: 02ad05965491ca72034327d47da6cb25f3a92603 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Replace preemption disable with migrate_disable in BPF array macros and cgroup/lirc code.", + "keywords": "migrate_disable,array,cgroup", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups).", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +Rethinking... +new content: +{ + "summary": "Replace preemption disable with migrate_disable in BPF array macros and cgroup/lirc code.", + "keywords": "migrate_disable,array,cgroup", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups).", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 516/6895 - Commit ID: 02ad05965491ca72034327d47da6cb25f3a92603 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 02ad05965491ca72034327d47da6cb25f3a92603 + Author Name: David Miller + Author Email: davem@davemloft.net + Commit Date: 1582590009 + Commit Message: + bpf: Use migrate_disable/enabe() in trampoline code. Instead of preemption disable/enable to reflect the purpose. This allows PREEMPT_RT to substitute it with an actual migration disable implementation. On non RT kernels this is still mapped to preempt_disable/enable(). Signed-off-by: David S. Miller Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145643.891428873@linutronix.de + Changed Files: kernel/bpf/trampoline.c | 9 +++++----; 1 file changed, 5 insertions(+), 4 deletions(-) + Parent Hashes: 6eac7795e8ef75de062c8f5bdb9520c9f0f065fa +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit updates trampoline code to use migrate_disable/enable for better PREEMPT_RT compatibility.", + "keywords": "trampoline migrate_disable PREEMPT_RT", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit updates trampoline code to use migrate_disable/enable for better PREEMPT_RT compatibility.", + "keywords": "trampoline migrate_disable PREEMPT_RT", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 517/6895 - Commit ID: 6eac7795e8ef75de062c8f5bdb9520c9f0f065fa +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 6eac7795e8ef75de062c8f5bdb9520c9f0f065fa + Author Name: David Miller + Author Email: davem@davemloft.net + Commit Date: 1582590009 + Commit Message: + bpf/tests: Use migrate disable instead of preempt disable Replace the preemption disable/enable with migrate_disable/enable() to reflect the actual requirement and to allow PREEMPT_RT to substitute it with an actual migration disable mechanism which does not disable preemption. [ tglx: Switched it over to migrate disable ] Signed-off-by: David S. Miller Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145643.785306549@linutronix.de + Changed Files: lib/test_bpf.c | 4 ++--; net/bpf/test_run.c | 8 ++++----; 2 files changed, 6 insertions(+), 6 deletions(-) + Parent Hashes: 3d9f773cf2876c01a505b9fe27270901d464e90a +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit replaces preempt_disable with migrate_disable in eBPF tests to allow better PREEMPT_RT handling.", + "keywords": "migrate, preempt, disable", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit updates eBPF tests to use migrate_disable instead of preempt_disable to improve PREEMPT_RT support.", + "keywords": "migrate, preempt, tests", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 518/6895 - Commit ID: 3d9f773cf2876c01a505b9fe27270901d464e90a +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 3d9f773cf2876c01a505b9fe27270901d464e90a + Author Name: David Miller + Author Email: davem@davemloft.net + Commit Date: 1582590009 + Commit Message: + bpf: Use bpf_prog_run_pin_on_cpu() at simple call sites. All of these cases are strictly of the form: preempt_disable(); BPF_PROG_RUN(...); preempt_enable(); Replace this with bpf_prog_run_pin_on_cpu() which wraps BPF_PROG_RUN() with: migrate_disable(); BPF_PROG_RUN(...); migrate_enable(); On non RT enabled kernels this maps to preempt_disable/enable() and on RT enabled kernels this solely prevents migration, which is sufficient as there is no requirement to prevent reentrancy to any BPF program from a preempting task. The only requirement is that the program stays on the same CPU. Therefore, this is a trivially correct transformation. The seccomp loop does not need protection over the loop. It only needs protection per BPF filter program [ tglx: Converted to bpf_prog_run_pin_on_cpu() ] Signed-off-by: David S. Miller Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145643.691493094@linutronix.de + Changed Files: include/linux/filter.h | 4 +---; kernel/seccomp.c | 4 +---; net/core/flow_dissector.c | 4 +---; net/core/skmsg.c | 8 ++------; net/kcm/kcmsock.c | 4 +---; 5 files changed, 6 insertions(+), 18 deletions(-) + Parent Hashes: 37e1d9202225635772b32e340294208367279c2b +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit refactors eBPF code to use bpf_prog_run_pin_on_cpu() for improved CPU pinning consistency across platforms.", + "keywords": "refactor, CPU, pinning", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit uses bpf_prog_run_pin_on_cpu() for CPU-specific eBPF execution, enhancing consistency across kernel configurations.", + "keywords": "bpf, CPU, refactoring", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 519/6895 - Commit ID: 37e1d9202225635772b32e340294208367279c2b +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 37e1d9202225635772b32e340294208367279c2b + Author Name: Thomas Gleixner + Author Email: tglx@linutronix.de + Commit Date: 1582590009 + Commit Message: + bpf: Replace cant_sleep() with cant_migrate() As already discussed in the previous change which introduced BPF_RUN_PROG_PIN_ON_CPU() BPF only requires to disable migration to guarantee per CPUness. If RT substitutes the preempt disable based migration protection then the cant_sleep() check will obviously trigger as preemption is not disabled. Replace it by cant_migrate() which maps to cant_sleep() on a non RT kernel and will verify that migration is disabled on a full RT kernel. Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145643.583038889@linutronix.de + Changed Files: include/linux/filter.h | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: 3c58482a382bae89410439247152eb342e9872f7 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Replace cant_sleep() with cant_migrate() to align with BPF_RUN_PROG_PIN_ON_CPU requirements regarding CPU migration and preemption.", + "keywords": "cant_sleep,cant_migrate,CPU-migration", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Replace cant_sleep() with cant_migrate() for handling CPU migration in BPF programs.", + "keywords": "cant_sleep,cant_migrate,BPF", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 520/6895 - Commit ID: 3c58482a382bae89410439247152eb342e9872f7 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 3c58482a382bae89410439247152eb342e9872f7 + Author Name: Thomas Gleixner + Author Email: tglx@linutronix.de + Commit Date: 1582590005 + Commit Message: + bpf: Provide bpf_prog_run_pin_on_cpu() helper BPF programs require to run on one CPU to completion as they use per CPU storage, but according to Alexei they don't need reentrancy protection as obviously BPF programs running in thread context can always be 'preempted' by hard and soft interrupts and instrumentation and the same program can run concurrently on a different CPU. The currently used mechanism to ensure CPUness is to wrap the invocation into a preempt_disable/enable() pair. Disabling preemption is also disabling migration for a task. preempt_disable/enable() is used because there is no explicit way to reliably disable only migration. Provide a separate macro to invoke a BPF program which can be used in migrateable task context. It wraps BPF_PROG_RUN() in a migrate_disable/enable() pair which maps on non RT enabled kernels to preempt_disable/enable(). On RT enabled kernels this merely disables migration. Both methods ensure that the invoked BPF program runs on one CPU to completion. Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145643.474592620@linutronix.de + Changed Files: include/linux/filter.h | 26 ++++++++++++++++++++++++--; 1 file changed, 24 insertions(+), 2 deletions(-) + Parent Hashes: 569de905ebc30b9c61be7aa557403aeb5a9141a4 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit introduces a new helper function, bpf_prog_run_pin_on_cpu, to ensure BPF programs run on one CPU to completion by disabling migration.", + "keywords": "bpf, migration, cpu", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit introduces bpf_prog_run_pin_on_cpu to ensure BPF programs run on a single CPU by disabling migration effectively.", + "keywords": "bpf, migration, cpu", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 521/6895 - Commit ID: 569de905ebc30b9c61be7aa557403aeb5a9141a4 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 569de905ebc30b9c61be7aa557403aeb5a9141a4 + Author Name: Thomas Gleixner + Author Email: tglx@linutronix.de + Commit Date: 1582589900 + Commit Message: + bpf: Dont iterate over possible CPUs with interrupts disabled pcpu_freelist_populate() is disabling interrupts and then iterates over the possible CPUs. The reason why this disables interrupts is to silence lockdep because the invoked ___pcpu_freelist_push() takes spin locks. Neither the interrupt disabling nor the locking are required in this function because it's called during initialization and the resulting map is not yet visible to anything. Split out the actual push assignement into an inline, call it from the loop and remove the interrupt disable. Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145643.365930116@linutronix.de + Changed Files: kernel/bpf/percpu_freelist.c | 20 ++++++++++----------; 1 file changed, 10 insertions(+), 10 deletions(-) + Parent Hashes: 8a37963c7ac9ecb7f86f8ebda020e3f8d6d7b8a0 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit refactors percpu_freelist to eliminate unnecessary interrupt disabling during initialization.", + "keywords": "interrupts, initialization, percpu_freelist", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit refactors percpu_freelist to eliminate unnecessary interrupt disabling during the initialization phase.", + "keywords": "interrupts, initialization, percpu_freelist", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 522/6895 - Commit ID: 8a37963c7ac9ecb7f86f8ebda020e3f8d6d7b8a0 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 8a37963c7ac9ecb7f86f8ebda020e3f8d6d7b8a0 + Author Name: Thomas Gleixner + Author Email: tglx@linutronix.de + Commit Date: 1582589900 + Commit Message: + bpf: Remove recursion prevention from rcu free callback If an element is freed via RCU then recursion into BPF instrumentation functions is not a concern. The element is already detached from the map and the RCU callback does not hold any locks on which a kprobe, perf event or tracepoint attached BPF program could deadlock. Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145643.259118710@linutronix.de + Changed Files: kernel/bpf/hashtab.c | 8 --------; 1 file changed, 8 deletions(-) + Parent Hashes: 1d7bf6b7d3e8353c3fac648f3f9b3010458570c2 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit removes recursion prevention from RCU free callback in BPF maps as recursion is not a concern when elements are detached and no deadlock risks exist.", + "keywords": "recursion,RCU,BPF", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit removes unnecessary recursion prevention from the RCU free callback in BPF maps, enhancing map management without deadlock risks.", + "keywords": "recursion,RCU,BPF", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 523/6895 - Commit ID: 1d7bf6b7d3e8353c3fac648f3f9b3010458570c2 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 1d7bf6b7d3e8353c3fac648f3f9b3010458570c2 + Author Name: Thomas Gleixner + Author Email: tglx@linutronix.de + Commit Date: 1582589900 + Commit Message: + perf/bpf: Remove preempt disable around BPF invocation The BPF invocation from the perf event overflow handler does not require to disable preemption because this is called from NMI or at least hard interrupt context which is already non-preemptible. Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145643.151953573@linutronix.de + Changed Files: kernel/events/core.c | 2 --; 1 file changed, 2 deletions(-) + Parent Hashes: b0a81b94cc50a112601721fcc2f91fab78d7b9f3 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit removes unnecessary preemption disabling in BPF invocation from the perf event overflow handler.", + "keywords": "preemption, BPF, invocation", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit removes redundant preemption disabling in the BPF call from the perf event overflow handler.", + "keywords": "perf,BPF,preemption", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 524/6895 - Commit ID: b0a81b94cc50a112601721fcc2f91fab78d7b9f3 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: b0a81b94cc50a112601721fcc2f91fab78d7b9f3 + Author Name: Thomas Gleixner + Author Email: tglx@linutronix.de + Commit Date: 1582589900 + Commit Message: + bpf/trace: Remove redundant preempt_disable from trace_call_bpf() Similar to __bpf_trace_run this is redundant because __bpf_trace_run() is invoked from a trace point via __DO_TRACE() which already disables preemption _before_ invoking any of the functions which are attached to a trace point. Remove it and add a cant_sleep() check. Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145643.059995527@linutronix.de + Changed Files: kernel/trace/bpf_trace.c | 3 +--; 1 file changed, 1 insertion(+), 2 deletions(-) + Parent Hashes: 70ed0706a48e3da3eb4515214fef658ff1184b9f +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit removes redundant preempt_disable from trace_call_bpf and introduces a cant_sleep check.", + "keywords": "preempt_disable,trace_call_bpf,cant_sleep", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here." + ] +} +Rethinking... +new content: +{ + "summary": "This commit removes redundant preemption logic from a tracing function in the eBPF trace code.", + "keywords": "preempt_disable,trace_call_bpf,cant_sleep", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here." + ] +} +-------------------- +-------------------- +Processing Commit 525/6895 - Commit ID: 70ed0706a48e3da3eb4515214fef658ff1184b9f +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 70ed0706a48e3da3eb4515214fef658ff1184b9f + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1582589834 + Commit Message: + bpf: disable preemption for bpf progs attached to uprobe trace_call_bpf() no longer disables preemption on its own. All callers of this function has to do it explicitly. Signed-off-by: Alexei Starovoitov Acked-by: Thomas Gleixner + Changed Files: kernel/trace/trace_uprobe.c | 11 +++++++++--; 1 file changed, 9 insertions(+), 2 deletions(-) + Parent Hashes: 1b7a51a63b031092b8b8acda3f6820b62a8b5e5d +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit modifies the handling of preemption for BPF programs attached to uprobe by requiring explicit preemption disablement.", + "keywords": "preemption,uprobes,bpf", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "uprobe/usdt like type user-space dynamic probe programs. It impacts user-space probes for tracing user-space applications. It can be other user-space probes in perf-events." + ] +} +Rethinking... +new content: +{ + "summary": "This commit changes preemption handling for BPF programs attached to uprobes, requiring explicit disabling by callers.", + "keywords": "preemption,uprobes,bpf", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "uprobe/usdt like type user-space dynamic probe programs. It impacts user-space probes for tracing user-space applications. It can be other user-space probes in perf-events." + ] +} +-------------------- +-------------------- +Processing Commit 526/6895 - Commit ID: 1b7a51a63b031092b8b8acda3f6820b62a8b5e5d +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 1b7a51a63b031092b8b8acda3f6820b62a8b5e5d + Author Name: Thomas Gleixner + Author Email: tglx@linutronix.de + Commit Date: 1582589798 + Commit Message: + bpf/trace: Remove EXPORT from trace_call_bpf() All callers are built in. No point to export this. Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov + Changed Files: kernel/trace/bpf_trace.c | 1 -; 1 file changed, 1 deletion(-) + Parent Hashes: f03efe49bd16c017107ff5079d08ea428e390dde +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Removed export of trace_call_bpf() as all its callers are built-in.", + "keywords": "trace_call_bpf, remove export, callers", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "It's likely a merge commit. It involves changes across multiple use cases or events.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Removed export of trace_call_bpf() as all callers are built-in.", + "keywords": "trace_call_bpf, remove, export", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +-------------------- +-------------------- +Processing Commit 527/6895 - Commit ID: f03efe49bd16c017107ff5079d08ea428e390dde +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: f03efe49bd16c017107ff5079d08ea428e390dde + Author Name: Thomas Gleixner + Author Email: tglx@linutronix.de + Commit Date: 1582589540 + Commit Message: + bpf/tracing: Remove redundant preempt_disable() in __bpf_trace_run() __bpf_trace_run() disables preemption around the BPF_PROG_RUN() invocation. This is redundant because __bpf_trace_run() is invoked from a trace point via __DO_TRACE() which already disables preemption _before_ invoking any of the functions which are attached to a trace point. Remove it and add a cant_sleep() check. Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145642.847220186@linutronix.de + Changed Files: kernel/trace/bpf_trace.c | 3 +--; 1 file changed, 1 insertion(+), 2 deletions(-) + Parent Hashes: dbca151cad736c99f4817076daf9fd02ed0c2daa +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit removes redundant preemption disabling in __bpf_trace_run and adds a cant_sleep check in the bpf tracing code.", + "keywords": "preemption,tracing,__bpf_trace_run", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing." + ] +} +Rethinking... +new content: +{ + "summary": "The commit removes redundant preemption disabling in __bpf_trace_run and adds a cant_sleep check in the bpf tracing code.", + "keywords": "preemption,tracing,__bpf_trace_run", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing." + ] +} +-------------------- +-------------------- +Processing Commit 528/6895 - Commit ID: dbca151cad736c99f4817076daf9fd02ed0c2daa +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: dbca151cad736c99f4817076daf9fd02ed0c2daa + Author Name: Thomas Gleixner + Author Email: tglx@linutronix.de + Commit Date: 1582589540 + Commit Message: + bpf: Update locking comment in hashtab code The comment where the bucket lock is acquired says: /* bpf_map_update_elem() can be called in_irq() */ which is not really helpful and aside of that it does not explain the subtle details of the hash bucket locks expecially in the context of BPF and perf, kprobes and tracing. Add a comment at the top of the file which explains the protection scopes and the details how potential deadlocks are prevented. Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145642.755793061@linutronix.de + Changed Files: kernel/bpf/hashtab.c | 24 ++++++++++++++++++++----; 1 file changed, 20 insertions(+), 4 deletions(-) + Parent Hashes: 2ed905c521e56aead6987df94c083efb0ee59895 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit updates the locking comment in the eBPF hashtab code to clarify protection scopes and prevent potential deadlocks.", + "keywords": "locking,hashtab,comment", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit updates the locking comment in the eBPF hashtab code to clarify protection scopes and prevent potential deadlocks.", + "keywords": "locking,hashtab,comment", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 529/6895 - Commit ID: 2ed905c521e56aead6987df94c083efb0ee59895 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 2ed905c521e56aead6987df94c083efb0ee59895 + Author Name: Thomas Gleixner + Author Email: tglx@linutronix.de + Commit Date: 1582589539 + Commit Message: + bpf: Enforce preallocation for instrumentation programs on RT Aside of the general unsafety of run-time map allocation for instrumentation type programs RT enabled kernels have another constraint: The instrumentation programs are invoked with preemption disabled, but the memory allocator spinlocks cannot be acquired in atomic context because they are converted to 'sleeping' spinlocks on RT. Therefore enforce map preallocation for these programs types when RT is enabled. Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145642.648784007@linutronix.de + Changed Files: kernel/bpf/verifier.c | 13 +++++++++----; 1 file changed, 9 insertions(+), 4 deletions(-) + Parent Hashes: 94dacdbd5d2dfa2cffd308f128d78c99f855f5be +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit enforces map preallocation for instrumentation programs when real-time (RT) is enabled to prevent unsafe memory allocator usage.", + "keywords": "preallocation,instrumentation,RT", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit enforces map preallocation for instrumentation programs when real-time (RT) is enabled to prevent unsafe memory allocator usage.", + "keywords": "preallocation,instrumentation,RT", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 530/6895 - Commit ID: 94dacdbd5d2dfa2cffd308f128d78c99f855f5be +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 94dacdbd5d2dfa2cffd308f128d78c99f855f5be + Author Name: Thomas Gleixner + Author Email: tglx@linutronix.de + Commit Date: 1582589539 + Commit Message: + bpf: Tighten the requirements for preallocated hash maps The assumption that only programs attached to perf NMI events can deadlock on memory allocators is wrong. Assume the following simplified callchain: kmalloc() from regular non BPF context cache empty freelist empty lock(zone->lock); tracepoint or kprobe BPF() update_elem() lock(bucket) kmalloc() cache empty freelist empty lock(zone->lock); <- DEADLOCK There are other ways which do not involve locking to create wreckage: kmalloc() from regular non BPF context local_irq_save(); ... obj = slab_first(); kprobe() BPF() update_elem() lock(bucket) kmalloc() local_irq_save(); ... obj = slab_first(); <- Same object as above ... So preallocation _must_ be enforced for all variants of intrusive instrumentation. Unfortunately immediate enforcement would break backwards compatibility, so for now such programs still are allowed to run, but a one time warning is emitted in dmesg and the verifier emits a warning in the verifier log as well so developers are made aware about this and can fix their programs before the enforcement becomes mandatory. Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145642.540542802@linutronix.de + Changed Files: kernel/bpf/verifier.c | 39 ++++++++++++++++++++++++++++-----------; 1 file changed, 28 insertions(+), 11 deletions(-) + Parent Hashes: 8eece07c011f88da0ccf4127fca9a4e4faaf58ae +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit tightens requirements for preallocated hash maps to prevent deadlocks in non-BPF contexts, while emitting warnings to maintain backward compatibility.", + "keywords": "preallocated, deadlock, warning", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +Rethinking... +new content: +{ + "summary": "This commit tightens requirements for preallocated hash maps to prevent deadlocks in non-BPF contexts while issuing warnings for backward compatibility.", + "keywords": "preallocated, deadlock, warnings", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +-------------------- +-------------------- +Processing Commit 531/6895 - Commit ID: 8eece07c011f88da0ccf4127fca9a4e4faaf58ae +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 8eece07c011f88da0ccf4127fca9a4e4faaf58ae + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1582338467 + Commit Message: + Merge tag 'sched-for-bpf-2020-02-20' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip into bpf-next Two migrate disable related stubs for BPF to base the RT patches on + Changed Files: nan + Parent Hashes: 732a0dee501f9a693c9a711730838129f4587041 4e139c7711633365ebb52fbb63905395522a8413 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges the 'sched-for-bpf-2020-02-20' tag from the tip tree into the bpf-next branch.", + "keywords": "merge, sched, bpf-next", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges the 'sched-for-bpf-2020-02-20' tag from the tip tree into the bpf-next branch.", + "keywords": "merge, sched, bpf", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 532/6895 - Commit ID: b105e8e281ac2dbea4229982ad57fbefab05963d +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: b105e8e281ac2dbea4229982ad57fbefab05963d + Author Name: David S. Miller + Author Email: davem@davemloft.net + Commit Date: 1582327365 + Commit Message: + Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next Daniel Borkmann says: ==================== pull-request: bpf-next 2020-02-21 The following pull-request contains BPF updates for your *net-next* tree. We've added 25 non-merge commits during the last 4 day(s) which contain a total of 33 files changed, 2433 insertions(+), 161 deletions(-). The main changes are: 1) Allow for adding TCP listen sockets into sock_map/hash so they can be used with reuseport BPF programs, from Jakub Sitnicki. 2) Add a new bpf_program__set_attach_target() helper for adding libbpf support to specify the tracepoint/function dynamically, from Eelco Chaudron. 3) Add bpf_read_branch_records() BPF helper which helps use cases like profile guided optimizations, from Daniel Xu. 4) Enable bpf_perf_event_read_value() in all tracing programs, from Song Liu. 5) Relax BTF mandatory check if only used for libbpf itself e.g. to process BTF defined maps, from Andrii Nakryiko. 6) Move BPF selftests -mcpu compilation attribute from 'probe' to 'v3' as it has been observed that former fails in envs with low memlock, from Yonghong Song. ==================== Signed-off-by: David S. Miller + Changed Files: nan + Parent Hashes: e65ee2fb54d4745d7b7d9061d7fe33c5c5bf3b06 eb1e1478b6f4e70d99fee3f49bb7f7143c8c871d +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges updates from the bpf-next branch into the net-next tree, including several enhancements and new features for BPF programs.", + "keywords": "merge,bpf,next", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges bpf-next updates into net-next containing various BPF enhancements and features.", + "keywords": "merge,bpf,next", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 533/6895 - Commit ID: eb1e1478b6f4e70d99fee3f49bb7f7143c8c871d +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: eb1e1478b6f4e70d99fee3f49bb7f7143c8c871d + Author Name: Daniel Borkmann + Author Email: daniel@iogearbox.net + Commit Date: 1582320701 + Commit Message: + Merge branch 'bpf-sockmap-listen' Jakub Sitnicki says: ==================== This patch set turns SOCK{MAP,HASH} into generic collections for TCP sockets, both listening and established. Adding support for listening sockets enables us to use these BPF map types with reuseport BPF programs. Why? SOCKMAP and SOCKHASH, in comparison to REUSEPORT_SOCKARRAY, allow the socket to be in more than one map at the same time. Having a BPF map type that can hold listening sockets, and gracefully co-exist with reuseport BPF is important if, in the future, we want BPF programs that run at socket lookup time [0]. Cover letter for v1 of this series tells the full story of how we got here [1]. Although SOCK{MAP,HASH} are not a drop-in replacement for SOCKARRAY just yet, because UDP support is lacking, it's a step in this direction. We're working with Lorenz on extending SOCK{MAP,HASH} to hold UDP sockets, and expect to post RFC series for sockmap + UDP in the near future. I've dropped Acks from all patches that have been touched since v6. The audit for missing READ_ONCE annotations for access to sk_prot is ongoing. Thus far I've found one location specific to TCP listening sockets that needed annotating. This got fixed it in this iteration. I wonder if sparse checker could be put to work to identify places where we have sk_prot access while not holding sk_lock... The patch series depends on another one, posted earlier [2], that has been split out of it. v6 -> v7: - Extended the series to cover SOCKHASH. (patches 4-8, 10-11) (John) - Rebased onto recent bpf-next. Resolved conflicts in recent fixes to sk_state checks on sockmap/sockhash update path. (patch 4) - Added missing READ_ONCE annotation in sock_copy. (patch 1) - Split out patches that simplify sk_psock_restore_proto [2]. v5 -> v6: - Added a fix-up for patch 1 which I forgot to commit in v5. Sigh. v4 -> v5: - Rebase onto recent bpf-next to resolve conflicts. (Daniel) v3 -> v4: - Make tcp_bpf_clone parameter names consistent across function declaration and definition. (Martin) - Use sock_map_redirect_okay helper everywhere we need to take a different action for listening sockets. (Lorenz) - Expand comment explaining the need for a callback from reuseport to sockarray code in reuseport_detach_sock. (Martin) - Mention the possibility of using a u64 counter for reuseport IDs in the future in the description for patch 10. (Martin) v2 -> v3: - Generate reuseport ID when group is created. Please see patch 10 description for details. (Martin) - Fix the build when CONFIG_NET_SOCK_MSG is not selected by either CONFIG_BPF_STREAM_PARSER or CONFIG_TLS. (kbuild bot & John) - Allow updating sockmap from BPF on BPF_SOCK_OPS_TCP_LISTEN_CB callback. An oversight in previous iterations. Users may want to populate the sockmap with listening sockets from BPF as well. - Removed RCU read lock assertion in sock_map_lookup_sys. (Martin) - Get rid of a warning when child socket was cloned with parent's psock state. (John) - Check for tcp_bpf_unhash rather than tcp_bpf_recvmsg when deciding if sk_proto needs restoring on clone. Check for recvmsg in the context of listening socket cloning was confusing. (Martin) - Consolidate sock_map_sk_is_suitable with sock_map_update_okay. This led to adding dedicated predicates for sockhash. Update self-tests accordingly. (John) - Annotate unlikely branch in bpf_{sk,msg}_redirect_map when socket isn't in a map, or isn't a valid redirect target. (John) - Document paired READ/WRITE_ONCE annotations and cover shared access in more detail in patch 2 description. (John) - Correct a couple of log messages in sockmap_listen self-tests so the message reflects the actual failure. - Rework reuseport tests from sockmap_listen suite so that ENOENT error from bpf_sk_select_reuseport handler does not happen on happy path. v1 -> v2: - af_ops->syn_recv_sock callback is no longer overridden and burdened with restoring sk_prot and clearing sk_user_data in the child socket. As child socket is already hashed when syn_recv_sock returns, it is too late to put it in the right state. Instead patches 3 & 4 address restoring sk_prot and clearing sk_user_data before we hash the child socket. (Pointed out by Martin Lau) - Annotate shared access to sk->sk_prot with READ_ONCE/WRITE_ONCE macros as we write to it from sk_msg while socket might be getting cloned on another CPU. (Suggested by John Fastabend) - Convert tests for SOCKMAP holding listening sockets to return-on-error style, and hook them up to test_progs. Also use BPF skeleton for setup. Add new tests to cover the race scenario discovered during v1 review. RFC -> v1: - Switch from overriding proto->accept to af_ops->syn_recv_sock, which happens earlier. Clearing the psock state after accept() does not work for child sockets that become orphaned (never got accepted). v4-mapped sockets need special care. - Return the socket cookie on SOCKMAP lookup from syscall to be on par with REUSEPORT_SOCKARRAY. Requires SOCKMAP to take u64 on lookup/update from syscall. - Make bpf_sk_redirect_map (ingress) and bpf_msg_redirect_map (egress) SOCKMAP helpers fail when target socket is a listening one. - Make bpf_sk_select_reuseport helper fail when target is a TCP established socket. - Teach libbpf to recognize SK_REUSEPORT program type from section name. - Add a dedicated set of tests for SOCKMAP holding listening sockets, covering map operations, overridden socket callbacks, and BPF helpers. [0] https://lore.kernel.org/bpf/20190828072250.29828-1-jakub@cloudflare.com/ [1] https://lore.kernel.org/bpf/20191123110751.6729-1-jakub@cloudflare.com/ [2] https://lore.kernel.org/bpf/20200217121530.754315-1-jakub@cloudflare.com/ ==================== Signed-off-by: Daniel Borkmann + Changed Files: nan + Parent Hashes: e42da4c62abb547d9c9138e0e7fcd1f36057b5e8 44d28be2b8d41e3198052b8c9eded2e23eb9e08b +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges changes enabling SOCKMAP and SOCKHASH to support listening TCP sockets, enhancing BPF program capabilities for socket lookup and reuseport scenarios.", + "keywords": "SOCKMAP,SOCKHASH,reuseport", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's likely a merge commit. It involves changes across multiple use cases or events.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges changes enabling SOCKMAP and SOCKHASH to support listening TCP sockets, enhancing BPF program capabilities for socket lookup and reuseport scenarios.", + "keywords": "SOCKMAP,SOCKHASH,reuseport", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's likely a merge commit. It involves changes across multiple use cases or events.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +-------------------- +-------------------- +Processing Commit 534/6895 - Commit ID: 44d28be2b8d41e3198052b8c9eded2e23eb9e08b +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 44d28be2b8d41e3198052b8c9eded2e23eb9e08b + Author Name: Jakub Sitnicki + Author Email: jakub@cloudflare.com + Commit Date: 1582320586 + Commit Message: + selftests/bpf: Tests for sockmap/sockhash holding listening sockets Now that SOCKMAP and SOCKHASH map types can store listening sockets, user-space and BPF API is open to a new set of potential pitfalls. Exercise the map operations, with extra attention to code paths susceptible to races between map ops and socket cloning, and BPF helpers that work with SOCKMAP/SOCKHASH to gain confidence that all works as expected. Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200218171023.844439-12-jakub@cloudflare.com + Changed Files: .../selftests/bpf/prog_tests/sockmap_listen.c | 1496 ++++++++++++++++++++; .../selftests/bpf/progs/test_sockmap_listen.c | 98 ++; 2 files changed, 1594 insertions(+) + Parent Hashes: 11318ba8cafd59105637b2b82b8a32719e44a2d2 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Add selftests for sockmap and sockhash with listening sockets to address potential issues and ensure reliable operation.", + "keywords": "selftests,sockmap,sockhash", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "Add selftests to verify sockmap and sockhash functionality with listening sockets, targeting race conditions and socket cloning issues.", + "keywords": "selftests,sockmap,listening", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +-------------------- +-------------------- +Processing Commit 535/6895 - Commit ID: 11318ba8cafd59105637b2b82b8a32719e44a2d2 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 11318ba8cafd59105637b2b82b8a32719e44a2d2 + Author Name: Jakub Sitnicki + Author Email: jakub@cloudflare.com + Commit Date: 1582320585 + Commit Message: + selftests/bpf: Extend SK_REUSEPORT tests to cover SOCKMAP/SOCKHASH Parametrize the SK_REUSEPORT tests so that the map type for storing sockets is not hard-coded in the test setup routine. This, together with careful state cleaning after the tests, lets us run the test cases for REUSEPORT_ARRAY, SOCKMAP, and SOCKHASH to have test coverage for all supported map types. The last two support only TCP sockets at the moment. Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200218171023.844439-11-jakub@cloudflare.com + Changed Files: .../selftests/bpf/prog_tests/select_reuseport.c | 63 ++++++++++++++++++----; 1 file changed, 53 insertions(+), 10 deletions(-) + Parent Hashes: 035ff358f2d9e2f5e1639ba4defe4dc40ac642dd +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit extends SK_REUSEPORT tests to also cover SOCKMAP and SOCKHASH map types for socket storage.", + "keywords": "SK_REUSEPORT, SOCKMAP, SOCKHASH", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "The commit extends SK_REUSEPORT test coverage to include SOCKMAP and SOCKHASH types by parameterizing the map type.", + "keywords": "SK_REUSEPORT, SOCKMAP, SOCKHASH", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 536/6895 - Commit ID: 035ff358f2d9e2f5e1639ba4defe4dc40ac642dd +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 035ff358f2d9e2f5e1639ba4defe4dc40ac642dd + Author Name: Jakub Sitnicki + Author Email: jakub@cloudflare.com + Commit Date: 1582320585 + Commit Message: + net: Generate reuseport group ID on group creation Commit 736b46027eb4 ("net: Add ID (if needed) to sock_reuseport and expose reuseport_lock") has introduced lazy generation of reuseport group IDs that survive group resize. By comparing the identifier we check if BPF reuseport program is not trying to select a socket from a BPF map that belongs to a different reuseport group than the one the packet is for. Because SOCKARRAY used to be the only BPF map type that can be used with reuseport BPF, it was possible to delay the generation of reuseport group ID until a socket from the group was inserted into BPF map for the first time. Now that SOCK{MAP,HASH} can be used with reuseport BPF we have two options, either generate the reuseport ID on map update, like SOCKARRAY does, or allocate an ID from the start when reuseport group gets created. This patch takes the latter approach to keep sockmap free of calls into reuseport code. This streamlines the reuseport_id access as its lifetime now matches the longevity of reuseport object. The cost of this simplification, however, is that we allocate reuseport IDs for all SO_REUSEPORT users. Even those that don't use SOCKARRAY in their setups. With the way identifiers are currently generated, we can have at most S32_MAX reuseport groups, which hopefully is sufficient. If we ever get close to the limit, we can switch an u64 counter like sk_cookie. Another change is that we now always call into SOCKARRAY logic to unlink the socket from the map when unhashing or closing the socket. Previously we did it only when at least one socket from the group was in a BPF map. It is worth noting that this doesn't conflict with sockmap tear-down in case a socket is in a SOCK{MAP,HASH} and belongs to a reuseport group. sockmap tear-down happens first: prot->unhash `- tcp_bpf_unhash |- tcp_bpf_remove | `- while (sk_psock_link_pop(psock)) | `- sk_psock_unlink | `- sock_map_delete_from_link | `- __sock_map_delete | `- sock_map_unref | `- sk_psock_put | `- sk_psock_drop | `- rcu_assign_sk_user_data(sk, NULL) `- inet_unhash `- reuseport_detach_sock `- bpf_sk_reuseport_detach `- WRITE_ONCE(sk->sk_user_data, NULL) Suggested-by: Martin Lau Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200218171023.844439-10-jakub@cloudflare.com + Changed Files: include/net/sock_reuseport.h | 2 --; kernel/bpf/reuseport_array.c | 5 -----; net/core/filter.c | 12 +----------; net/core/sock_reuseport.c | 50 +++++++++++++++++++-------------------------; 4 files changed, 22 insertions(+), 47 deletions(-) + Parent Hashes: 9fed9000c5c6cacfcaaa48aff74818072ae294cc +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit generates reuseport group IDs during group creation to streamline reuseport ID access and avoid calls into reuseport code by sockmap.", + "keywords": "reuseport, group, ID", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "The commit generates reuseport group IDs during group creation to streamline reuseport ID access and avoid calls into reuseport code by sockmap.", + "keywords": "reuseport, group, ID", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 537/6895 - Commit ID: 9fed9000c5c6cacfcaaa48aff74818072ae294cc +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 9fed9000c5c6cacfcaaa48aff74818072ae294cc + Author Name: Jakub Sitnicki + Author Email: jakub@cloudflare.com + Commit Date: 1582320585 + Commit Message: + bpf: Allow selecting reuseport socket from a SOCKMAP/SOCKHASH SOCKMAP & SOCKHASH now support storing references to listening sockets. Nothing keeps us from using these map types a collection of sockets to select from in BPF reuseport programs. Whitelist the map types with the bpf_sk_select_reuseport helper. The restriction that the socket has to be a member of a reuseport group still applies. Sockets in SOCKMAP/SOCKHASH that don't have sk_reuseport_cb set are not a valid target and we signal it with -EINVAL. The main benefit from this change is that, in contrast to REUSEPORT_SOCKARRAY, SOCK{MAP,HASH} don't impose a restriction that a listening socket can be just one BPF map at the same time. Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200218171023.844439-9-jakub@cloudflare.com + Changed Files: kernel/bpf/verifier.c | 10 +++++++---; net/core/filter.c | 15 ++++++++++-----; 2 files changed, 17 insertions(+), 8 deletions(-) + Parent Hashes: 1d59f3bcee356caa933646dc45ff0836455535e8 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit allows using SOCKMAP and SOCKHASH for selecting reuseport sockets in BPF programs.", + "keywords": "SOCKMAP, SOCKHASH, reuseport", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "This commit allows using SOCKMAP and SOCKHASH for selecting reuseport sockets in BPF programs.", + "keywords": "SOCKMAP, SOCKHASH, reuseport", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 538/6895 - Commit ID: 1d59f3bcee356caa933646dc45ff0836455535e8 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 1d59f3bcee356caa933646dc45ff0836455535e8 + Author Name: Jakub Sitnicki + Author Email: jakub@cloudflare.com + Commit Date: 1582320585 + Commit Message: + bpf, sockmap: Let all kernel-land lookup values in SOCKMAP/SOCKHASH Don't require the kernel code, like BPF helpers, that needs access to SOCK{MAP,HASH} map contents to live in net/core/sock_map.c. Expose the lookup operation to all kernel-land. Lookup from BPF context is not whitelisted yet. While syscalls have a dedicated lookup handler. Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200218171023.844439-8-jakub@cloudflare.com + Changed Files: net/core/sock_map.c | 9 +++++++--; 1 file changed, 7 insertions(+), 2 deletions(-) + Parent Hashes: c1cdf65da060a8e047a9f4433306fd6dac1f51a6 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Expose SOCKMAP/SOCKHASH lookup operation to kernel code outside net/core/sock_map.c.", + "keywords": "SOCKMAP SOCKHASH lookup", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Expose SOCKMAP/SOCKHASH lookup operation to kernel code outside net/core/sock_map.c.", + "keywords": "SOCKMAP SOCKHASH lookup", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 539/6895 - Commit ID: c1cdf65da060a8e047a9f4433306fd6dac1f51a6 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: c1cdf65da060a8e047a9f4433306fd6dac1f51a6 + Author Name: Jakub Sitnicki + Author Email: jakub@cloudflare.com + Commit Date: 1582320585 + Commit Message: + bpf, sockmap: Return socket cookie on lookup from syscall Tooling that populates the SOCK{MAP,HASH} with sockets from user-space needs a way to inspect its contents. Returning the struct sock * that the map holds to user-space is neither safe nor useful. An approach established by REUSEPORT_SOCKARRAY is to return a socket cookie (a unique identifier) instead. Since socket cookies are u64 values, SOCK{MAP,HASH} need to support such a value size for lookup to be possible. This requires special handling on update, though. Attempts to do a lookup on a map holding u32 values will be met with ENOSPC error. Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200218171023.844439-7-jakub@cloudflare.com + Changed Files: net/core/sock_map.c | 57 +++++++++++++++++++++++++++++++++++++++++++++++++----; 1 file changed, 53 insertions(+), 4 deletions(-) + Parent Hashes: 6e830c2f6c9641217e22330cec1372acff78dcef +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit enables the sockmap to return a socket cookie as a unique identifier during user-space lookup operations.", + "keywords": "sockmap,cookie,lookup", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "This commit enables the sockmap to return a socket cookie as a unique identifier during user-space lookup operations.", + "keywords": "sockmap,cookie,lookup", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 540/6895 - Commit ID: 6e830c2f6c9641217e22330cec1372acff78dcef +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 6e830c2f6c9641217e22330cec1372acff78dcef + Author Name: Jakub Sitnicki + Author Email: jakub@cloudflare.com + Commit Date: 1582320585 + Commit Message: + bpf, sockmap: Don't set up upcalls and progs for listening sockets Now that sockmap/sockhash can hold listening sockets, when setting up the psock we will (i) grab references to verdict/parser progs, and (2) override socket upcalls sk_data_ready and sk_write_space. However, since we cannot redirect to listening sockets so we don't need to link the socket to the BPF progs. And more importantly we don't want the listening socket to have overridden upcalls because they would get inherited by child sockets cloned from it. Introduce a separate initialization path for listening sockets that does not change the upcalls and ignores the BPF progs. Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200218171023.844439-6-jakub@cloudflare.com + Changed Files: net/core/sock_map.c | 52 +++++++++++++++++++++++++++++++++++++++++++++-------; 1 file changed, 45 insertions(+), 7 deletions(-) + Parent Hashes: 8ca30379a40103bf6734ae127ec940da798534dd +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit separates the initialization path for listening sockets from others to prevent BPF program references and upcalls on them in sockmap/sockhash.", + "keywords": "sockmap,sockets,upcalls", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "This commit separates initialization for listening sockets to avoid links to BPF programs in sockmap/sockhash.", + "keywords": "sockmap,upcalls,sockets", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 541/6895 - Commit ID: 8ca30379a40103bf6734ae127ec940da798534dd +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 8ca30379a40103bf6734ae127ec940da798534dd + Author Name: Jakub Sitnicki + Author Email: jakub@cloudflare.com + Commit Date: 1582320585 + Commit Message: + bpf, sockmap: Allow inserting listening TCP sockets into sockmap In order for sockmap/sockhash types to become generic collections for storing TCP sockets we need to loosen the checks during map update, while tightening the checks in redirect helpers. Currently sock{map,hash} require the TCP socket to be in established state, which prevents inserting listening sockets. Change the update pre-checks so the socket can also be in listening state. Since it doesn't make sense to redirect with sock{map,hash} to listening sockets, add appropriate socket state checks to BPF redirect helpers too. Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200218171023.844439-5-jakub@cloudflare.com + Changed Files: net/core/sock_map.c | 59 ++++++++++++++++++++++++---------; tools/testing/selftests/bpf/test_maps.c | 6 +---; 2 files changed, 45 insertions(+), 20 deletions(-) + Parent Hashes: e80251555f0befd1271e74b080bccf0ff0348bfc +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit allows listening TCP sockets to be inserted into sockmap improving generic collection capabilities.", + "keywords": "bpf,sockmap,TCP", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "This commit allows the insertion of listening TCP sockets into sockmap, enhancing generic collection capabilities.", + "keywords": "bpf,sockmap,TCP", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 542/6895 - Commit ID: e80251555f0befd1271e74b080bccf0ff0348bfc +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: e80251555f0befd1271e74b080bccf0ff0348bfc + Author Name: Jakub Sitnicki + Author Email: jakub@cloudflare.com + Commit Date: 1582320585 + Commit Message: + tcp_bpf: Don't let child socket inherit parent protocol ops on copy Prepare for cloning listening sockets that have their protocol callbacks overridden by sk_msg. Child sockets must not inherit parent callbacks that access state stored in sk_user_data owned by the parent. Restore the child socket protocol callbacks before it gets hashed and any of the callbacks can get invoked. Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200218171023.844439-4-jakub@cloudflare.com + Changed Files: include/net/tcp.h | 7 +++++++; net/ipv4/tcp_bpf.c | 14 ++++++++++++++; net/ipv4/tcp_minisocks.c | 2 ++; 3 files changed, 23 insertions(+) + Parent Hashes: f1ff5ce2cd5ef3335f19c0f6576582c87045b04f +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit prevents child sockets from inheriting parent sockets' overridden protocol operations in TCP BPF context.", + "keywords": "tcp_bpf, socket, protocol", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "The commit ensures child sockets do not inherit parent protocol callbacks in tcp_bpf to prevent state access issues.", + "keywords": "tcp_bpf,socket,protocol", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 543/6895 - Commit ID: f1ff5ce2cd5ef3335f19c0f6576582c87045b04f +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: f1ff5ce2cd5ef3335f19c0f6576582c87045b04f + Author Name: Jakub Sitnicki + Author Email: jakub@cloudflare.com + Commit Date: 1582320585 + Commit Message: + net, sk_msg: Clear sk_user_data pointer on clone if tagged sk_user_data can hold a pointer to an object that is not intended to be shared between the parent socket and the child that gets a pointer copy on clone. This is the case when sk_user_data points at reference-counted object, like struct sk_psock. One way to resolve it is to tag the pointer with a no-copy flag by repurposing its lowest bit. Based on the bit-flag value we clear the child sk_user_data pointer after cloning the parent socket. The no-copy flag is stored in the pointer itself as opposed to externally, say in socket flags, to guarantee that the pointer and the flag are copied from parent to child socket in an atomic fashion. Parent socket state is subject to change while copying, we don't hold any locks at that time. This approach relies on an assumption that sk_user_data holds a pointer to an object aligned at least 2 bytes. A manual audit of existing users of rcu_dereference_sk_user_data helper confirms our assumption. Also, an RCU-protected sk_user_data is not likely to hold a pointer to a char value or a pathological case of "struct { char c; }". To be safe, warn when the flag-bit is set when setting sk_user_data to catch any future misuses. It is worth considering why clearing sk_user_data unconditionally is not an option. There exist users, DRBD, NVMe, and Xen drivers being among them, that rely on the pointer being copied when cloning the listening socket. Potentially we could distinguish these users by checking if the listening socket has been created in kernel-space via sock_create_kern, and hence has sk_kern_sock flag set. However, this is not the case for NVMe and Xen drivers, which create sockets without marking them as belonging to the kernel. Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200218171023.844439-3-jakub@cloudflare.com + Changed Files: include/net/sock.h | 37 +++++++++++++++++++++++++++++++++++--; net/core/skmsg.c | 2 +-; net/core/sock.c | 6 ++++++; 3 files changed, 42 insertions(+), 3 deletions(-) + Parent Hashes: b8e202d1d1d0f182f01062804efb523ea9a9008c +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit clears sk_user_data on socket clone if a no-copy flag is set to prevent unwanted sharing.", + "keywords": "sk_user_data,clear,clone", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here." + ] +} +Rethinking... +new content: +{ + "summary": "The commit tags sk_user_data with a no-copy flag to prevent undesired pointer sharing between cloned sockets.", + "keywords": "sk_user_data,no-copy,clone", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +-------------------- +-------------------- +Processing Commit 544/6895 - Commit ID: b8e202d1d1d0f182f01062804efb523ea9a9008c +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: b8e202d1d1d0f182f01062804efb523ea9a9008c + Author Name: Jakub Sitnicki + Author Email: jakub@cloudflare.com + Commit Date: 1582320585 + Commit Message: + net, sk_msg: Annotate lockless access to sk_prot on clone sk_msg and ULP frameworks override protocol callbacks pointer in sk->sk_prot, while tcp accesses it locklessly when cloning the listening socket, that is with neither sk_lock nor sk_callback_lock held. Once we enable use of listening sockets with sockmap (and hence sk_msg), there will be shared access to sk->sk_prot if socket is getting cloned while being inserted/deleted to/from the sockmap from another CPU: Read side: tcp_v4_rcv sk = __inet_lookup_skb(...) tcp_check_req(sk) inet_csk(sk)->icsk_af_ops->syn_recv_sock tcp_v4_syn_recv_sock tcp_create_openreq_child inet_csk_clone_lock sk_clone_lock READ_ONCE(sk->sk_prot) Write side: sock_map_ops->map_update_elem sock_map_update_elem sock_map_update_common sock_map_link_no_progs tcp_bpf_init tcp_bpf_update_sk_prot sk_psock_update_proto WRITE_ONCE(sk->sk_prot, ops) sock_map_ops->map_delete_elem sock_map_delete_elem __sock_map_delete sock_map_unref sk_psock_put sk_psock_drop sk_psock_restore_proto tcp_update_ulp WRITE_ONCE(sk->sk_prot, proto) Mark the shared access with READ_ONCE/WRITE_ONCE annotations. Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200218171023.844439-2-jakub@cloudflare.com + Changed Files: include/linux/skmsg.h | 3 ++-; net/core/sock.c | 8 +++++---; net/ipv4/tcp_bpf.c | 4 +++-; net/ipv4/tcp_ulp.c | 3 ++-; net/tls/tls_main.c | 3 ++-; 5 files changed, 14 insertions(+), 7 deletions(-) + Parent Hashes: e42da4c62abb547d9c9138e0e7fcd1f36057b5e8 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit annotates lockless access to sk->sk_prot during socket cloning to ensure safe concurrent access in the sk_msg and ULP frameworks with sockmap.", + "keywords": "lockless, sk_prot, clone", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds annotations for lockless access to sk->sk_prot during socket cloning to prevent race conditions with sk_msg and ULP frameworks.", + "keywords": "lockless, sk_prot, annotations", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 545/6895 - Commit ID: 3dc55dba67231fc22352483f5ca737df96cdc1e6 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 3dc55dba67231fc22352483f5ca737df96cdc1e6 + Author Name: Linus Torvalds + Author Email: torvalds@linux-foundation.org + Commit Date: 1582315191 + Commit Message: + Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from David Miller: 1) Limit xt_hashlimit hash table size to avoid OOM or hung tasks, from Cong Wang. 2) Fix deadlock in xsk by publishing global consumer pointers when NAPI is finished, from Magnus Karlsson. 3) Set table field properly to RT_TABLE_COMPAT when necessary, from Jethro Beekman. 4) NLA_STRING attributes are not necessary NULL terminated, deal wiht that in IFLA_ALT_IFNAME. From Eric Dumazet. 5) Fix checksum handling in atlantic driver, from Dmitry Bezrukov. 6) Handle mtu==0 devices properly in wireguard, from Jason A. Donenfeld. 7) Fix several lockdep warnings in bonding, from Taehee Yoo. 8) Fix cls_flower port blocking, from Jason Baron. 9) Sanitize internal map names in libbpf, from Toke Høiland-Jørgensen. 10) Fix RDMA race in qede driver, from Michal Kalderon. 11) Fix several false lockdep warnings by adding conditions to list_for_each_entry_rcu(), from Madhuparna Bhowmik. 12) Fix sleep in atomic in mlx5 driver, from Huy Nguyen. 13) Fix potential deadlock in bpf_map_do_batch(), from Yonghong Song. 14) Hey, variables declared in switch statement before any case statements are not initialized. I learn something every day. Get rids of this stuff in several parts of the networking, from Kees Cook. * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (99 commits) bnxt_en: Issue PCIe FLR in kdump kernel to cleanup pending DMAs. bnxt_en: Improve device shutdown method. net: netlink: cap max groups which will be considered in netlink_bind() net: thunderx: workaround BGX TX Underflow issue ionic: fix fw_status read net: disable BRIDGE_NETFILTER by default net: macb: Properly handle phylink on at91rm9200 s390/qeth: fix off-by-one in RX copybreak check s390/qeth: don't warn for napi with 0 budget s390/qeth: vnicc Fix EOPNOTSUPP precedence openvswitch: Distribute switch variables for initialization net: ip6_gre: Distribute switch variables for initialization net: core: Distribute switch variables for initialization udp: rehash on disconnect net/tls: Fix to avoid gettig invalid tls record bpf: Fix a potential deadlock with bpf_map_do_batch bpf: Do not grab the bucket spinlock by default on htab batch ops ice: Wait for VF to be reset/ready before configuration ice: Don't tell the OS that link is going down ice: Don't reject odd values of usecs set by user ... + Changed Files: nan + Parent Hashes: b0dd1eb220c06892e0a4098378c4296650f3f8db 36a44bcdd8df092d76c11bc213e81c5817d4e302 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Merge networking fixes including hash table size limitation, lockdep warnings resolution, and deadlock prevention in networking components from various contributors.", + "keywords": "Merge,networking,fixes", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "Merge networking fixes including deadlock prevention, lockdep warnings resolution, and adjustments in networking components from various contributors.", + "keywords": "Merge,networking,fixes", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 546/6895 - Commit ID: e42da4c62abb547d9c9138e0e7fcd1f36057b5e8 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: e42da4c62abb547d9c9138e0e7fcd1f36057b5e8 + Author Name: Yonghong Song + Author Email: yhs@fb.com + Commit Date: 1582250737 + Commit Message: + docs/bpf: Update bpf development Q/A file bpf now has its own mailing list bpf@vger.kernel.org. Update the bpf_devel_QA.rst file to reflect this. Also llvm has switch to github with llvm and clang in the same repo https://github.com/llvm/llvm-project.git. Update the QA file with newer build instructions. Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200221004354.930952-1-yhs@fb.com + Changed Files: Documentation/bpf/bpf_devel_QA.rst | 29 ++++++++++++-----------------; 1 file changed, 12 insertions(+), 17 deletions(-) + Parent Hashes: 006ed53e8caa0b3c1e21a51dc34d6b3b5ab0aab6 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit updates the eBPF development Q/A document with new mailing list and LLVM GitHub repository details.", + "keywords": "documentation, mailing, LLVM", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit updates the bpf_devel_QA.rst file to reflect new mailing list and LLVM GitHub repository details.", + "keywords": "bpf_development, mailing_list, LLVM", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 547/6895 - Commit ID: 006ed53e8caa0b3c1e21a51dc34d6b3b5ab0aab6 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 006ed53e8caa0b3c1e21a51dc34d6b3b5ab0aab6 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1582250590 + Commit Message: + selftests/bpf: Fix trampoline_count clean up logic Libbpf's Travis CI tests caught this issue. Ensure bpf_link and bpf_object clean up is performed correctly. Fixes: d633d57902a5 ("selftest/bpf: Add test for allowed trampolines count") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Cc: Jiri Olsa Link: https://lore.kernel.org/bpf/20200220230546.769250-1-andriin@fb.com + Changed Files: .../selftests/bpf/prog_tests/trampoline_count.c | 25 ++++++++++++++++------; 1 file changed, 18 insertions(+), 7 deletions(-) + Parent Hashes: 2c3a368127e1b56b32e147971ab804176ff4c9f3 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes cleanup logic for trampoline_count in bpf selftests as caught by Libbpf's Travis CI.", + "keywords": "selftests,bpf,trampoline_count", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes cleanup logic for trampoline_count in bpf selftests as caught by Libbpf's Travis CI.", + "keywords": "selftests,bpf,trampoline_count", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 548/6895 - Commit ID: 2c3a368127e1b56b32e147971ab804176ff4c9f3 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 2c3a368127e1b56b32e147971ab804176ff4c9f3 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1582249900 + Commit Message: + Merge branch 'set_attach_target' Eelco Chaudron says: ==================== Currently when you want to attach a trace program to a bpf program the section name needs to match the tracepoint/function semantics. However the addition of the bpf_program__set_attach_target() API allows you to specify the tracepoint/function dynamically. The call flow would look something like this: xdp_fd = bpf_prog_get_fd_by_id(id); trace_obj = bpf_object__open_file("func.o", NULL); prog = bpf_object__find_program_by_title(trace_obj, "fentry/myfunc"); bpf_program__set_expected_attach_type(prog, BPF_TRACE_FENTRY); bpf_program__set_attach_target(prog, xdp_fd, "xdpfilt_blk_all"); bpf_object__load(trace_obj) v1 -> v2: Remove requirement for attach type hint in API v2 -> v3: Moved common warning to __find_vmlinux_btf_id, requested by Andrii Updated the xdp_bpf2bpf test to use this new API v3 -> v4: Split up patch, update libbpf.map version v4 -> v5: Fix return code, and prog assignment in test case ==================== Signed-off-by: Alexei Starovoitov + Changed Files: nan + Parent Hashes: 5327644614a18f5d0ff845844a4e9976210b3d8d 933ce62d68dee5465cb5f5b359ab0638c9f665b1 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit merges changes to dynamically specify tracepoint/function targets when attaching a trace program to a BPF program using new APIs.", + "keywords": "merge, tracepoint, API", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "The commit involves merging a branch that introduces APIs for dynamically setting tracepoint/function targets for BPF program attachments.", + "keywords": "merge, tracepoint, API", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 549/6895 - Commit ID: 933ce62d68dee5465cb5f5b359ab0638c9f665b1 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 933ce62d68dee5465cb5f5b359ab0638c9f665b1 + Author Name: Eelco Chaudron + Author Email: echaudro@redhat.com + Commit Date: 1582249720 + Commit Message: + selftests/bpf: Update xdp_bpf2bpf test to use new set_attach_target API Use the new bpf_program__set_attach_target() API in the xdp_bpf2bpf selftest so it can be referenced as an example on how to use it. Signed-off-by: Eelco Chaudron Signed-off-by: Alexei Starovoitov Acked-by: Toke Høiland-Jørgensen Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/158220520562.127661.14289388017034825841.stgit@xdp-tutorial + Changed Files: tools/testing/selftests/bpf/prog_tests/xdp_bpf2bpf.c | 16 +++++++++++++---; tools/testing/selftests/bpf/progs/test_xdp_bpf2bpf.c | 4 ++--; 2 files changed, 15 insertions(+), 5 deletions(-) + Parent Hashes: ff26ce5cd7680ebc9c5446cda013e2087decc60f +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit updates xdp_bpf2bpf test to utilize the new set_attach_target API in BPF selftests.", + "keywords": "xdp_bpf2bpf,set_attach_target,selftests", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +Rethinking... +new content: +{ + "summary": "The commit updates xdp_bpf2bpf test to utilize the new set_attach_target API in BPF selftests.", + "keywords": "xdp_bpf2bpf,set_attach_target,selftests", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +-------------------- +-------------------- +Processing Commit 550/6895 - Commit ID: ff26ce5cd7680ebc9c5446cda013e2087decc60f +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: ff26ce5cd7680ebc9c5446cda013e2087decc60f + Author Name: Eelco Chaudron + Author Email: echaudro@redhat.com + Commit Date: 1582249720 + Commit Message: + libbpf: Add support for dynamic program attach target Currently when you want to attach a trace program to a bpf program the section name needs to match the tracepoint/function semantics. However the addition of the bpf_program__set_attach_target() API allows you to specify the tracepoint/function dynamically. The call flow would look something like this: xdp_fd = bpf_prog_get_fd_by_id(id); trace_obj = bpf_object__open_file("func.o", NULL); prog = bpf_object__find_program_by_title(trace_obj, "fentry/myfunc"); bpf_program__set_expected_attach_type(prog, BPF_TRACE_FENTRY); bpf_program__set_attach_target(prog, xdp_fd, "xdpfilt_blk_all"); bpf_object__load(trace_obj) Signed-off-by: Eelco Chaudron Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/158220519486.127661.7964708960649051384.stgit@xdp-tutorial + Changed Files: tools/lib/bpf/libbpf.c | 34 ++++++++++++++++++++++++++++++----; tools/lib/bpf/libbpf.h | 4 ++++; tools/lib/bpf/libbpf.map | 2 ++; 3 files changed, 36 insertions(+), 4 deletions(-) + Parent Hashes: dd88aed92d017bed2a2c0023f22f0eef7cd29702 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds support for dynamically specifying attach targets in libbpf for trace programs.", + "keywords": "dynamic, attach, libbpf", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds dynamic attach target support to libbpf for trace programs.", + "keywords": "dynamic, attach, libbpf", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +-------------------- +-------------------- +Processing Commit 551/6895 - Commit ID: dd88aed92d017bed2a2c0023f22f0eef7cd29702 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: dd88aed92d017bed2a2c0023f22f0eef7cd29702 + Author Name: Eelco Chaudron + Author Email: echaudro@redhat.com + Commit Date: 1582249720 + Commit Message: + libbpf: Bump libpf current version to v0.0.8 New development cycles starts, bump to v0.0.8. Signed-off-by: Eelco Chaudron Signed-off-by: Alexei Starovoitov Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/158220518424.127661.8278643006567775528.stgit@xdp-tutorial + Changed Files: tools/lib/bpf/libbpf.map | 3 +++; 1 file changed, 3 insertions(+) + Parent Hashes: 5327644614a18f5d0ff845844a4e9976210b3d8d +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit updates libbpf to version v0.0.8 to mark the start of a new development cycle.", + "keywords": "libbpf,version,update", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit updates libbpf version to v0.0.8 marking the start of a new development cycle.", + "keywords": "libbpf,version,bump", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 552/6895 - Commit ID: 5327644614a18f5d0ff845844a4e9976210b3d8d +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 5327644614a18f5d0ff845844a4e9976210b3d8d + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1582225419 + Commit Message: + libbpf: Relax check whether BTF is mandatory If BPF program is using BTF-defined maps, BTF is required only for libbpf itself to process map definitions. If after that BTF fails to be loaded into kernel (e.g., if it doesn't support BTF at all), this shouldn't prevent valid BPF program from loading. Existing retry-without-BTF logic for creating maps will succeed to create such maps without any problems. So, presence of .maps section shouldn't make BTF required for kernel. Update the check accordingly. Validated by ensuring simple BPF program with BTF-defined maps is still loaded on old kernel without BTF support and map is correctly parsed and created. Fixes: abd29c931459 ("libbpf: allow specifying map definitions using BTF") Reported-by: Julia Kartseva Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200220062635.1497872-1-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.c | 4 +---; 1 file changed, 1 insertion(+), 3 deletions(-) + Parent Hashes: 500897804a369358f4d27356787dcf9b33527fd7 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit updates libbpf to relax the requirement for BTF when loading BPF programs with BTF-defined maps on kernels without BTF support.", + "keywords": "libbpf,BTF,maps", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit updates libbpf to relax the requirement for BTF when loading BPF programs with BTF-defined maps on kernels without BTF support.", + "keywords": "libbpf,BTF,maps", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 553/6895 - Commit ID: 41f57cfde186dba6e357f9db25eafbed017e4487 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 41f57cfde186dba6e357f9db25eafbed017e4487 + Author Name: David S. Miller + Author Email: davem@davemloft.net + Commit Date: 1582159355 + Commit Message: + Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf Alexei Starovoitov says: ==================== pull-request: bpf 2020-02-19 The following pull-request contains BPF updates for your *net* tree. We've added 10 non-merge commits during the last 10 day(s) which contain a total of 10 files changed, 93 insertions(+), 31 deletions(-). The main changes are: 1) batched bpf hashtab fixes from Brian and Yonghong. 2) various selftests and libbpf fixes. ==================== Signed-off-by: David S. Miller + Changed Files: nan + Parent Hashes: fca07a937a27e720df7310bc5e68a11e5d2ff3c5 b9aff38de2cb166476988020428985c5f7412ffc +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit merges BPF updates from another branch focusing on hashtab fixes and selftests improvements.", + "keywords": "merge,hashtab,selftests", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "The commit merges BPF updates from another branch focusing on hashtab fixes and selftests improvements.", + "keywords": "merge,hashtab,selftests", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 554/6895 - Commit ID: 500897804a369358f4d27356787dcf9b33527fd7 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 500897804a369358f4d27356787dcf9b33527fd7 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1582157844 + Commit Message: + selftests/bpf: Fix build of sockmap_ktls.c The selftests fails to build with: tools/testing/selftests/bpf/prog_tests/sockmap_ktls.c: In function ‘test_sockmap_ktls_disconnect_after_delete’: tools/testing/selftests/bpf/prog_tests/sockmap_ktls.c:72:37: error: ‘TCP_ULP’ undeclared (first use in this function) 72 | err = setsockopt(cli, IPPROTO_TCP, TCP_ULP, "tls", strlen("tls")); | ^~~~~~~ Similar to commit that fixes build of sockmap_basic.c on systems with old /usr/include fix the build of sockmap_ktls.c Fixes: d1ba1204f2ee ("selftests/bpf: Test unhashing kTLS socket after removing from map") Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200219205514.3353788-1-ast@kernel.org + Changed Files: tools/testing/selftests/bpf/prog_tests/sockmap_ktls.c | 1 +; 1 file changed, 1 insertion(+) + Parent Hashes: 83250f2b6940654a73a2cfab7ac112b804a5f648 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fix the build issue of sockmap_ktls.c in eBPF selftests caused by undeclared TCP_ULP variable.", + "keywords": "fix, build, sockmap_ktls", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "Fix the build issue of sockmap_ktls.c related to undeclared TCP_ULP variable in eBPF selftests.", + "keywords": "fix, build, sockmap_ktls", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 555/6895 - Commit ID: b9aff38de2cb166476988020428985c5f7412ffc +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: b9aff38de2cb166476988020428985c5f7412ffc + Author Name: Yonghong Song + Author Email: yhs@fb.com + Commit Date: 1582156885 + Commit Message: + bpf: Fix a potential deadlock with bpf_map_do_batch Commit 057996380a42 ("bpf: Add batch ops to all htab bpf map") added lookup_and_delete batch operation for hash table. The current implementation has bpf_lru_push_free() inside the bucket lock, which may cause a deadlock. syzbot reports: -> #2 (&htab->buckets[i].lock#2){....}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x95/0xcd kernel/locking/spinlock.c:159 htab_lru_map_delete_node+0xce/0x2f0 kernel/bpf/hashtab.c:593 __bpf_lru_list_shrink_inactive kernel/bpf/bpf_lru_list.c:220 [inline] __bpf_lru_list_shrink+0xf9/0x470 kernel/bpf/bpf_lru_list.c:266 bpf_lru_list_pop_free_to_local kernel/bpf/bpf_lru_list.c:340 [inline] bpf_common_lru_pop_free kernel/bpf/bpf_lru_list.c:447 [inline] bpf_lru_pop_free+0x87c/0x1670 kernel/bpf/bpf_lru_list.c:499 prealloc_lru_pop+0x2c/0xa0 kernel/bpf/hashtab.c:132 __htab_lru_percpu_map_update_elem+0x67e/0xa90 kernel/bpf/hashtab.c:1069 bpf_percpu_hash_update+0x16e/0x210 kernel/bpf/hashtab.c:1585 bpf_map_update_value.isra.0+0x2d7/0x8e0 kernel/bpf/syscall.c:181 generic_map_update_batch+0x41f/0x610 kernel/bpf/syscall.c:1319 bpf_map_do_batch+0x3f5/0x510 kernel/bpf/syscall.c:3348 __do_sys_bpf+0x9b7/0x41e0 kernel/bpf/syscall.c:3460 __se_sys_bpf kernel/bpf/syscall.c:3355 [inline] __x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:3355 do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe -> #0 (&loc_l->lock){....}: check_prev_add kernel/locking/lockdep.c:2475 [inline] check_prevs_add kernel/locking/lockdep.c:2580 [inline] validate_chain kernel/locking/lockdep.c:2970 [inline] __lock_acquire+0x2596/0x4a00 kernel/locking/lockdep.c:3954 lock_acquire+0x190/0x410 kernel/locking/lockdep.c:4484 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x95/0xcd kernel/locking/spinlock.c:159 bpf_common_lru_push_free kernel/bpf/bpf_lru_list.c:516 [inline] bpf_lru_push_free+0x250/0x5b0 kernel/bpf/bpf_lru_list.c:555 __htab_map_lookup_and_delete_batch+0x8d4/0x1540 kernel/bpf/hashtab.c:1374 htab_lru_map_lookup_and_delete_batch+0x34/0x40 kernel/bpf/hashtab.c:1491 bpf_map_do_batch+0x3f5/0x510 kernel/bpf/syscall.c:3348 __do_sys_bpf+0x1f7d/0x41e0 kernel/bpf/syscall.c:3456 __se_sys_bpf kernel/bpf/syscall.c:3355 [inline] __x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:3355 do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe Possible unsafe locking scenario: CPU0 CPU2 ---- ---- lock(&htab->buckets[i].lock#2); lock(&l->lock); lock(&htab->buckets[i].lock#2); lock(&loc_l->lock); *** DEADLOCK *** To fix the issue, for htab_lru_map_lookup_and_delete_batch() in CPU0, let us do bpf_lru_push_free() out of the htab bucket lock. This can avoid the above deadlock scenario. Fixes: 057996380a42 ("bpf: Add batch ops to all htab bpf map") Reported-by: syzbot+a38ff3d9356388f2fb83@syzkaller.appspotmail.com Reported-by: syzbot+122b5421d14e68f29cd1@syzkaller.appspotmail.com Suggested-by: Hillf Danton Suggested-by: Martin KaFai Lau Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Reviewed-by: Jakub Sitnicki Acked-by: Brian Vazquez Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200219234757.3544014-1-yhs@fb.com + Changed Files: kernel/bpf/hashtab.c | 34 +++++++++++++++++++++++++++++++---; 1 file changed, 31 insertions(+), 3 deletions(-) + Parent Hashes: 492e0d0d6f2eb4badfd2868addf9da0f651eba0e +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes a potential deadlock in bpf_map_do_batch by moving bpf_lru_push_free outside the lock to avoid the issue.", + "keywords": "deadlock, batch operations, htab", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes a potential deadlock in bpf_map_do_batch related to lock operations in eBPF hash table maps.", + "keywords": "deadlock, lock, hash table", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 556/6895 - Commit ID: 492e0d0d6f2eb4badfd2868addf9da0f651eba0e +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 492e0d0d6f2eb4badfd2868addf9da0f651eba0e + Author Name: Brian Vazquez + Author Email: brianvv@google.com + Commit Date: 1582156770 + Commit Message: + bpf: Do not grab the bucket spinlock by default on htab batch ops Grabbing the spinlock for every bucket even if it's empty, was causing significant perfomance cost when traversing htab maps that have only a few entries. This patch addresses the issue by checking first the bucket_cnt, if the bucket has some entries then we go and grab the spinlock and proceed with the batching. Tested with a htab of size 50K and different value of populated entries. Before: Benchmark Time(ns) CPU(ns) --------------------------------------------- BM_DumpHashMap/1 2759655 2752033 BM_DumpHashMap/10 2933722 2930825 BM_DumpHashMap/200 3171680 3170265 BM_DumpHashMap/500 3639607 3635511 BM_DumpHashMap/1000 4369008 4364981 BM_DumpHashMap/5k 11171919 11134028 BM_DumpHashMap/20k 69150080 69033496 BM_DumpHashMap/39k 190501036 190226162 After: Benchmark Time(ns) CPU(ns) --------------------------------------------- BM_DumpHashMap/1 202707 200109 BM_DumpHashMap/10 213441 210569 BM_DumpHashMap/200 478641 472350 BM_DumpHashMap/500 980061 967102 BM_DumpHashMap/1000 1863835 1839575 BM_DumpHashMap/5k 8961836 8902540 BM_DumpHashMap/20k 69761497 69322756 BM_DumpHashMap/39k 187437830 186551111 Fixes: 057996380a42 ("bpf: Add batch ops to all htab bpf map") Signed-off-by: Brian Vazquez Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200218172552.215077-1-brianvv@google.com + Changed Files: kernel/bpf/hashtab.c | 24 ++++++++++++++++++++++--; 1 file changed, 22 insertions(+), 2 deletions(-) + Parent Hashes: 113e6b7e15e23dc45d5c66eb66bb91a627812e36 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit optimizes htab batch operations by avoiding unnecessary spinlock acquisition, significantly improving performance for maps with few entries.", + "keywords": "htab, spinlock, optimization", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit optimizes htab batch operations by avoiding unnecessary spinlock acquisition, significantly improving performance for maps with few entries.", + "keywords": "htab, spinlock, optimization", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 557/6895 - Commit ID: 83250f2b6940654a73a2cfab7ac112b804a5f648 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 83250f2b6940654a73a2cfab7ac112b804a5f648 + Author Name: Yonghong Song + Author Email: yhs@fb.com + Commit Date: 1582154107 + Commit Message: + selftests/bpf: Change llvm flag -mcpu=probe to -mcpu=v3 The latest llvm supports cpu version v3, which is cpu version v1 plus some additional 64bit jmp insns and 32bit jmp insn support. In selftests/bpf Makefile, the llvm flag -mcpu=probe did runtime probe into the host system. Depending on compilation environments, it is possible that runtime probe may fail, e.g., due to memlock issue. This will cause generated code with cpu version v1. This may cause confusion as the same compiler and the same C code generates different byte codes in different environment. Let us change the llvm flag -mcpu=probe to -mcpu=v3 so the generated code will be the same regardless of the compilation environment. Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200219004236.2291125-1-yhs@fb.com + Changed Files: tools/testing/selftests/bpf/Makefile | 4 ++--; 1 file changed, 2 insertions(+), 2 deletions(-) + Parent Hashes: 03aa39558e74649b8ad19b2a3988a22bef23a517 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit changes the LLVM flag from -mcpu=probe to -mcpu=v3 in selftests to ensure consistent code generation across environments.", + "keywords": "LLVM,selftests,Makefile", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "The commit updates the LLVM flag in selftests to ensure consistent code generation by using -mcpu=v3 instead of -mcpu=probe.", + "keywords": "LLVM,Makefile,selftests", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 558/6895 - Commit ID: 03aa39558e74649b8ad19b2a3988a22bef23a517 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 03aa39558e74649b8ad19b2a3988a22bef23a517 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1582153272 + Commit Message: + Merge branch 'bpf_read_branch_records' Daniel Xu says: ==================== Branch records are a CPU feature that can be configured to record certain branches that are taken during code execution. This data is particularly interesting for profile guided optimizations. perf has had branch record support for a while but the data collection can be a bit coarse grained. We (Facebook) have seen in experiments that associating metadata with branch records can improve results (after postprocessing). We generally use bpf_probe_read_*() to get metadata out of userspace. That's why bpf support for branch records is useful. Aside from this particular use case, having branch data available to bpf progs can be useful to get stack traces out of userspace applications that omit frame pointers. Changes in v8: - Use globals instead of perf buffer - Call test_perf_branches__detach() before destroying skeleton - Fix typo in docs Changes in v7: - Const-ify and static-ify local var - Documentation formatting Changes in v6: - Move #ifdef a little to avoid unused variable warnings on !x86 - Test negative condition in selftest (-EINVAL on improperly configured perf event) - Skip positive condition selftest on setups that don't support branch records Changes in v5: - Rename bpf_perf_prog_read_branches() -> bpf_read_branch_records() - Rename BPF_F_GET_BR_SIZE -> BPF_F_GET_BRANCH_RECORDS_SIZE - Squash tools/ bpf.h sync into selftest commit Changes in v4: - Add BPF_F_GET_BR_SIZE flag - Return -ENOENT on unsupported architectures - Only accept initialized memory in helper - Check buffer size is multiple of sizeof(struct perf_branch_entry) - Use bpf skeleton in selftest - Add commit messages - Spelling and formatting Changes in v3: - Document filling unused buffer with zero - Formatting fixes - Rebase Changes in v2: - Change to a bpf helper instead of context access - Avoid mentioning Intel specific things ==================== Signed-off-by: Alexei Starovoitov + Changed Files: nan + Parent Hashes: 2f14b2d9dd80427a1c07451b623afb8b85efef21 67306f84ca78c2ca5136f21791710c126a55a19b +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This merge commit integrates support for branch records into eBPF, enhancing profiling and stack tracing capabilities.", + "keywords": "branch,metadata,eBPF", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Profile related type programs. It affects programs used for profiling system or application performance.", + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here." + ] +} +Rethinking... +new content: +{ + "summary": "This merge commit integrates support for branch records into eBPF.", + "keywords": "branch,metadata,eBPF", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Profile related type programs. It affects programs used for profiling system or application performance.", + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here." + ] +} +-------------------- +-------------------- +Processing Commit 559/6895 - Commit ID: 67306f84ca78c2ca5136f21791710c126a55a19b +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 67306f84ca78c2ca5136f21791710c126a55a19b + Author Name: Daniel Xu + Author Email: dxu@dxuuu.xyz + Commit Date: 1582153267 + Commit Message: + selftests/bpf: Add bpf_read_branch_records() selftest Add a selftest to test: * default bpf_read_branch_records() behavior * BPF_F_GET_BRANCH_RECORDS_SIZE flag behavior * error path on non branch record perf events * using helper to write to stack * using helper to write to global On host with hardware counter support: # ./test_progs -t perf_branches #27/1 perf_branches_hw:OK #27/2 perf_branches_no_hw:OK #27 perf_branches:OK Summary: 1/2 PASSED, 0 SKIPPED, 0 FAILED On host without hardware counter support (VM): # ./test_progs -t perf_branches #27/1 perf_branches_hw:OK #27/2 perf_branches_no_hw:OK #27 perf_branches:OK Summary: 1/2 PASSED, 1 SKIPPED, 0 FAILED Also sync tools/include/uapi/linux/bpf.h. Signed-off-by: Daniel Xu Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200218030432.4600-3-dxu@dxuuu.xyz + Changed Files: tools/include/uapi/linux/bpf.h | 25 ++-; .../selftests/bpf/prog_tests/perf_branches.c | 170 +++++++++++++++++++++; .../selftests/bpf/progs/test_perf_branches.c | 50 ++++++; 3 files changed, 244 insertions(+), 1 deletion(-) + Parent Hashes: fff7b64355eac6e29b50229ad1512315bc04b44e +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds a selftest for bpf_read_branch_records and synchronizes tools/include/uapi/linux/bpf.h.", + "keywords": "selftest, perf_events, synchronization", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds a selftest for bpf_read_branch_records and synchronizes tools/include/uapi/linux/bpf.h.", + "keywords": "selftest, perf_events, synchronization", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 560/6895 - Commit ID: fff7b64355eac6e29b50229ad1512315bc04b44e +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: fff7b64355eac6e29b50229ad1512315bc04b44e + Author Name: Daniel Xu + Author Email: dxu@dxuuu.xyz + Commit Date: 1582151856 + Commit Message: + bpf: Add bpf_read_branch_records() helper Branch records are a CPU feature that can be configured to record certain branches that are taken during code execution. This data is particularly interesting for profile guided optimizations. perf has had branch record support for a while but the data collection can be a bit coarse grained. We (Facebook) have seen in experiments that associating metadata with branch records can improve results (after postprocessing). We generally use bpf_probe_read_*() to get metadata out of userspace. That's why bpf support for branch records is useful. Aside from this particular use case, having branch data available to bpf progs can be useful to get stack traces out of userspace applications that omit frame pointers. Signed-off-by: Daniel Xu Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200218030432.4600-2-dxu@dxuuu.xyz + Changed Files: include/uapi/linux/bpf.h | 25 ++++++++++++++++++++++++-; kernel/trace/bpf_trace.c | 41 +++++++++++++++++++++++++++++++++++++++++; 2 files changed, 65 insertions(+), 1 deletion(-) + Parent Hashes: 2f14b2d9dd80427a1c07451b623afb8b85efef21 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds the bpf_read_branch_records() helper to support branch record data collection in eBPF programs for optimization purposes.", + "keywords": "bpf,branch,records", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Profile related type programs. It affects programs used for profiling system or application performance.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit introduces a new helper bpf_read_branch_records() for branch record data collection in eBPF.", + "keywords": "bpf,branch,helper", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Profile related type programs. It affects programs used for profiling system or application performance.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 561/6895 - Commit ID: 2f14b2d9dd80427a1c07451b623afb8b85efef21 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 2f14b2d9dd80427a1c07451b623afb8b85efef21 + Author Name: Daniel Borkmann + Author Email: daniel@iogearbox.net + Commit Date: 1582127664 + Commit Message: + Merge branch 'bpf-skmsg-simplify-restore' Jakub Sitnicki says: ==================== This series has been split out from "Extend SOCKMAP to store listening sockets" [0]. I think it stands on its own, and makes the latter series smaller, which will make the review easier, hopefully. The essence is that we don't need to do a complicated dance in sk_psock_restore_proto, if we agree that the contract with tcp_update_ulp is to restore callbacks even when the socket doesn't use ULP. This is what tcp_update_ulp currently does, and we just make use of it. Series is accompanied by a test for a particularly tricky case of restoring callbacks when we have both sockmap and tls callbacks configured in sk->sk_prot. [0] https://lore.kernel.org/bpf/20200127131057.150941-1-jakub@cloudflare.com/ ==================== Signed-off-by: Daniel Borkmann + Changed Files: nan + Parent Hashes: b80b033bedae68dae8fc703ab8a69811ce678f2e d1ba1204f2eec134937cb32997ee47756d448aa2 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit merges changes that simplify sk_psock_restore_proto in the eBPF subsystem to enhance socket handling.", + "keywords": "merge,socket,simplify", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's likely a merge commit. It involves changes across multiple use cases or events.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +Rethinking... +new content: +{ + "summary": "The commit merges a branch simplifying sk_psock_restore_proto to improve handling of socket callbacks without complex dances.", + "keywords": "merge,simplify,socket", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's likely a merge commit. It involves changes across multiple use cases or events.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +-------------------- +-------------------- +Processing Commit 562/6895 - Commit ID: d1ba1204f2eec134937cb32997ee47756d448aa2 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: d1ba1204f2eec134937cb32997ee47756d448aa2 + Author Name: Jakub Sitnicki + Author Email: jakub@cloudflare.com + Commit Date: 1582127645 + Commit Message: + selftests/bpf: Test unhashing kTLS socket after removing from map When a TCP socket gets inserted into a sockmap, its sk_prot callbacks get replaced with tcp_bpf callbacks built from regular tcp callbacks. If TLS gets enabled on the same socket, sk_prot callbacks get replaced once again, this time with kTLS callbacks built from tcp_bpf callbacks. Now, we allow removing a socket from a sockmap that has kTLS enabled. After removal, socket remains with kTLS configured. This is where things things get tricky. Since the socket has a set of sk_prot callbacks that are a mix of kTLS and tcp_bpf callbacks, we need to restore just the tcp_bpf callbacks to the original ones. At the moment, it comes down to the the unhash operation. We had a regression recently because tcp_bpf callbacks were not cleared in this particular scenario of removing a kTLS socket from a sockmap. It got fixed in commit 4da6a196f93b ("bpf: Sockmap/tls, during free we may call tcp_bpf_unhash() in loop"). Add a test that triggers the regression so that we don't reintroduce it in the future. Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200217121530.754315-4-jakub@cloudflare.com + Changed Files: .../selftests/bpf/prog_tests/sockmap_ktls.c | 123 +++++++++++++++++++++; 1 file changed, 123 insertions(+) + Parent Hashes: a178b4585865a4c756c41bc5376f63416b7d9271 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds a test for unhashing kTLS sockets after removal from a sockmap to prevent future regressions.", + "keywords": "test,kTLS,sockmap", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds a test case to verify kTLS socket behavior after sockmap removal to avoid regression.", + "keywords": "kTLS,sockmap,test", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 563/6895 - Commit ID: a178b4585865a4c756c41bc5376f63416b7d9271 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: a178b4585865a4c756c41bc5376f63416b7d9271 + Author Name: Jakub Sitnicki + Author Email: jakub@cloudflare.com + Commit Date: 1582127645 + Commit Message: + bpf, sk_msg: Don't clear saved sock proto on restore There is no need to clear psock->sk_proto when restoring socket protocol callbacks in sk->sk_prot. The psock is about to get detached from the sock and eventually destroyed. At worst we will restore the protocol callbacks and the write callback twice. This makes reasoning about psock state easier. Once psock is initialized, we can count on psock->sk_proto always being set. Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200217121530.754315-3-jakub@cloudflare.com + Changed Files: include/linux/skmsg.h | 8 +-------; 1 file changed, 1 insertion(+), 7 deletions(-) + Parent Hashes: a4393861a351f66fef1102e775743c86a276afce +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit avoids clearing saved socket protocol during socket restore to simplify psock state management.", + "keywords": "psock,socket,protocol", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +Rethinking... +new content: +{ + "summary": "The commit avoids clearing saved socket protocol during socket restore to simplify psock state management.", + "keywords": "psock,socket,protocol", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +-------------------- +-------------------- +Processing Commit 564/6895 - Commit ID: a4393861a351f66fef1102e775743c86a276afce +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: a4393861a351f66fef1102e775743c86a276afce + Author Name: Jakub Sitnicki + Author Email: jakub@cloudflare.com + Commit Date: 1582127645 + Commit Message: + bpf, sk_msg: Let ULP restore sk_proto and write_space callback We don't need a fallback for when the socket is not using ULP. tcp_update_ulp handles this case exactly the same as we do in sk_psock_restore_proto. Get rid of the duplicated code. Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200217121530.754315-2-jakub@cloudflare.com + Changed Files: include/linux/skmsg.h | 11 +----------; 1 file changed, 1 insertion(+), 10 deletions(-) + Parent Hashes: b80b033bedae68dae8fc703ab8a69811ce678f2e +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Refactor code to eliminate duplicate logic for restoring sk_proto and write_space callback in ULP.", + "keywords": "ULP, sk_proto, write_space", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +Rethinking... +new content: +{ + "summary": "Refactor code to simplify restoration of sk_proto and write_space callback in sockets using ULP.", + "keywords": "ULP, sk_proto, socket", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +-------------------- +-------------------- +Processing Commit 565/6895 - Commit ID: b80b033bedae68dae8fc703ab8a69811ce678f2e +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: b80b033bedae68dae8fc703ab8a69811ce678f2e + Author Name: Song Liu + Author Email: songliubraving@fb.com + Commit Date: 1582038507 + Commit Message: + bpf: Allow bpf_perf_event_read_value in all BPF programs bpf_perf_event_read_value() is NMI safe. Enable it for all BPF programs. This can be used in fentry/fexit to profile BPF program and individual kernel function with hardware counters. Signed-off-by: Song Liu Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200214234146.2910011-1-songliubraving@fb.com + Changed Files: kernel/trace/bpf_trace.c | 4 ++--; 1 file changed, 2 insertions(+), 2 deletions(-) + Parent Hashes: b182a66792feb706c62e50c31db8546ca4ff168e +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Enable bpf_perf_event_read_value() for use in all BPF programs to assist in profiling.", + "keywords": "bpf_perf_event_read_value BPF profiling", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Profile related type programs. It affects programs used for profiling system or application performance.", + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Enable bpf_perf_event_read_value() for use in all BPF programs to enhance profiling capabilities.", + "keywords": "bpf_perf_event_read_value,BPF,profiling", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Profile related type programs. It affects programs used for profiling system or application performance.", + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 566/6895 - Commit ID: 113e6b7e15e23dc45d5c66eb66bb91a627812e36 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 113e6b7e15e23dc45d5c66eb66bb91a627812e36 + Author Name: Toke Høiland-Jørgensen + Author Email: toke@redhat.com + Commit Date: 1582036460 + Commit Message: + libbpf: Sanitise internal map names so they are not rejected by the kernel The kernel only accepts map names with alphanumeric characters, underscores and periods in their name. However, the auto-generated internal map names used by libbpf takes their prefix from the user-supplied BPF object name, which has no such restriction. This can lead to "Invalid argument" errors when trying to load a BPF program using global variables. Fix this by sanitising the map names, replacing any non-allowed characters with underscores. Fixes: d859900c4c56 ("bpf, libbpf: support global data/bss/rodata sections") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200217171701.215215-1-toke@redhat.com + Changed Files: tools/lib/bpf/libbpf.c | 8 +++++++-; 1 file changed, 7 insertions(+), 1 deletion(-) + Parent Hashes: f25975f42f2f8f2a01303054d6a70c7ceb1fcf54 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Sanitise libbpf's internal map names to meet kernel's naming restrictions and avoid load errors.", + "keywords": "libbpf,map,sanitise", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Sanitise libbpf's internal map names to meet kernel's naming restrictions and avoid load errors.", + "keywords": "libbpf,map,sanitise", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 567/6895 - Commit ID: f25975f42f2f8f2a01303054d6a70c7ceb1fcf54 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: f25975f42f2f8f2a01303054d6a70c7ceb1fcf54 + Author Name: Toke Høiland-Jørgensen + Author Email: toke@redhat.com + Commit Date: 1582036291 + Commit Message: + bpf, uapi: Remove text about bpf_redirect_map() giving higher performance The performance of bpf_redirect() is now roughly the same as that of bpf_redirect_map(). However, David Ahern pointed out that the header file has not been updated to reflect this, and still says that a significant performance increase is possible when using bpf_redirect_map(). Remove this text from the bpf_redirect_map() description, and reword the description in bpf_redirect() slightly. Also fix the 'Return' section of the bpf_redirect_map() documentation. Fixes: 1d233886dd90 ("xdp: Use bulking for non-map XDP_REDIRECT and consolidate code paths") Reported-by: David Ahern Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200218130334.29889-1-toke@redhat.com + Changed Files: include/uapi/linux/bpf.h | 16 +++++++---------; tools/include/uapi/linux/bpf.h | 16 +++++++---------; 2 files changed, 14 insertions(+), 18 deletions(-) + Parent Hashes: e20d3a055a457a10a4c748ce5b7c2ed3173a1324 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit updates the documentation for bpf_redirect() and bpf_redirect_map() to reflect their equivalent performance.", + "keywords": "bpf_redirect,bpf_redirect_map,documentation", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit revises the documentation to accurately represent bpf_redirect() and bpf_redirect_map() performance equivalence.", + "keywords": "bpf_redirect,bpf_redirect_map,uapi", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 568/6895 - Commit ID: 3b573bf318d894b4290e194c4d7dbcba8c1f6ead +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 3b573bf318d894b4290e194c4d7dbcba8c1f6ead + Author Name: Arnaldo Carvalho de Melo + Author Email: acme@redhat.com + Commit Date: 1582031608 + Commit Message: + perf bpf: Remove bpf/ subdir from bpf.h headers used to build bpf events The bpf.h file needed gets installed in /usr/lib/include/perf/bpf/bpf.h, and /usr/lib/include/perf/ is added to the include path passed to clang to build the eBPF bytecode, so just remove "bpf/", its directly in the path passed already. This was working by accident, fix it. I.e. now this is back working: # cat /home/acme/git/perf/tools/perf/examples/bpf/hello.c #include int syscall_enter(openat)(void *args) { puts("Hello, world\n"); return 0; } license(GPL); # perf trace -e /home/acme/git/perf/tools/perf/examples/bpf/hello.c 0.000 pickup/21493 __bpf_stdout__(Hello, world) 56.462 sh/13539 __bpf_stdout__(Hello, world) 56.536 sh/13539 __bpf_stdout__(Hello, world) 56.673 sh/13539 __bpf_stdout__(Hello, world) 56.781 sh/13539 __bpf_stdout__(Hello, world) 56.707 perf/13182 __bpf_stdout__(Hello, world) 56.849 perf/13182 __bpf_stdout__(Hello, world) ^C # Cc: Adrian Hunter Cc: Jiri Olsa Cc: Namhyung Kim Link: https://lkml.kernel.org/n/tip-d9myswhgo8gfi3vmehdqpxa7@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo + Changed Files: tools/perf/include/bpf/pid_filter.h | 2 +-; tools/perf/include/bpf/stdio.h | 2 +-; tools/perf/include/bpf/unistd.h | 2 +-; 3 files changed, 3 insertions(+), 3 deletions(-) + Parent Hashes: b1da3acc781ce445445d959b41064d209a27bc2d +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit fixes the header path for bpf.h by removing unnecessary directory prefixes in the include path.", + "keywords": "header, path, remove", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit refactors include paths for bpf.h in perf bpf to correct directory structure issues.", + "keywords": "refactor, include, directory", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 569/6895 - Commit ID: 45a4296b6e55ef2fbbe5946582822daf8f0f2e71 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 45a4296b6e55ef2fbbe5946582822daf8f0f2e71 + Author Name: Gustavo A. R. Silva + Author Email: gustavo@embeddedor.com + Commit Date: 1581995105 + Commit Message: + bpf, sockmap: Replace zero-length array with flexible-array member The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva Signed-off-by: David S. Miller + Changed Files: net/core/sock_map.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: 9814428a44d63bf77831afdbb37b5f0aab7394c9 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit replaces a zero-length array with a flexible-array member in the sockmap structure for improved code safety.", + "keywords": "sockmap,array,fixed", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "I'm not sure about the logic component of the commit. The affected logic component is unclear.", + "usecases_or_submodule_events": [ + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +Rethinking... +new content: +{ + "summary": "The commit refactors code by replacing a zero-length array with a flexible-array member in the sockmap structure.", + "keywords": "flexible-array,sockmap,refactoring", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 570/6895 - Commit ID: e20d3a055a457a10a4c748ce5b7c2ed3173a1324 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: e20d3a055a457a10a4c748ce5b7c2ed3173a1324 + Author Name: Johannes Krude + Author Email: johannes@krude.de + Commit Date: 1581954829 + Commit Message: + bpf, offload: Replace bitwise AND by logical AND in bpf_prog_offload_info_fill This if guards whether user-space wants a copy of the offload-jited bytecode and whether this bytecode exists. By erroneously doing a bitwise AND instead of a logical AND on user- and kernel-space buffer-size can lead to no data being copied to user-space especially when user-space size is a power of two and bigger then the kernel-space buffer. Fixes: fcfb126defda ("bpf: add new jited info fields in bpf_dev_offload and bpf_prog_info") Signed-off-by: Johannes Krude Signed-off-by: Daniel Borkmann Acked-by: Jakub Kicinski Link: https://lore.kernel.org/bpf/20200212193227.GA3769@phlox.h.transitiv.net + Changed Files: kernel/bpf/offload.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: eecd618b45166fdddea3b6366b18479c2be0e11c +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes a logical error in bpf_prog_offload_info_fill by replacing a bitwise AND with a logical AND to ensure proper data copying to user-space.", + "keywords": "bpf, offload, bugfix", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit corrects a logical error by replacing a bitwise AND with a logical AND in bpf_prog_offload_info_fill to ensure user-space data copying.", + "keywords": "bpf, offload, fix", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 571/6895 - Commit ID: 66256e0b15bd72e1e1c24c4cef4281a95636781c +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 66256e0b15bd72e1e1c24c4cef4281a95636781c + Author Name: Randy Dunlap + Author Email: rdunlap@infradead.org + Commit Date: 1581910986 + Commit Message: + net/sock.h: fix all kernel-doc warnings Fix all kernel-doc warnings for . Fixes these warnings: ../include/net/sock.h:232: warning: Function parameter or member 'skc_addrpair' not described in 'sock_common' ../include/net/sock.h:232: warning: Function parameter or member 'skc_portpair' not described in 'sock_common' ../include/net/sock.h:232: warning: Function parameter or member 'skc_ipv6only' not described in 'sock_common' ../include/net/sock.h:232: warning: Function parameter or member 'skc_net_refcnt' not described in 'sock_common' ../include/net/sock.h:232: warning: Function parameter or member 'skc_v6_daddr' not described in 'sock_common' ../include/net/sock.h:232: warning: Function parameter or member 'skc_v6_rcv_saddr' not described in 'sock_common' ../include/net/sock.h:232: warning: Function parameter or member 'skc_cookie' not described in 'sock_common' ../include/net/sock.h:232: warning: Function parameter or member 'skc_listener' not described in 'sock_common' ../include/net/sock.h:232: warning: Function parameter or member 'skc_tw_dr' not described in 'sock_common' ../include/net/sock.h:232: warning: Function parameter or member 'skc_rcv_wnd' not described in 'sock_common' ../include/net/sock.h:232: warning: Function parameter or member 'skc_tw_rcv_nxt' not described in 'sock_common' ../include/net/sock.h:498: warning: Function parameter or member 'sk_rx_skb_cache' not described in 'sock' ../include/net/sock.h:498: warning: Function parameter or member 'sk_wq_raw' not described in 'sock' ../include/net/sock.h:498: warning: Function parameter or member 'tcp_rtx_queue' not described in 'sock' ../include/net/sock.h:498: warning: Function parameter or member 'sk_tx_skb_cache' not described in 'sock' ../include/net/sock.h:498: warning: Function parameter or member 'sk_route_forced_caps' not described in 'sock' ../include/net/sock.h:498: warning: Function parameter or member 'sk_txtime_report_errors' not described in 'sock' ../include/net/sock.h:498: warning: Function parameter or member 'sk_validate_xmit_skb' not described in 'sock' ../include/net/sock.h:498: warning: Function parameter or member 'sk_bpf_storage' not described in 'sock' ../include/net/sock.h:2024: warning: No description found for return value of 'sk_wmem_alloc_get' ../include/net/sock.h:2035: warning: No description found for return value of 'sk_rmem_alloc_get' ../include/net/sock.h:2046: warning: No description found for return value of 'sk_has_allocations' ../include/net/sock.h:2082: warning: No description found for return value of 'skwq_has_sleeper' ../include/net/sock.h:2244: warning: No description found for return value of 'sk_page_frag' ../include/net/sock.h:2444: warning: Function parameter or member 'tcp_rx_skb_cache_key' not described in 'DECLARE_STATIC_KEY_FALSE' ../include/net/sock.h:2444: warning: Excess function parameter 'sk' description in 'DECLARE_STATIC_KEY_FALSE' ../include/net/sock.h:2444: warning: Excess function parameter 'skb' description in 'DECLARE_STATIC_KEY_FALSE' Signed-off-by: Randy Dunlap Signed-off-by: David S. Miller + Changed Files: include/net/sock.h | 38 +++++++++++++++++++++++++++++++++-----; 1 file changed, 33 insertions(+), 5 deletions(-) + Parent Hashes: 58292104832fef6cb4a89f736012c0e0724c3442 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixed all kernel-doc warnings for the net/sock.h file by adding missing descriptions.", + "keywords": "kernel-doc,warnings,sock.h", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here." + ] +} +Rethinking... +new content: +{ + "summary": "Fixed documentation warnings in net/sock.h by adding missing param descriptions.", + "keywords": "documentation,warnings,net/sock.h", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +-------------------- +-------------------- +Processing Commit 572/6895 - Commit ID: eecd618b45166fdddea3b6366b18479c2be0e11c +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: eecd618b45166fdddea3b6366b18479c2be0e11c + Author Name: Jakub Sitnicki + Author Email: jakub@cloudflare.com + Commit Date: 1581525884 + Commit Message: + selftests/bpf: Mark SYN cookie test skipped for UDP sockets SYN cookie test with reuseport BPF doesn't make sense for UDP sockets. We don't run it but the test_progs test runner doesn't know about it. Mark the test as skipped so the test_progs can report correctly how many tests were skipped. Fixes: 7ee0d4e97b88 ("selftests/bpf: Switch reuseport tests for test_progs framework") Reported-by: Lorenz Bauer Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200212103208.438419-1-jakub@cloudflare.com + Changed Files: tools/testing/selftests/bpf/prog_tests/select_reuseport.c | 4 +++-; 1 file changed, 3 insertions(+), 1 deletion(-) + Parent Hashes: 2fe77100553f3ac6b2105db8ae14b5ea4b43c108 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit marks the SYN cookie test as skipped for UDP sockets in the BPF selftests.", + "keywords": "selftests, BPF, UDP", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +Rethinking... +new content: +{ + "summary": "The commit marks SYN cookie test as skipped for UDP sockets in BPF selftests for better reporting.", + "keywords": "SYN,cookie,UDP", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 573/6895 - Commit ID: 2fe77100553f3ac6b2105db8ae14b5ea4b43c108 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 2fe77100553f3ac6b2105db8ae14b5ea4b43c108 + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1581525877 + Commit Message: + selftests/bpf: Fix error checking on reading the tcp_fastopen sysctl There is a typo in checking the "saved_tcp_fo" and instead "saved_tcp_syncookie" is checked again. This patch fixes it and also breaks them into separate if statements such that the test will abort asap. Reported-by: David Binderman Signed-off-by: Martin KaFai Lau Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200211175910.3235321-1-kafai@fb.com + Changed Files: tools/testing/selftests/bpf/prog_tests/select_reuseport.c | 4 +++-; 1 file changed, 3 insertions(+), 1 deletion(-) + Parent Hashes: 30744a68626db6a0029aca9c646831c869c16d83 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit fixes a typo in error checking logic within the BPF self-tests related to TCP fast open configuration.", + "keywords": "typo, error checking, sysctl", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit fixes a typo in error checking within BPF self-tests related to TCP fast open sysctl configuration.", + "keywords": "typo,error checking,sysctl", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 574/6895 - Commit ID: 4ca54d3d3022ce27170b50e4bdecc3a42f05dbdc +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 4ca54d3d3022ce27170b50e4bdecc3a42f05dbdc + Author Name: Connor O'Brien + Author Email: connoro@google.com + Commit Date: 1581476574 + Commit Message: + security: selinux: allow per-file labeling for bpffs Add support for genfscon per-file labeling of bpffs files. This allows for separate permissions for different pinned bpf objects, which may be completely unrelated to each other. Signed-off-by: Connor O'Brien Signed-off-by: Steven Moreland Acked-by: Stephen Smalley Signed-off-by: Paul Moore + Changed Files: security/selinux/hooks.c | 1 +; 1 file changed, 1 insertion(+) + Parent Hashes: 89d4d7c88d2b4f252adb434a28ea9b84d629aeb1 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Add per-file labeling support for bpffs in SELinux to handle permissions for different pinned BPF objects.", + "keywords": "SELinux,bpffs,permissions", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +Rethinking... +new content: +{ + "summary": "Add per-file labeling support for bpffs in SELinux to manage permissions for distinct pinned BPF objects.", + "keywords": "SELinux,bpffs,labeling", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "LSM type related programs. It relates to eBPF programs used with Linux Security Modules (LSMs) for security enhancements." + ] +} +-------------------- +-------------------- +Processing Commit 575/6895 - Commit ID: 457fed775c97ac2c0cd1672aaf2ff2c8a6235e87 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 457fed775c97ac2c0cd1672aaf2ff2c8a6235e87 + Author Name: Eric Dumazet + Author Email: edumazet@google.com + Commit Date: 1581469482 + Commit Message: + net/smc: fix leak of kernel memory to user space As nlmsg_put() does not clear the memory that is reserved, it this the caller responsability to make sure all of this memory will be written, in order to not reveal prior content. While we are at it, we can provide the socket cookie even if clsock is not set. syzbot reported : BUG: KMSAN: uninit-value in __arch_swab32 arch/x86/include/uapi/asm/swab.h:10 [inline] BUG: KMSAN: uninit-value in __fswab32 include/uapi/linux/swab.h:59 [inline] BUG: KMSAN: uninit-value in __swab32p include/uapi/linux/swab.h:179 [inline] BUG: KMSAN: uninit-value in __be32_to_cpup include/uapi/linux/byteorder/little_endian.h:82 [inline] BUG: KMSAN: uninit-value in get_unaligned_be32 include/linux/unaligned/access_ok.h:30 [inline] BUG: KMSAN: uninit-value in ____bpf_skb_load_helper_32 net/core/filter.c:240 [inline] BUG: KMSAN: uninit-value in ____bpf_skb_load_helper_32_no_cache net/core/filter.c:255 [inline] BUG: KMSAN: uninit-value in bpf_skb_load_helper_32_no_cache+0x14a/0x390 net/core/filter.c:252 CPU: 1 PID: 5262 Comm: syz-executor.5 Not tainted 5.5.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x220 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215 __arch_swab32 arch/x86/include/uapi/asm/swab.h:10 [inline] __fswab32 include/uapi/linux/swab.h:59 [inline] __swab32p include/uapi/linux/swab.h:179 [inline] __be32_to_cpup include/uapi/linux/byteorder/little_endian.h:82 [inline] get_unaligned_be32 include/linux/unaligned/access_ok.h:30 [inline] ____bpf_skb_load_helper_32 net/core/filter.c:240 [inline] ____bpf_skb_load_helper_32_no_cache net/core/filter.c:255 [inline] bpf_skb_load_helper_32_no_cache+0x14a/0x390 net/core/filter.c:252 Uninit was created at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:144 [inline] kmsan_internal_poison_shadow+0x66/0xd0 mm/kmsan/kmsan.c:127 kmsan_kmalloc_large+0x73/0xc0 mm/kmsan/kmsan_hooks.c:128 kmalloc_large_node_hook mm/slub.c:1406 [inline] kmalloc_large_node+0x282/0x2c0 mm/slub.c:3841 __kmalloc_node_track_caller+0x44b/0x1200 mm/slub.c:4368 __kmalloc_reserve net/core/skbuff.c:141 [inline] __alloc_skb+0x2fd/0xac0 net/core/skbuff.c:209 alloc_skb include/linux/skbuff.h:1049 [inline] netlink_dump+0x44b/0x1ab0 net/netlink/af_netlink.c:2224 __netlink_dump_start+0xbb2/0xcf0 net/netlink/af_netlink.c:2352 netlink_dump_start include/linux/netlink.h:233 [inline] smc_diag_handler_dump+0x2ba/0x300 net/smc/smc_diag.c:242 sock_diag_rcv_msg+0x211/0x610 net/core/sock_diag.c:256 netlink_rcv_skb+0x451/0x650 net/netlink/af_netlink.c:2477 sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:275 netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline] netlink_unicast+0xf9e/0x1100 net/netlink/af_netlink.c:1328 netlink_sendmsg+0x1248/0x14d0 net/netlink/af_netlink.c:1917 sock_sendmsg_nosec net/socket.c:639 [inline] sock_sendmsg net/socket.c:659 [inline] kernel_sendmsg+0x433/0x440 net/socket.c:679 sock_no_sendpage+0x235/0x300 net/core/sock.c:2740 kernel_sendpage net/socket.c:3776 [inline] sock_sendpage+0x1e1/0x2c0 net/socket.c:937 pipe_to_sendpage+0x38c/0x4c0 fs/splice.c:458 splice_from_pipe_feed fs/splice.c:512 [inline] __splice_from_pipe+0x539/0xed0 fs/splice.c:636 splice_from_pipe fs/splice.c:671 [inline] generic_splice_sendpage+0x1d5/0x2d0 fs/splice.c:844 do_splice_from fs/splice.c:863 [inline] do_splice fs/splice.c:1170 [inline] __do_sys_splice fs/splice.c:1447 [inline] __se_sys_splice+0x2380/0x3350 fs/splice.c:1427 __x64_sys_splice+0x6e/0x90 fs/splice.c:1427 do_syscall_64+0xb8/0x160 arch/x86/entry/common.c:296 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: f16a7dd5cf27 ("smc: netlink interface for SMC sockets") Signed-off-by: Eric Dumazet Cc: Ursula Braun Signed-off-by: David S. Miller + Changed Files: net/smc/smc_diag.c | 5 ++---; 1 file changed, 2 insertions(+), 3 deletions(-) + Parent Hashes: f27f37a04a69890ac85d9155f03ee2d23b678d8f +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes a kernel memory leak to user space and provides a socket cookie even if clsock is not set.", + "keywords": "kernel,memory,leak", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +Rethinking... +new content: +{ + "summary": "This commit addresses a memory leak to user space in the net/smc by ensuring proper memory handling.", + "keywords": "memory,leak,user", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +-------------------- +-------------------- +Processing Commit 576/6895 - Commit ID: 30744a68626db6a0029aca9c646831c869c16d83 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 30744a68626db6a0029aca9c646831c869c16d83 + Author Name: Magnus Karlsson + Author Email: magnus.karlsson@intel.com + Commit Date: 1581432671 + Commit Message: + xsk: Publish global consumer pointers when NAPI is finished The commit 4b638f13bab4 ("xsk: Eliminate the RX batch size") introduced a much more lazy way of updating the global consumer pointers from the kernel side, by only doing so when running out of entries in the fill or Tx rings (the rings consumed by the kernel). This can result in a deadlock with the user application if the kernel requires more than one entry to proceed and the application cannot put these entries in the fill ring because the kernel has not updated the global consumer pointer since the ring is not empty. Fix this by publishing the local kernel side consumer pointer whenever we have completed Rx or Tx processing in the kernel. This way, user space will have an up-to-date view of the consumer pointers whenever it gets to execute in the one core case (application and driver on the same core), or after a certain number of packets have been processed in the two core case (application and driver on different cores). A side effect of this patch is that the one core case gets better performance, but the two core case gets worse. The reason that the one core case improves is that updating the global consumer pointer is relatively cheap since the application by definition is not running when the kernel is (they are on the same core) and it is beneficial for the application, once it gets to run, to have pointers that are as up to date as possible since it then can operate on more packets and buffers. In the two core case, the most important performance aspect is to minimize the number of accesses to the global pointers since they are shared between two cores and bounces between the caches of those cores. This patch results in more updates to global state, which means lower performance in the two core case. Fixes: 4b638f13bab4 ("xsk: Eliminate the RX batch size") Reported-by: Ryan Goodfellow Reported-by: Maxim Mikityanskiy Signed-off-by: Magnus Karlsson Signed-off-by: Daniel Borkmann Acked-by: Jonathan Lemon Acked-by: Maxim Mikityanskiy Link: https://lore.kernel.org/bpf/1581348432-6747-1-git-send-email-magnus.karlsson@intel.com + Changed Files: net/xdp/xsk.c | 2 ++; net/xdp/xsk_queue.h | 3 ++-; 2 files changed, 4 insertions(+), 1 deletion(-) + Parent Hashes: 2bf0eb9b3b0d099b20b2c4736436b666d78b94d5 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit fixes a potential deadlock in XSK by updating global consumer pointers after kernel processing.", + "keywords": "xsk,deadlock,performance", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit resolves a deadlock issue in XSK by updating global consumer pointers after kernel processing.", + "keywords": "xsk,deadlock,performance", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 577/6895 - Commit ID: c363eb48ada5cf732b3f489fab799fc881097842 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: c363eb48ada5cf732b3f489fab799fc881097842 + Author Name: Jiri Benc + Author Email: jbenc@redhat.com + Commit Date: 1581382915 + Commit Message: + selftests: fix too long argument With some shells, the command construed for install of bpf selftests becomes too large due to long list of files: make[1]: execvp: /bin/sh: Argument list too long make[1]: *** [../lib.mk:73: install] Error 127 Currently, each of the file lists is replicated three times in the command: in the shell 'if' condition, in the 'echo' and in the 'rsync'. Reduce that by one instance by using make conditionals and separate the echo and rsync into two shell commands. (One would be inclined to just remove the '@' at the beginning of the rsync command and let 'make' echo it by itself; unfortunately, it appears that the '@' in the front of mkdir silences output also for the following commands.) Also, separate handling of each of the lists to its own shell command. The semantics of the makefile is unchanged before and after the patch. The ability of individual test directories to override INSTALL_RULE is retained. Reported-by: Yauheni Kaliuta Tested-by: Yauheni Kaliuta Signed-off-by: Jiri Benc Signed-off-by: Shuah Khan + Changed Files: tools/testing/selftests/lib.mk | 23 +++++++++++++----------; 1 file changed, 13 insertions(+), 10 deletions(-) + Parent Hashes: 9d235a558c689b0ecdd23bbd8beb2e0584f619ed +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit refactors makefile commands in bpf selftests to reduce argument list length errors.", + "keywords": "selftests, makefile, refactor", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Refactor selftests makefile to fix argument list too long error by optimizing command structure.", + "keywords": "selftests, makefile, refactor", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 578/6895 - Commit ID: 2bf0eb9b3b0d099b20b2c4736436b666d78b94d5 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 2bf0eb9b3b0d099b20b2c4736436b666d78b94d5 + Author Name: Hongbo Yao + Author Email: yaohongbo@huawei.com + Commit Date: 1581376967 + Commit Message: + bpf: Make btf_check_func_type_match() static Fix the following sparse warning: kernel/bpf/btf.c:4131:5: warning: symbol 'btf_check_func_type_match' was not declared. Should it be static? Reported-by: Hulk Robot Signed-off-by: Hongbo Yao Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200210011441.147102-1-yaohongbo@huawei.com + Changed Files: kernel/bpf/btf.c | 6 +++---; 1 file changed, 3 insertions(+), 3 deletions(-) + Parent Hashes: f2e97dc126b712c0d21219ed0c42710006c1cf52 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit makes the btf_check_func_type_match function static to resolve a sparse warning in the BPF subsystem.", + "keywords": "static,function,sparse", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit fixes a sparse warning by making the btf_check_func_type_match function static in the BPF subsystem.", + "keywords": "static,function,sparse", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 579/6895 - Commit ID: f2e97dc126b712c0d21219ed0c42710006c1cf52 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: f2e97dc126b712c0d21219ed0c42710006c1cf52 + Author Name: John Fastabend + Author Email: john.fastabend@gmail.com + Commit Date: 1581373894 + Commit Message: + bpf: Selftests build error in sockmap_basic.c Fix following build error. We could push a tcp.h header into one of the include paths, but I think its easy enough to simply pull in the three defines we need here. If we end up using more of tcp.h at some point we can pull it in later. /home/john/git/bpf/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c: In function ‘connected_socket_v4’: /home/john/git/bpf/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c:20:11: error: ‘TCP_REPAIR_ON’ undeclared (first use in this function) repair = TCP_REPAIR_ON; ^ /home/john/git/bpf/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c:20:11: note: each undeclared identifier is reported only once for each function it appears in /home/john/git/bpf/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c:29:11: error: ‘TCP_REPAIR_OFF_NO_WP’ undeclared (first use in this function) repair = TCP_REPAIR_OFF_NO_WP; Then with fix, $ ./test_progs -n 44 #44/1 sockmap create_update_free:OK #44/2 sockhash create_update_free:OK #44 sockmap_basic:OK Fixes: 5d3919a953c3c ("selftests/bpf: Test freeing sockmap/sockhash with a socket in it") Signed-off-by: John Fastabend Signed-off-by: Alexei Starovoitov Reviewed-by: Jakub Sitnicki Link: https://lore.kernel.org/bpf/158131347731.21414.12120493483848386652.stgit@john-Precision-5820-Tower + Changed Files: tools/testing/selftests/bpf/prog_tests/sockmap_basic.c | 5 +++++; 1 file changed, 5 insertions(+) + Parent Hashes: 00516d13d4cfa56ce39da144db2dbf08b09b9357 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes build error in sockmap_basic.c by adding missing TCP_REPAIR definitions.", + "keywords": "selftests, sockmap, TCP_REPAIR", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes build error in sockmap_basic.c by adding missing TCP_REPAIR definitions.", + "keywords": "selftests,sockmap,TCP_REPAIR", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 580/6895 - Commit ID: 291abfea4746897b821830e0189dc225abd401eb +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 291abfea4746897b821830e0189dc225abd401eb + Author Name: Linus Torvalds + Author Email: torvalds@linux-foundation.org + Commit Date: 1581210908 + Commit Message: + Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from David Miller: 1) Unbalanced locking in mwifiex_process_country_ie, from Brian Norris. 2) Fix thermal zone registration in iwlwifi, from Andrei Otcheretianski. 3) Fix double free_irq in sgi ioc3 eth, from Thomas Bogendoerfer. 4) Use after free in mptcp, from Florian Westphal. 5) Use after free in wireguard's root_remove_peer_lists, from Eric Dumazet. 6) Properly access packets heads in bonding alb code, from Eric Dumazet. 7) Fix data race in skb_queue_len(), from Qian Cai. 8) Fix regression in r8169 on some chips, from Heiner Kallweit. 9) Fix XDP program ref counting in hv_netvsc, from Haiyang Zhang. 10) Certain kinds of set link netlink operations can cause a NULL deref in the ipv6 addrconf code. Fix from Eric Dumazet. 11) Don't cancel uninitialized work queue in drop monitor, from Ido Schimmel. * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (84 commits) net: thunderx: use proper interface type for RGMII mt76: mt7615: fix max_nss in mt7615_eeprom_parse_hw_cap bpf: Improve bucket_log calculation logic selftests/bpf: Test freeing sockmap/sockhash with a socket in it bpf, sockhash: Synchronize_rcu before free'ing map bpf, sockmap: Don't sleep while holding RCU lock on tear-down bpftool: Don't crash on missing xlated program instructions bpf, sockmap: Check update requirements after locking drop_monitor: Do not cancel uninitialized work item mlxsw: spectrum_dpipe: Add missing error path mlxsw: core: Add validation of hardware device types for MGPIR register mlxsw: spectrum_router: Clear offload indication from IPv6 nexthops on abort selftests: mlxsw: Add test cases for local table route replacement mlxsw: spectrum_router: Prevent incorrect replacement of local table routes net: dsa: microchip: enable module autoprobe ipv6/addrconf: fix potential NULL deref in inet6_set_link_af() dpaa_eth: support all modes with rate adapting PHYs net: stmmac: update pci platform data to use phy_interface net: stmmac: xgmac: fix missing IFF_MULTICAST checki in dwxgmac2_set_filter net: stmmac: fix missing IFF_MULTICAST check in dwmac4_set_filter ... + Changed Files: nan + Parent Hashes: d4f309ca411887cd61ea389c7abfb70c2eb1e532 29ca3b31756fb7cfbfc85f2d82a0475bf38cc1ed +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Merge commit incorporating various networking fixes from the netdev tree including issues related to locking and race conditions.", + "keywords": "networking,merge,fixes", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "Merge commit incorporating networking fixes including unbalanced locking and race condition resolutions.", + "keywords": "networking,merge,fixes", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 581/6895 - Commit ID: 2696e1146d3490f1af4b0080955bf1628bd8ab85 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 2696e1146d3490f1af4b0080955bf1628bd8ab85 + Author Name: David S. Miller + Author Email: davem@davemloft.net + Commit Date: 1581170463 + Commit Message: + Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf Daniel Borkmann says: ==================== pull-request: bpf 2020-02-07 The following pull-request contains BPF updates for your *net* tree. We've added 15 non-merge commits during the last 10 day(s) which contain a total of 12 files changed, 114 insertions(+), 31 deletions(-). The main changes are: 1) Various BPF sockmap fixes related to RCU handling in the map's tear- down code, from Jakub Sitnicki. 2) Fix macro state explosion in BPF sk_storage map when calculating its bucket_log on allocation, from Martin KaFai Lau. 3) Fix potential BPF sockmap update race by rechecking socket's established state under lock, from Lorenz Bauer. 4) Fix crash in bpftool on missing xlated instructions when kptr_restrict sysctl is set, from Toke Høiland-Jørgensen. 5) Fix i40e's XSK wakeup code to return proper error in busy state and various misc fixes in xdpsock BPF sample code, from Maciej Fijalkowski. 6) Fix the way modifiers are skipped in BTF in the verifier while walking pointers to avoid program rejection, from Alexei Starovoitov. 7) Fix Makefile for runqslower BPF tool to i) rebuild on libbpf changes and ii) to fix undefined reference linker errors for older gcc version due to order of passed gcc parameters, from Yulia Kartseva and Song Liu. 8) Fix a trampoline_count BPF kselftest warning about missing braces around initializer, from Andrii Nakryiko. 9) Fix up redundant "HAVE" prefix from large INSN limit kernel probe in bpftool, from Michal Rostecki. ==================== Signed-off-by: David S. Miller + Changed Files: nan + Parent Hashes: dfa7f709596be5ca46c070d4f8acbb344322056a 88d6f130e5632bbf419a2e184ec7adcbe241260b +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit merges BPF updates addressing issues in sockmap, sk_storage, and various other components.", + "keywords": "BPF,sockmap,fixes", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "The commit merges BPF updates addressing issues in sockmap, sk_storage, and various other components.", + "keywords": "BPF,sockmap,fixes", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 582/6895 - Commit ID: 88d6f130e5632bbf419a2e184ec7adcbe241260b +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 88d6f130e5632bbf419a2e184ec7adcbe241260b + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1581112901 + Commit Message: + bpf: Improve bucket_log calculation logic It was reported that the max_t, ilog2, and roundup_pow_of_two macros have exponential effects on the number of states in the sparse checker. This patch breaks them up by calculating the "nbuckets" first so that the "bucket_log" only needs to take ilog2(). In addition, Linus mentioned: Patch looks good, but I'd like to point out that it's not just sparse. You can see it with a simple make net/core/bpf_sk_storage.i grep 'smap->bucket_log = ' net/core/bpf_sk_storage.i | wc and see the end result: 1 365071 2686974 That's one line (the assignment line) that is 2,686,974 characters in length. Now, sparse does happen to react particularly badly to that (I didn't look to why, but I suspect it's just that evaluating all the types that don't actually ever end up getting used ends up being much more expensive than it should be), but I bet it's not good for gcc either. Fixes: 6ac99e8f23d4 ("bpf: Introduce bpf sk local storage") Reported-by: Randy Dunlap Reported-by: Luc Van Oostenryck Suggested-by: Linus Torvalds Signed-off-by: Martin KaFai Lau Signed-off-by: Daniel Borkmann Reviewed-by: Luc Van Oostenryck Link: https://lore.kernel.org/bpf/20200207081810.3918919-1-kafai@fb.com + Changed Files: net/core/bpf_sk_storage.c | 5 +++--; 1 file changed, 3 insertions(+), 2 deletions(-) + Parent Hashes: 5d3919a953c3c96c02fc7a337f8376cde43ae31f +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit refactors the bucket_log calculation logic to reduce state complexity and improve compiler handling.", + "keywords": "bucket_log, refactor, complexity", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit refactors the bucket_log calculation to improve compiler efficiency and reduce sparse checker complexity.", + "keywords": "bucket_log, refactor, efficiency", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 583/6895 - Commit ID: 5d3919a953c3c96c02fc7a337f8376cde43ae31f +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 5d3919a953c3c96c02fc7a337f8376cde43ae31f + Author Name: Jakub Sitnicki + Author Email: jakub@cloudflare.com + Commit Date: 1581111386 + Commit Message: + selftests/bpf: Test freeing sockmap/sockhash with a socket in it Commit 7e81a3530206 ("bpf: Sockmap, ensure sock lock held during tear down") introduced sleeping issues inside RCU critical sections and while holding a spinlock on sockmap/sockhash tear-down. There has to be at least one socket in the map for the problem to surface. This adds a test that triggers the warnings for broken locking rules. Not a fix per se, but rather tooling to verify the accompanying fixes. Run on a VM with 1 vCPU to reproduce the warnings. Fixes: 7e81a3530206 ("bpf: Sockmap, ensure sock lock held during tear down") Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200206111652.694507-4-jakub@cloudflare.com + Changed Files: .../selftests/bpf/prog_tests/sockmap_basic.c | 74 ++++++++++++++++++++++; 1 file changed, 74 insertions(+) + Parent Hashes: 0b2dc83906cf1e694e48003eae5df8fa63f76fd9 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds a test to validate locking rules for sockmap/sockhash teardown issues.", + "keywords": "sockmap,sockhash,tests", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds a test to identify broken locking rules in sockmap/sockhash teardown.", + "keywords": "sockmap,sockhash,test", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 584/6895 - Commit ID: 0b2dc83906cf1e694e48003eae5df8fa63f76fd9 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 0b2dc83906cf1e694e48003eae5df8fa63f76fd9 + Author Name: Jakub Sitnicki + Author Email: jakub@cloudflare.com + Commit Date: 1581111386 + Commit Message: + bpf, sockhash: Synchronize_rcu before free'ing map We need to have a synchronize_rcu before free'ing the sockhash because any outstanding psock references will have a pointer to the map and when they use it, this could trigger a use after free. This is a sister fix for sockhash, following commit 2bb90e5cc90e ("bpf: sockmap, synchronize_rcu before free'ing map") which addressed sockmap, which comes from a manual audit. Fixes: 604326b41a6fb ("bpf, sockmap: convert to generic sk_msg interface") Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200206111652.694507-3-jakub@cloudflare.com + Changed Files: net/core/sock_map.c | 4 ++++; 1 file changed, 4 insertions(+) + Parent Hashes: db6a5018b6e008c1d69c6628cdaa9541b8e70940 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Adds synchronize_rcu to sockhash to prevent use-after-free issues when freeing the map.", + "keywords": "synchronize_rcu,sockhash,use-after-free", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "Adds synchronize_rcu to sockhash to prevent use-after-free issues when freeing the map.", + "keywords": "synchronize_rcu,sockhash,use-after-free", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 585/6895 - Commit ID: db6a5018b6e008c1d69c6628cdaa9541b8e70940 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: db6a5018b6e008c1d69c6628cdaa9541b8e70940 + Author Name: Jakub Sitnicki + Author Email: jakub@cloudflare.com + Commit Date: 1581111386 + Commit Message: + bpf, sockmap: Don't sleep while holding RCU lock on tear-down rcu_read_lock is needed to protect access to psock inside sock_map_unref when tearing down the map. However, we can't afford to sleep in lock_sock while in RCU read-side critical section. Grab the RCU lock only after we have locked the socket. This fixes RCU warnings triggerable on a VM with 1 vCPU when free'ing a sockmap/sockhash that contains at least one socket: | ============================= | WARNING: suspicious RCU usage | 5.5.0-04005-g8fc91b972b73 #450 Not tainted | ----------------------------- | include/linux/rcupdate.h:272 Illegal context switch in RCU read-side critical section! | | other info that might help us debug this: | | | rcu_scheduler_active = 2, debug_locks = 1 | 4 locks held by kworker/0:1/62: | #0: ffff88813b019748 ((wq_completion)events){+.+.}, at: process_one_work+0x1d7/0x5e0 | #1: ffffc900000abe50 ((work_completion)(&map->work)){+.+.}, at: process_one_work+0x1d7/0x5e0 | #2: ffffffff82065d20 (rcu_read_lock){....}, at: sock_map_free+0x5/0x170 | #3: ffff8881368c5df8 (&stab->lock){+...}, at: sock_map_free+0x64/0x170 | | stack backtrace: | CPU: 0 PID: 62 Comm: kworker/0:1 Not tainted 5.5.0-04005-g8fc91b972b73 #450 | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 | Workqueue: events bpf_map_free_deferred | Call Trace: | dump_stack+0x71/0xa0 | ___might_sleep+0x105/0x190 | lock_sock_nested+0x28/0x90 | sock_map_free+0x95/0x170 | bpf_map_free_deferred+0x58/0x80 | process_one_work+0x260/0x5e0 | worker_thread+0x4d/0x3e0 | kthread+0x108/0x140 | ? process_one_work+0x5e0/0x5e0 | ? kthread_park+0x90/0x90 | ret_from_fork+0x3a/0x50 | ============================= | WARNING: suspicious RCU usage | 5.5.0-04005-g8fc91b972b73-dirty #452 Not tainted | ----------------------------- | include/linux/rcupdate.h:272 Illegal context switch in RCU read-side critical section! | | other info that might help us debug this: | | | rcu_scheduler_active = 2, debug_locks = 1 | 4 locks held by kworker/0:1/62: | #0: ffff88813b019748 ((wq_completion)events){+.+.}, at: process_one_work+0x1d7/0x5e0 | #1: ffffc900000abe50 ((work_completion)(&map->work)){+.+.}, at: process_one_work+0x1d7/0x5e0 | #2: ffffffff82065d20 (rcu_read_lock){....}, at: sock_hash_free+0x5/0x1d0 | #3: ffff888139966e00 (&htab->buckets[i].lock){+...}, at: sock_hash_free+0x92/0x1d0 | | stack backtrace: | CPU: 0 PID: 62 Comm: kworker/0:1 Not tainted 5.5.0-04005-g8fc91b972b73-dirty #452 | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 | Workqueue: events bpf_map_free_deferred | Call Trace: | dump_stack+0x71/0xa0 | ___might_sleep+0x105/0x190 | lock_sock_nested+0x28/0x90 | sock_hash_free+0xec/0x1d0 | bpf_map_free_deferred+0x58/0x80 | process_one_work+0x260/0x5e0 | worker_thread+0x4d/0x3e0 | kthread+0x108/0x140 | ? process_one_work+0x5e0/0x5e0 | ? kthread_park+0x90/0x90 | ret_from_fork+0x3a/0x50 Fixes: 7e81a3530206 ("bpf: Sockmap, ensure sock lock held during tear down") Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200206111652.694507-2-jakub@cloudflare.com + Changed Files: net/core/sock_map.c | 8 ++++----; 1 file changed, 4 insertions(+), 4 deletions(-) + Parent Hashes: d95f1e8b462c4372ac409886070bb8719d8a4d3a +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fix RCU warning in sockmap teardown by adjusting lock sequence to avoid sleeping while holding RCU lock.", + "keywords": "RCU,sockmap,teardown", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "Fix RCU warning in sockmap teardown by adjusting lock sequence to avoid sleeping while holding RCU lock.", + "keywords": "RCU,sockmap,teardown", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 586/6895 - Commit ID: d95f1e8b462c4372ac409886070bb8719d8a4d3a +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: d95f1e8b462c4372ac409886070bb8719d8a4d3a + Author Name: Toke Høiland-Jørgensen + Author Email: toke@redhat.com + Commit Date: 1581110985 + Commit Message: + bpftool: Don't crash on missing xlated program instructions Turns out the xlated program instructions can also be missing if kptr_restrict sysctl is set. This means that the previous fix to check the jited_prog_insns pointer was insufficient; add another check of the xlated_prog_insns pointer as well. Fixes: 5b79bcdf0362 ("bpftool: Don't crash on missing jited insns or ksyms") Fixes: cae73f233923 ("bpftool: use bpf_program__get_prog_info_linear() in prog.c:do_dump()") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200206102906.112551-1-toke@redhat.com + Changed Files: tools/bpf/bpftool/prog.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: 85b8ac01a421791d66c3a458a7f83cfd173fe3fa +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit updates bpftool to prevent crashes when xlated program instructions are missing due to kptr_restrict sysctl settings.", + "keywords": "bpftool,missing,instructions", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit updates bpftool to prevent crashes when xlated program instructions are missing due to kptr_restrict sysctl settings.", + "keywords": "bpftool,missing,instructions", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 587/6895 - Commit ID: 85b8ac01a421791d66c3a458a7f83cfd173fe3fa +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 85b8ac01a421791d66c3a458a7f83cfd173fe3fa + Author Name: Lorenz Bauer + Author Email: lmb@cloudflare.com + Commit Date: 1581110884 + Commit Message: + bpf, sockmap: Check update requirements after locking It's currently possible to insert sockets in unexpected states into a sockmap, due to a TOCTTOU when updating the map from a syscall. sock_map_update_elem checks that sk->sk_state == TCP_ESTABLISHED, locks the socket and then calls sock_map_update_common. At this point, the socket may have transitioned into another state, and the earlier assumptions don't hold anymore. Crucially, it's conceivable (though very unlikely) that a socket has become unhashed. This breaks the sockmap's assumption that it will get a callback via sk->sk_prot->unhash. Fix this by checking the (fixed) sk_type and sk_protocol without the lock, followed by a locked check of sk_state. Unfortunately it's not possible to push the check down into sock_(map|hash)_update_common, since BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB run before the socket has transitioned from TCP_SYN_RECV into TCP_ESTABLISHED. Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface") Signed-off-by: Lorenz Bauer Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Sitnicki Link: https://lore.kernel.org/bpf/20200207103713.28175-1-lmb@cloudflare.com + Changed Files: net/core/sock_map.c | 16 ++++++++++------; 1 file changed, 10 insertions(+), 6 deletions(-) + Parent Hashes: b9e42724888527352604260abc6717cba21421de +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes TOCTTOU vulnerability in sockmap updates by adding proper state checks on sockets.", + "keywords": "sockmap, TOCTTOU, TCP_ESTABLISHED", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The syscall interface. It changes the system calls through which user-space programs interact with eBPF.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes TOCTTOU bug in sockmap by adding state checks to prevent sockets in unintended states.", + "keywords": "sockmap, TOCTTOU, state", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 588/6895 - Commit ID: 184367dce4f744bde54377203305ccc8889aa79f +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 184367dce4f744bde54377203305ccc8889aa79f + Author Name: Haiyang Zhang + Author Email: haiyangz@microsoft.com + Commit Date: 1581071581 + Commit Message: + hv_netvsc: Fix XDP refcnt for synthetic and VF NICs The caller of XDP_SETUP_PROG has already incremented refcnt in __bpf_prog_get(), so drivers should only increment refcnt by num_queues - 1. To fix the issue, update netvsc_xdp_set() to add the correct number to refcnt. Hold a refcnt in netvsc_xdp_set()’s other caller, netvsc_attach(). And, do the same in netvsc_vf_setxdp(). Otherwise, every time when VF is removed and added from the host side, the refcnt will be decreased by one, which may cause page fault when unloading xdp program. Fixes: 351e1581395f ("hv_netvsc: Add XDP support") Signed-off-by: Haiyang Zhang Signed-off-by: David S. Miller + Changed Files: drivers/net/hyperv/netvsc_bpf.c | 13 +++++++++++--; drivers/net/hyperv/netvsc_drv.c | 5 ++++-; 2 files changed, 15 insertions(+), 3 deletions(-) + Parent Hashes: 6910fe95c61880e75b1c3a20eb13a6fd01ca501a +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes refcnt handling in hv_netvsc XDP implementation to avoid page faults on synthetic and VF NICs.", + "keywords": "hv_netvsc,XDP,refcnt", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "It's likely a merge commit. It involves changes across multiple use cases or events.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes refcnt handling in hv_netvsc XDP implementation to avoid page faults on synthetic and VF NICs.", + "keywords": "hv_netvsc,XDP,refcnt", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +-------------------- +-------------------- +Processing Commit 589/6895 - Commit ID: f1ed10264ed6b66b9cd5e8461cffce69be482356 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: f1ed10264ed6b66b9cd5e8461cffce69be482356 + Author Name: Nicolas Dichtel + Author Email: nicolas.dichtel@6wind.com + Commit Date: 1580992050 + Commit Message: + vti[6]: fix packet tx through bpf_redirect() in XinY cases I forgot the 4in6/6in4 cases in my previous patch. Let's fix them. Fixes: 95224166a903 ("vti[6]: fix packet tx through bpf_redirect()") Signed-off-by: Nicolas Dichtel Signed-off-by: Steffen Klassert + Changed Files: net/ipv4/Kconfig | 1 +; net/ipv4/ip_vti.c | 38 ++++++++++++++++++++++++++++++--------; net/ipv6/ip6_vti.c | 32 +++++++++++++++++++++++++-------; 3 files changed, 56 insertions(+), 15 deletions(-) + Parent Hashes: 03891f820c2117b19e80b370281eb924a09cf79f +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fix packet transmission through bpf_redirect() for 4in6 and 6in4 cases in vti interfaces.", + "keywords": "bpf_redirect vti fix", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "tc related type programs. It affects programs managing traffic control (tc) for queuing or prioritizing network traffic." + ] +} +Rethinking... +new content: +{ + "summary": "Fix packet transmission through bpf_redirect() for 4in6 and 6in4 cases in vti interfaces.", + "keywords": "bpf_redirect vti fix", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here." + ] +} +-------------------- +-------------------- +Processing Commit 590/6895 - Commit ID: b9e42724888527352604260abc6717cba21421de +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: b9e42724888527352604260abc6717cba21421de + Author Name: Daniel Borkmann + Author Email: daniel@iogearbox.net + Commit Date: 1580936772 + Commit Message: + Merge branch 'bpf-xsk-fixes' Maciej Fijalkowski says: ==================== Cameron reported [0] that on fresh bpf-next he could not run multiple xdpsock instances in Tx-only mode on single network interface with i40e driver. Turns out that Maxim's series [1] which was adding RCU protection around ndo_xsk_wakeup added check against the __I40E_CONFIG_BUSY being set on pf->state within i40e_xsk_wakeup() - if it's set, return -ENETDOWN. Since this bit is set per PF when UMEM is being enabled/disabled, the situation Cameron stumbled upon was that when he launched second xdpsock instance, second UMEM was being registered, hence set __I40E_CONFIG_BUSY which is now observed by first xdpsock and therefore xdpsock's kick_tx() gets -ENETDOWN as errno. -ENETDOWN currently is not allowed in kick_tx(), so we were exiting the first application. Such exit means also XDP program being unloaded and its dedicated resources, which caused an -ENXIO being return in the second xdpsock instance. Let's fix the issue from both sides - protect ourselves from future xdpsock crashes by allowing for -ENETDOWN errno being set in kick_tx() (patch 3) and from driver side, return -EAGAIN for the case where PF is busy (patch 1). Remove also doubled variable from xdpsock_user.c (patch 2). Note that ixgbe seems not to be affected since UMEM registration sets the busy/disable bit per ring, not per PF. [0]: https://www.spinics.net/lists/xdp-newbies/msg01558.html [1]: https://lore.kernel.org/netdev/20191217162023.16011-1-maximmi@mellanox.com/ ==================== Signed-off-by: Daniel Borkmann + Changed Files: nan + Parent Hashes: fc9e34f8de001c92e6cfc6481bb30a34dbda4f5c 8ed47e140867a6e7d56170f325c8d4fdee6d6b66 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes issues with xdpsock instances in Tx-only mode on i40e driver by handling -ENETDOWN and -EAGAIN errors.", + "keywords": "xdpsock,ENETDOWN,UMEM", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "I'm not sure about the complexity of the commit. It is difficult to estimate the complexity based on the provided commit details.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes issues with xdpsock instances in Tx-only mode on i40e driver by handling -ENETDOWN and -EAGAIN errors.", + "keywords": "xdpsock,ENETDOWN,UMEM", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "I'm not sure about the complexity of the commit. It is difficult to estimate the complexity based on the provided commit details.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +-------------------- +-------------------- +Processing Commit 591/6895 - Commit ID: 8ed47e140867a6e7d56170f325c8d4fdee6d6b66 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 8ed47e140867a6e7d56170f325c8d4fdee6d6b66 + Author Name: Maciej Fijalkowski + Author Email: maciej.fijalkowski@intel.com + Commit Date: 1580936769 + Commit Message: + samples: bpf: Allow for -ENETDOWN in xdpsock ndo_xsk_wakeup() can return -ENETDOWN and there's no particular reason to bail the whole application out on that case. Let's check in kick_tx() whether errno was set to mentioned value and basically allow application to further process frames. Fixes: 248c7f9c0e21 ("samples/bpf: convert xdpsock to use libbpf for AF_XDP access") Reported-by: Cameron Elliott Signed-off-by: Maciej Fijalkowski Signed-off-by: Daniel Borkmann Acked-by: Björn Töpel Link: https://lore.kernel.org/bpf/20200205045834.56795-4-maciej.fijalkowski@intel.com + Changed Files: samples/bpf/xdpsock_user.c | 3 ++-; 1 file changed, 2 insertions(+), 1 deletion(-) + Parent Hashes: 32c92c15ad3dca6f7cca8643766ad79fa3ab3d17 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit modifies the xdpsock sample application to handle the -ENETDOWN error without terminating.", + "keywords": "xdpsock,errno,ENETDOWN", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +Rethinking... +new content: +{ + "summary": "This commit modifies the xdpsock sample application to handle the -ENETDOWN error without terminating.", + "keywords": "xdpsock,errno,ENETDOWN", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +-------------------- +-------------------- +Processing Commit 592/6895 - Commit ID: 32c92c15ad3dca6f7cca8643766ad79fa3ab3d17 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 32c92c15ad3dca6f7cca8643766ad79fa3ab3d17 + Author Name: Maciej Fijalkowski + Author Email: maciej.fijalkowski@intel.com + Commit Date: 1580936769 + Commit Message: + samples: bpf: Drop doubled variable declaration in xdpsock Seems that by accident there is a doubled declaration of global variable opt_xdp_bind_flags in xdpsock_user.c. The second one is uninitialized so compiler was simply ignoring it. To keep things clean, drop the doubled variable. Fixes: c543f5469822 ("samples/bpf: add unaligned chunks mode support to xdpsock") Signed-off-by: Maciej Fijalkowski Signed-off-by: Daniel Borkmann Acked-by: Björn Töpel Link: https://lore.kernel.org/bpf/20200205045834.56795-3-maciej.fijalkowski@intel.com + Changed Files: samples/bpf/xdpsock_user.c | 1 -; 1 file changed, 1 deletion(-) + Parent Hashes: c77e9f09143822623dd71a0fdc84331129e97c3a +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit removes a duplicated variable declaration in the sample eBPF xdpsock code.", + "keywords": "xdpsock variable cleanup", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit removes a duplicated global variable declaration in the eBPF sample code for xdpsock.", + "keywords": "xdpsock variable declaration", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 593/6895 - Commit ID: c77e9f09143822623dd71a0fdc84331129e97c3a +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: c77e9f09143822623dd71a0fdc84331129e97c3a + Author Name: Maciej Fijalkowski + Author Email: maciej.fijalkowski@intel.com + Commit Date: 1580936768 + Commit Message: + i40e: Relax i40e_xsk_wakeup's return value when PF is busy Return -EAGAIN instead of -ENETDOWN to provide a slightly milder information to user space so that an application will know to retry the syscall when __I40E_CONFIG_BUSY bit is set on pf->state. Fixes: b3873a5be757 ("net/i40e: Fix concurrency issues between config flow and XSK") Signed-off-by: Maciej Fijalkowski Signed-off-by: Daniel Borkmann Acked-by: Björn Töpel Link: https://lore.kernel.org/bpf/20200205045834.56795-2-maciej.fijalkowski@intel.com + Changed Files: drivers/net/ethernet/intel/i40e/i40e_xsk.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: fc9e34f8de001c92e6cfc6481bb30a34dbda4f5c +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit changes the return value of i40e_xsk_wakeup to -EAGAIN when the PF is busy, indicating the application should retry.", + "keywords": "i40e,return value,EAGAIN", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +Rethinking... +new content: +{ + "summary": "The commit changes the return value of i40e_xsk_wakeup to -EAGAIN when the PF is busy, for signaling application to retry.", + "keywords": "i40e,return value,EAGAIN", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +-------------------- +-------------------- +Processing Commit 594/6895 - Commit ID: fc9e34f8de001c92e6cfc6481bb30a34dbda4f5c +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: fc9e34f8de001c92e6cfc6481bb30a34dbda4f5c + Author Name: Song Liu + Author Email: songliubraving@fb.com + Commit Date: 1580936728 + Commit Message: + tools/bpf/runqslower: Rebuild libbpf.a on libbpf source change Add missing dependency of $(BPFOBJ) to $(LIBBPF_SRC), so that running make in runqslower/ will rebuild libbpf.a when there is change in libbpf/. Fixes: 9c01546d26d2 ("tools/bpf: Add runqslower tool to tools/bpf") Signed-off-by: Song Liu Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200204215037.2258698-1-songliubraving@fb.com + Changed Files: tools/bpf/runqslower/Makefile | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: 8fc91b972b734a62a3f3ef45db06d06617f739ea +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fix the makefile in runqslower to correctly rebuild libbpf.a upon changes to libbpf source.", + "keywords": "runqslower libbpf makefile", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Fix the Makefile in runqslower to trigger rebuild of libbpf.a when there are source changes in libbpf.", + "keywords": "runqslower libbpf Makefile", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 595/6895 - Commit ID: 9afe2322cb90a8fbc27e32bfc691100c653cab2a +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 9afe2322cb90a8fbc27e32bfc691100c653cab2a + Author Name: David S. Miller + Author Email: davem@davemloft.net + Commit Date: 1580805000 + Commit Message: + Merge branch 'unbreak-basic-and-bpf-tdc-testcases' Davide Caratti says: ==================== unbreak 'basic' and 'bpf' tdc testcases - patch 1/2 fixes tdc failures with 'bpf' action on fresch clones of the kernel tree - patch 2/2 allow running tdc for the 'basic' classifier without tweaking tdc_config.py ==================== Signed-off-by: David S. Miller + Changed Files: nan + Parent Hashes: 2b5b8251bc9fe2f9118411f037862ee17cf81e97 e9ed4fa7b4400d7b2cf03108842a30e6c9bd0eb2 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges changes to fix 'basic' and 'bpf' tdc test cases in the kernel tree.", + "keywords": "merge,fix,testcases", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "I'm not sure about the implementation component of the commit. The component affected by It is unclear.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges updates to fix issues with 'basic' and 'bpf' TDC test cases.", + "keywords": "merge,fix,testcases", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 596/6895 - Commit ID: 7145fcfffef1fad4266aaf5ca96727696916edb7 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 7145fcfffef1fad4266aaf5ca96727696916edb7 + Author Name: Davide Caratti + Author Email: dcaratti@redhat.com + Commit Date: 1580805000 + Commit Message: + tc-testing: fix eBPF tests failure on linux fresh clones when the following command is done on a fresh clone of the kernel tree, [root@f31 tc-testing]# ./tdc.py -c bpf test cases that need to build the eBPF sample program fail systematically, because 'buildebpfPlugin' is unable to install the kernel headers (i.e, the 'khdr' target fails). Pass the correct environment to 'make', in place of ENVIR, to allow running these tests. Fixes: 4c2d39bd40c1 ("tc-testing: use a plugin to build eBPF program") Signed-off-by: Davide Caratti Signed-off-by: David S. Miller + Changed Files: tools/testing/selftests/tc-testing/plugin-lib/buildebpfPlugin.py | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: 2b5b8251bc9fe2f9118411f037862ee17cf81e97 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes a failure in eBPF tests on fresh Linux kernel clones by passing the correct environment to the build process.", + "keywords": "eBPF tests failure", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes failure in eBPF tests on fresh kernel clones by correcting environment variable usage during build.", + "keywords": "eBPF, tests, failure", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 597/6895 - Commit ID: 8fc91b972b734a62a3f3ef45db06d06617f739ea +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 8fc91b972b734a62a3f3ef45db06d06617f739ea + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1580771329 + Commit Message: + selftests/bpf: Fix trampoline_count.c selftest compilation warning Fix missing braces compilation warning in trampoline_count test: .../prog_tests/trampoline_count.c: In function ‘test_trampoline_count’: .../prog_tests/trampoline_count.c:49:9: warning: missing braces around initializer [-Wmissing-braces] struct inst inst[MAX_TRAMP_PROGS] = { 0 }; ^ .../prog_tests/trampoline_count.c:49:9: warning: (near initialization for ‘inst[0]’) [-Wmissing-braces] Fixes: d633d57902a5 ("selftest/bpf: Add test for allowed trampolines count") Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200202065152.2718142-1-andriin@fb.com + Changed Files: tools/testing/selftests/bpf/prog_tests/trampoline_count.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: 257af63d7f84f0672aa6a24b5511871f00741f19 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes a compilation warning in the BPF selftest trampoline_count.c by adding missing braces.", + "keywords": "compilation,warning,braces", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes a compilation warning in the BPF selftest trampoline_count.c by adding missing braces.", + "keywords": "compilation,warning,braces", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 598/6895 - Commit ID: 257af63d7f84f0672aa6a24b5511871f00741f19 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 257af63d7f84f0672aa6a24b5511871f00741f19 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1580771167 + Commit Message: + bpf: Fix modifier skipping logic Fix the way modifiers are skipped while walking pointers. Otherwise second level dereferences of 'const struct foo *' will be rejected by the verifier. Fixes: 9e15db66136a ("bpf: Implement accurate raw_tp context access via BTF") Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200201000314.261392-1-ast@kernel.org + Changed Files: kernel/bpf/btf.c | 8 +++-----; 1 file changed, 3 insertions(+), 5 deletions(-) + Parent Hashes: a525b0881de7742617343f02df4073ddc1571237 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes the modifier skipping logic in eBPF verifier to prevent rejection of second level dereferences.", + "keywords": "modifier, verifier, dereferences", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes the modifier skipping logic in eBPF verifier to prevent rejection of second level dereferences.", + "keywords": "modifier, verifier, dereferences", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 599/6895 - Commit ID: a525b0881de7742617343f02df4073ddc1571237 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: a525b0881de7742617343f02df4073ddc1571237 + Author Name: Michal Rostecki + Author Email: mrostecki@opensuse.org + Commit Date: 1580771046 + Commit Message: + bpftool: Remove redundant "HAVE" prefix from the large INSN limit check "HAVE" prefix is already applied by default to feature macros and before this change, the large INSN limit macro had the incorrect name with double "HAVE". Fixes: 2faef64aa6b3 ("bpftool: Add misc section and probe for large INSN limit") Signed-off-by: Michal Rostecki Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200202110200.31024-1-mrostecki@opensuse.org + Changed Files: tools/bpf/bpftool/feature.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: 2577e373bbc07f18680287b3958d3b2fdebe4b20 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Removed redundant \"HAVE\" prefix from the bpftool's large INSN limit macro to correct naming.", + "keywords": "bpftool,INNSN,macro", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +Rethinking... +new content: +{ + "summary": "Removed redundant \"HAVE\" prefix from the bpftool's large INSN limit macro to correct naming.", + "keywords": "bpftool,macro,INSN", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +-------------------- +-------------------- +Processing Commit 600/6895 - Commit ID: 43e76cd368fbb67e767da5363ffeaa3989993c8c +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 43e76cd368fbb67e767da5363ffeaa3989993c8c + Author Name: Alexandre Ghiti + Author Email: alex@ghiti.fr + Commit Date: 1580462242 + Commit Message: + powerpc: Do not consider weak unresolved symbol relocations as bad Commit 8580ac9404f6 ("bpf: Process in-kernel BTF") introduced two weak symbols that may be unresolved at link time which result in an absolute relocation to 0. relocs_check.sh emits the following warning: "WARNING: 2 bad relocations c000000001a41478 R_PPC64_ADDR64 _binary__btf_vmlinux_bin_start c000000001a41480 R_PPC64_ADDR64 _binary__btf_vmlinux_bin_end" whereas those relocations are legitimate even for a relocatable kernel compiled with -pie option. relocs_check.sh already excluded some weak unresolved symbols explicitly: remove those hardcoded symbols and add some logic that parses the symbols using nm, retrieves all the weak unresolved symbols and excludes those from the list of the potential bad relocations. Reported-by: Stephen Rothwell Signed-off-by: Alexandre Ghiti Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200118170335.21440-1-alex@ghiti.fr + Changed Files: arch/powerpc/Makefile.postlink | 4 ++--; arch/powerpc/tools/relocs_check.sh | 20 ++++++++++++--------; 2 files changed, 14 insertions(+), 10 deletions(-) + Parent Hashes: 41196224883a64e56e0ef237c19eb837058df071 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit updates scripts to not consider weak unresolved symbol relocations as errors in PowerPC builds.", + "keywords": "weak symbols, relocations, PowerPC", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes handling of weak unresolved symbol relocations for PowerPC architecture during build.", + "keywords": "weak symbols, relocations, PowerPC", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +-------------------- +-------------------- +Processing Commit 601/6895 - Commit ID: 2577e373bbc07f18680287b3958d3b2fdebe4b20 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 2577e373bbc07f18680287b3958d3b2fdebe4b20 + Author Name: Yulia Kartseva + Author Email: hex@fb.com + Commit Date: 1580429987 + Commit Message: + runqslower: Fix Makefile Fix undefined reference linker errors when building runqslower with gcc 7.4.0 on Ubuntu 18.04. The issue is with misplaced -lelf, -lz options in Makefile: $(Q)$(CC) $(CFLAGS) -lelf -lz $^ -o $@ -lelf, -lz options should follow the list of target dependencies: $(Q)$(CC) $(CFLAGS) $^ -lelf -lz -o $@ or after substitution cc -g -Wall runqslower.o libbpf.a -lelf -lz -o runqslower The current order of gcc params causes failure in libelf symbols resolution, e.g. undefined reference to `elf_memory' Fixes: 9c01546d26d2 ("tools/bpf: Add runqslower tool to tools/bpf") Signed-off-by: Julia Kartseva Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/908498f794661c44dca54da9e09dc0c382df6fcb.1580425879.git.hex@fb.com + Changed Files: tools/bpf/runqslower/Makefile | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: d3e42bb0a329fadff98fcb927714d0a486840e3b +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit fixes linker errors in the runqslower tool's Makefile by correcting the order of library dependencies.", + "keywords": "Makefile,linker errors,runqslower", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "This commit fixes linker errors in the runqslower tool's Makefile by correcting the library linking order.", + "keywords": "Makefile,linker,runqslower", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 602/6895 - Commit ID: d3e42bb0a329fadff98fcb927714d0a486840e3b +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: d3e42bb0a329fadff98fcb927714d0a486840e3b + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1580312454 + Commit Message: + bpf: Reuse log from btf_prase_vmlinux() in btf_struct_ops_init() Instead of using a locally defined "struct bpf_verifier_log log = {}", btf_struct_ops_init() should reuse the "log" from its calling function "btf_parse_vmlinux()". It should also resolve the frame-size too large compiler warning in some ARCH. Fixes: 27ae7997a661 ("bpf: Introduce BPF_PROG_TYPE_STRUCT_OPS") Signed-off-by: Martin KaFai Lau Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Acked-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200127175145.1154438-1-kafai@fb.com + Changed Files: include/linux/bpf.h | 7 +++++--; kernel/bpf/bpf_struct_ops.c | 5 ++---; kernel/bpf/btf.c | 2 +-; 3 files changed, 8 insertions(+), 6 deletions(-) + Parent Hashes: 44efc78d0e464ce70b45b165c005f8bedc17952e +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Refactor btf_struct_ops_init() to reuse log from btf_parse_vmlinux() and resolve frame-size warning.", + "keywords": "btf,log,refactor", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Refactor btf_struct_ops_init() to reuse log from btf_parse_vmlinux() and resolve frame-size warning.", + "keywords": "btf,log,refactor", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 603/6895 - Commit ID: 9e0703a2650def6fffe91235a880bb6f37d9ad74 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 9e0703a2650def6fffe91235a880bb6f37d9ad74 + Author Name: David S. Miller + Author Email: davem@davemloft.net + Commit Date: 1580131900 + Commit Message: + Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next Daniel Borkmann says: ==================== pull-request: bpf-next 2020-01-27 The following pull-request contains BPF updates for your *net-next* tree. We've added 20 non-merge commits during the last 5 day(s) which contain a total of 24 files changed, 433 insertions(+), 104 deletions(-). The main changes are: 1) Make BPF trampolines and dispatcher aware for the stack unwinder, from Jiri Olsa. 2) Improve handling of failed CO-RE relocations in libbpf, from Andrii Nakryiko. 3) Several fixes to BPF sockmap and reuseport selftests, from Lorenz Bauer. 4) Various cleanups in BPF devmap's XDP flush code, from John Fastabend. 5) Fix BPF flow dissector when used with port ranges, from Yoshiki Komachi. 6) Fix bpffs' map_seq_next callback to always inc position index, from Vasily Averin. 7) Allow overriding LLVM tooling for runqslower utility, from Andrey Ignatov. 8) Silence false-positive lockdep splats in devmap hash lookup, from Amol Grover. 9) Fix fentry/fexit selftests to initialize a variable before use, from John Sperbeck. ==================== Signed-off-by: David S. Miller + Changed Files: nan + Parent Hashes: c312840cd79061af37158cb42590931cfa364c1b 82650dab9a5a2928c8d982cce5e3c687f14f8716 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges multiple updates to the BPF subsystem, including improvements and fixes in trampolines, libbpf, sockmap, and other components.", + "keywords": "merge,BPF,updates", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges multiple updates to the BPF subsystem, including improvements and fixes in trampolines, libbpf, sockmap, and other components.", + "keywords": "merge,exports,bpf", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 604/6895 - Commit ID: 82650dab9a5a2928c8d982cce5e3c687f14f8716 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 82650dab9a5a2928c8d982cce5e3c687f14f8716 + Author Name: Daniel Borkmann + Author Email: daniel@iogearbox.net + Commit Date: 1580120712 + Commit Message: + Merge branch 'bpf-flow-dissector-fix-port-ranges' Yoshiki Komachi says: ==================== When I tried a test based on the selftest program for BPF flow dissector (test_flow_dissector.sh), I observed unexpected result as below: $ tc filter add dev lo parent ffff: protocol ip pref 1337 flower ip_proto \ udp src_port 8-10 action drop $ tools/testing/selftests/bpf/test_flow_dissector -i 4 -f 9 -F inner.dest4: 127.0.0.1 inner.source4: 127.0.0.3 pkts: tx=10 rx=10 The last rx means the number of received packets. I expected rx=0 in this test (i.e., all received packets should have been dropped), but it resulted in acceptance. Although the previous commit 8ffb055beae5 ("cls_flower: Fix the behavior using port ranges with hw-offload") added new flag and field toward filtering based on port ranges with hw-offload, it missed applying for BPF flow dissector then. As a result, BPF flow dissector currently stores data extracted from packets in incorrect field used for exact match whenever packets are classified by filters based on port ranges. Thus, they never match rules in such cases because flow dissector gives rise to generating incorrect flow keys. This series fixes the issue by replacing incorrect flag and field with new ones in BPF flow dissector, and adds a test for filtering based on specified port ranges to the existing selftest program. Changes in v2: - set key_ports to NULL at the top of __skb_flow_bpf_to_target() ==================== Signed-off-by: Daniel Borkmann + Changed Files: nan + Parent Hashes: b23bfa5633b19bf1db87b36a76b2225c734f794c 265bb359061db6ef825dec3912f341a604966371 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit fixes incorrect handling of port ranges in BPF flow dissector to ensure proper packet filtering and adds a relevant test case.", + "keywords": "flow dissector,port ranges,selftest", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "I'm not sure about the complexity of the commit. It is difficult to estimate the complexity based on the provided commit details.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +Rethinking... +new content: +{ + "summary": "This commit fixes port range handling in the BPF flow dissector for accurate packet filtering and includes a self-test update.", + "keywords": "flow dissector,port ranges,filtering", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing." + ] +} +-------------------- +-------------------- +Processing Commit 605/6895 - Commit ID: 265bb359061db6ef825dec3912f341a604966371 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 265bb359061db6ef825dec3912f341a604966371 + Author Name: Yoshiki Komachi + Author Email: komachi.yoshiki@gmail.com + Commit Date: 1580120707 + Commit Message: + selftests/bpf: Add test based on port range for BPF flow dissector Add a simple test to make sure that a filter based on specified port range classifies packets correctly. Signed-off-by: Yoshiki Komachi Signed-off-by: Daniel Borkmann Acked-by: Petar Penkov Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200117070533.402240-3-komachi.yoshiki@gmail.com + Changed Files: tools/testing/selftests/bpf/test_flow_dissector.sh | 14 ++++++++++++++; 1 file changed, 14 insertions(+) + Parent Hashes: 59fb9b62fb6c929a756563152a89f39b07cf8893 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Added a test for port range filtering in BPF flow dissector to ensure correct packet classification.", + "keywords": "test,port,dissector", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Added a test for port range filtering in BPF flow dissector to ensure correct packet classification.", + "keywords": "test,port,dissector", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 606/6895 - Commit ID: 59fb9b62fb6c929a756563152a89f39b07cf8893 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 59fb9b62fb6c929a756563152a89f39b07cf8893 + Author Name: Yoshiki Komachi + Author Email: komachi.yoshiki@gmail.com + Commit Date: 1580120707 + Commit Message: + flow_dissector: Fix to use new variables for port ranges in bpf hook This patch applies new flag (FLOW_DISSECTOR_KEY_PORTS_RANGE) and field (tp_range) to BPF flow dissector to generate appropriate flow keys when classified by specified port ranges. Fixes: 8ffb055beae5 ("cls_flower: Fix the behavior using port ranges with hw-offload") Signed-off-by: Yoshiki Komachi Signed-off-by: Daniel Borkmann Acked-by: Petar Penkov Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200117070533.402240-2-komachi.yoshiki@gmail.com + Changed Files: net/core/flow_dissector.c | 11 +++++++++--; 1 file changed, 9 insertions(+), 2 deletions(-) + Parent Hashes: b23bfa5633b19bf1db87b36a76b2225c734f794c +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes port range usage in BPF flow dissector with new flag and field.", + "keywords": "flow,port,bpf", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Netfilter related type programs. It impacts programs interacting with the Netfilter framework used in packet filtering and NAT.", + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes port range usage in BPF flow dissector with new flag and field.", + "keywords": "flow,port,bpf", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Netfilter related type programs. It impacts programs interacting with the Netfilter framework used in packet filtering and NAT.", + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +-------------------- +-------------------- +Processing Commit 607/6895 - Commit ID: b23bfa5633b19bf1db87b36a76b2225c734f794c +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: b23bfa5633b19bf1db87b36a76b2225c734f794c + Author Name: John Fastabend + Author Email: john.fastabend@gmail.com + Commit Date: 1580120185 + Commit Message: + bpf, xdp: Remove no longer required rcu_read_{un}lock() Now that we depend on rcu_call() and synchronize_rcu() to also wait for preempt_disabled region to complete the rcu read critical section in __dev_map_flush() is no longer required. Except in a few special cases in drivers that need it for other reasons. These originally ensured the map reference was safe while a map was also being free'd. And additionally that bpf program updates via ndo_bpf did not happen while flush updates were in flight. But flush by new rules can only be called from preempt-disabled NAPI context. The synchronize_rcu from the map free path and the rcu_call from the delete path will ensure the reference there is safe. So lets remove the rcu_read_lock and rcu_read_unlock pair to avoid any confusion around how this is being protected. If the rcu_read_lock was required it would mean errors in the above logic and the original patch would also be wrong. Now that we have done above we put the rcu_read_lock in the driver code where it is needed in a driver dependent way. I think this helps readability of the code so we know where and why we are taking read locks. Most drivers will not need rcu_read_locks here and further XDP drivers already have rcu_read_locks in their code paths for reading xdp programs on RX side so this makes it symmetric where we don't have half of rcu critical sections define in driver and the other half in devmap. Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Acked-by: Jesper Dangaard Brouer Link: https://lore.kernel.org/bpf/1580084042-11598-4-git-send-email-john.fastabend@gmail.com + Changed Files: drivers/net/veth.c | 6 +++++-; kernel/bpf/devmap.c | 5 +++--; 2 files changed, 8 insertions(+), 3 deletions(-) + Parent Hashes: 9719c6b98db42462bfb9aa172f017bdfd6d66c6f +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit removes unnecessary rcu_read lock calls in devmap flush operations for better readability and symmetry with XDP drivers.", + "keywords": "rcu_read, devmap, xdp", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit removes unnecessary rcu_read lock calls from devmap and veth driver to optimize logic and enhance code clarity for XDP operations.", + "keywords": "rcu_read, devmap, xdp", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +-------------------- +-------------------- +Processing Commit 608/6895 - Commit ID: 9719c6b98db42462bfb9aa172f017bdfd6d66c6f +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 9719c6b98db42462bfb9aa172f017bdfd6d66c6f + Author Name: John Fastabend + Author Email: john.fastabend@gmail.com + Commit Date: 1580120185 + Commit Message: + bpf, xdp: virtio_net use access ptr macro for xdp enable check virtio_net currently relies on rcu critical section to access the xdp program in its xdp_xmit handler. However, the pointer to the xdp program is only used to do a NULL pointer comparison to determine if xdp is enabled or not. Use rcu_access_pointer() instead of rcu_dereference() to reflect this. Then later when we drop rcu_read critical section virtio_net will not need in special handling. Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Acked-by: Jesper Dangaard Brouer Link: https://lore.kernel.org/bpf/1580084042-11598-3-git-send-email-john.fastabend@gmail.com + Changed Files: drivers/net/virtio_net.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: 42a84a8cd0ff0cbff5a4595e1304c4567a30267d +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit changes the virtio_net driver to use rcu_access_pointer for checking XDP enablement, simplifying rcu handling.", + "keywords": "virtio_net,xdp,rcu_access_pointer", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +Rethinking... +new content: +{ + "summary": "The commit refactors the virtio_net driver to use rcu_access_pointer for checking XDP enablement to simplify RCU handling.", + "keywords": "virtio_net,XDP,rcu_access_pointer", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +-------------------- +-------------------- +Processing Commit 609/6895 - Commit ID: 42a84a8cd0ff0cbff5a4595e1304c4567a30267d +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 42a84a8cd0ff0cbff5a4595e1304c4567a30267d + Author Name: John Fastabend + Author Email: john.fastabend@gmail.com + Commit Date: 1580120180 + Commit Message: + bpf, xdp: Update devmap comments to reflect napi/rcu usage Now that we rely on synchronize_rcu and call_rcu waiting to exit perempt-disable regions (NAPI) lets update the comments to reflect this. Fixes: 0536b85239b84 ("xdp: Simplify devmap cleanup") Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Acked-by: Björn Töpel Acked-by: Song Liu Link: https://lore.kernel.org/bpf/1580084042-11598-2-git-send-email-john.fastabend@gmail.com + Changed Files: kernel/bpf/devmap.c | 21 +++++++++++----------; 1 file changed, 11 insertions(+), 10 deletions(-) + Parent Hashes: 90435a7891a2259b0f74c5a1bc5600d0d64cba8f +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Update devmap comments to reflect RCU usage in NAPI context.", + "keywords": "devmap, NAPI, RCU", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Update devmap comments to reflect RCU usage in NAPI context in eBPF XDP programs.", + "keywords": "devmap,NAPI,RCU", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +-------------------- +-------------------- +Processing Commit 610/6895 - Commit ID: 0e6223ea903a892ba6962bdf823572e595dc8236 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 0e6223ea903a892ba6962bdf823572e595dc8236 + Author Name: David S. Miller + Author Email: davem@davemloft.net + Commit Date: 1580119542 + Commit Message: + Merge branch 'XDP-fixes-for-socionext-driver' Lorenzo Bianconi says: ==================== XDP fixes for socionext driver Fix possible user-after-in XDP rx path Fix rx statistics accounting if no bpf program is attached ==================== Signed-off-by: David S. Miller + Changed Files: nan + Parent Hashes: 09917a126d5babd9d0d9bee8ee2c5fc8517851e6 02758cb6dac31a2b4bd9e535cffbe718acd46404 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges XDP fixes for the socionext driver to address a potential use-after-free issue and improve RX statistics accounting.", + "keywords": "XDP,socionext,fixes", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges XDP fixes for the Socionext driver addressing use-after-free and RX stats issues.", + "keywords": "XDP,socionext,fixes", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +-------------------- +-------------------- +Processing Commit 611/6895 - Commit ID: 02758cb6dac31a2b4bd9e535cffbe718acd46404 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 02758cb6dac31a2b4bd9e535cffbe718acd46404 + Author Name: Lorenzo Bianconi + Author Email: lorenzo@kernel.org + Commit Date: 1580119542 + Commit Message: + net: socionext: fix xdp_result initialization in netsec_process_rx Fix xdp_result initialization in netsec_process_rx in order to not increase rx counters if there is no bpf program attached to the xdp hook and napi_gro_receive returns GRO_DROP Fixes: ba2b232108d3c ("net: netsec: add XDP support") Signed-off-by: Lorenzo Bianconi Acked-by: Jesper Dangaard Brouer Acked-by: Ilias Apalodimas Signed-off-by: David S. Miller + Changed Files: drivers/net/ethernet/socionext/netsec.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: b5e82e3c89c78ee0407ea8e8087af5519b6c7bae +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fix xdp_result initialization in netsec_process_rx to prevent incrementing rx counters unnecessarily.", + "keywords": "xdp_result, initialization, netsec_process_rx", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +Rethinking... +new content: +{ + "summary": "Fix xdp_result initialization in netsec_process_rx to prevent incrementing rx counters unnecessarily.", + "keywords": "xdp_result, initialization, netsec_process_rx", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +-------------------- +-------------------- +Processing Commit 612/6895 - Commit ID: b5e82e3c89c78ee0407ea8e8087af5519b6c7bae +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: b5e82e3c89c78ee0407ea8e8087af5519b6c7bae + Author Name: Lorenzo Bianconi + Author Email: lorenzo@kernel.org + Commit Date: 1580119542 + Commit Message: + net: socionext: fix possible user-after-free in netsec_process_rx Fix possible use-after-free in in netsec_process_rx that can occurs if the first packet is sent to the normal networking stack and the following one is dropped by the bpf program attached to the xdp hook. Fix the issue defining the skb pointer in the 'budget' loop Fixes: ba2b232108d3c ("net: netsec: add XDP support") Signed-off-by: Lorenzo Bianconi Acked-by: Jesper Dangaard Brouer Acked-by: Ilias Apalodimas Signed-off-by: David S. Miller + Changed Files: drivers/net/ethernet/socionext/netsec.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: 09917a126d5babd9d0d9bee8ee2c5fc8517851e6 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes a possible use-after-free bug in the netsec driver when processing RX packets with XDP.", + "keywords": "use-after-free,XDP,netsec", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes a use-after-free bug in the netsec driver when dropped packets in XDP code path affect skb handling.", + "keywords": "use-after-free,XDP,netsec", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +-------------------- +-------------------- +Processing Commit 613/6895 - Commit ID: 90435a7891a2259b0f74c5a1bc5600d0d64cba8f +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 90435a7891a2259b0f74c5a1bc5600d0d64cba8f + Author Name: Vasily Averin + Author Email: vvs@virtuozzo.com + Commit Date: 1580118872 + Commit Message: + bpf: map_seq_next should always increase position index If seq_file .next fuction does not change position index, read after some lseek can generate an unexpected output. See also: https://bugzilla.kernel.org/show_bug.cgi?id=206283 v1 -> v2: removed missed increment in end of function Signed-off-by: Vasily Averin Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/eca84fdd-c374-a154-d874-6c7b55fc3bc4@virtuozzo.com + Changed Files: kernel/bpf/inode.c | 3 +--; 1 file changed, 1 insertion(+), 2 deletions(-) + Parent Hashes: 07fdbee134b3530ef30c709aa4251ca04ea9e3f8 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes position index update in the map_seq_next function to ensure correct output after seeking in eBPF maps.", + "keywords": "position,index,seq_file", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes position index update in the map_seq_next function to ensure correct output after seeking in eBPF maps.", + "keywords": "position,index,seq_file", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 614/6895 - Commit ID: 07fdbee134b3530ef30c709aa4251ca04ea9e3f8 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 07fdbee134b3530ef30c709aa4251ca04ea9e3f8 + Author Name: Andrey Ignatov + Author Email: rdna@fb.com + Commit Date: 1580118777 + Commit Message: + tools/bpf: Allow overriding llvm tools for runqslower tools/testing/selftests/bpf/Makefile supports overriding clang, llc and other tools so that custom ones can be used instead of those from PATH. It's convinient and heavily used by some users. Apply same rules to runqslower/Makefile. Signed-off-by: Andrey Ignatov Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200124224142.1833678-1-rdna@fb.com + Changed Files: tools/bpf/runqslower/Makefile | 6 +++---; 1 file changed, 3 insertions(+), 3 deletions(-) + Parent Hashes: e9f02a8027675e3957d463d7f8422d79fa90f2ba +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit allows llvm tools to be overridden in the runqslower Makefile for flexibility, aligning with the selftests/bpf Makefile.", + "keywords": "llvm, overriding, Makefile", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit allows llvm tools to be overridden in the runqslower Makefile for flexibility, aligning with the selftests/bpf Makefile.", + "keywords": "llvm, overriding, Makefile", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 615/6895 - Commit ID: e9f02a8027675e3957d463d7f8422d79fa90f2ba +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: e9f02a8027675e3957d463d7f8422d79fa90f2ba + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1579965166 + Commit Message: + Merge branch 'trampoline-fixes' Jiri Olsa says: ==================== hi, sending 2 fixes to fix kernel support for loading trampoline programs in bcc/bpftrace and allow to unwind through trampoline/dispatcher. Original rfc post [1]. Speedup output of perf bench while running klockstat.py on kprobes vs trampolines: Without: $ perf bench sched messaging -l 50000 ... Total time: 18.571 [sec] With current kprobe tracing: $ perf bench sched messaging -l 50000 ... Total time: 183.395 [sec] With kfunc tracing: $ perf bench sched messaging -l 50000 ... Total time: 39.773 [sec] v4 changes: - rebased on latest bpf-next/master - removed image tree mutex and use trampoline_mutex instead - checking directly for string pointer in patch 1 [Alexei] - skipped helpers patches, as they are no longer needed [Alexei] v3 changes: - added ack from John Fastabend for patch 1 - move out is_bpf_image_address from is_bpf_text_address call [David] v2 changes: - make the unwind work for dispatcher as well - added test for allowed trampolines count - used raw tp pt_regs nest-arrays for trampoline helpers thanks, jirka [1] https://lore.kernel.org/netdev/20191229143740.29143-1-jolsa@kernel.org/ ==================== Signed-off-by: Alexei Starovoitov + Changed Files: nan + Parent Hashes: 35b9211c0a2427e8f39e534f442f43804fc8d5ca d633d57902a510debd4ec5b7a374a009c8c2d620 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit merges 'trampoline-fixes' branch to improve kernel support for loading trampoline programs and allow unwinding through trampoline and dispatcher.", + "keywords": "trampoline, fixes, kernel", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.", + "It's likely a merge commit. It involves changes across multiple use cases or events.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +Rethinking... +new content: +{ + "summary": "The commit merges 'trampoline-fixes' branch to improve kernel support for loading trampoline programs and allow unwinding through trampoline and dispatcher.", + "keywords": "trampoline, fixes, kernel", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.", + "It's likely a merge commit. It involves changes across multiple use cases or events.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +-------------------- +-------------------- +Processing Commit 616/6895 - Commit ID: d633d57902a510debd4ec5b7a374a009c8c2d620 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: d633d57902a510debd4ec5b7a374a009c8c2d620 + Author Name: Jiri Olsa + Author Email: jolsa@kernel.org + Commit Date: 1579965160 + Commit Message: + selftest/bpf: Add test for allowed trampolines count There's limit of 40 programs tht can be attached to trampoline for one function. Adding test that tries to attach that many plus one extra that needs to fail. Signed-off-by: Jiri Olsa Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200123161508.915203-4-jolsa@kernel.org + Changed Files: .../selftests/bpf/prog_tests/trampoline_count.c | 112 +++++++++++++++++++++; .../selftests/bpf/progs/test_trampoline_count.c | 21 ++++; 2 files changed, 133 insertions(+) + Parent Hashes: e9b4e606c2289d6610113253922bb8c9ac7f68b0 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds a self-test for the limit on the number of eBPF trampolines that can be attached to a single function.", + "keywords": "selftest, trampolines, limit", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds a self-test for the limit on trampoline counts in eBPF programs.", + "keywords": "selftest, trampolines, limit", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 617/6895 - Commit ID: e9b4e606c2289d6610113253922bb8c9ac7f68b0 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: e9b4e606c2289d6610113253922bb8c9ac7f68b0 + Author Name: Jiri Olsa + Author Email: jolsa@kernel.org + Commit Date: 1579965160 + Commit Message: + bpf: Allow to resolve bpf trampoline and dispatcher in unwind When unwinding the stack we need to identify each address to successfully continue. Adding latch tree to keep trampolines for quick lookup during the unwind. The patch uses first 48 bytes for latch tree node, leaving 4048 bytes from the rest of the page for trampoline or dispatcher generated code. It's still enough not to affect trampoline and dispatcher progs maximum counts. Signed-off-by: Jiri Olsa Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200123161508.915203-3-jolsa@kernel.org + Changed Files: include/linux/bpf.h | 12 +++++++-; kernel/bpf/dispatcher.c | 4 +--; kernel/bpf/trampoline.c | 80 ++++++++++++++++++++++++++++++++++++++++++++-----; kernel/extable.c | 7 +++--; 4 files changed, 90 insertions(+), 13 deletions(-) + Parent Hashes: 84ad7a7ab69f112c0c4b878c9be91b950a1fb1f8 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Add latch tree for quick lookup of bpf trampoline and dispatcher during stack unwinding.", + "keywords": "trampoline,dispatcher,unwind", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Adds latch tree for quick lookup of bpf trampoline during stack unwinding.", + "keywords": "trampoline,dispatcher,unwind", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 618/6895 - Commit ID: 84ad7a7ab69f112c0c4b878c9be91b950a1fb1f8 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 84ad7a7ab69f112c0c4b878c9be91b950a1fb1f8 + Author Name: Jiri Olsa + Author Email: jolsa@kernel.org + Commit Date: 1579965160 + Commit Message: + bpf: Allow BTF ctx access for string pointers When accessing the context we allow access to arguments with scalar type and pointer to struct. But we deny access for pointer to scalar type, which is the case for many functions. Alexei suggested to take conservative approach and allow currently only string pointer access, which is the case for most functions now: Adding check if the pointer is to string type and allow access to it. Suggested-by: Alexei Starovoitov Signed-off-by: Jiri Olsa Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200123161508.915203-2-jolsa@kernel.org + Changed Files: kernel/bpf/btf.c | 16 ++++++++++++++++; 1 file changed, 16 insertions(+) + Parent Hashes: 35b9211c0a2427e8f39e534f442f43804fc8d5ca +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit enables BTF context access for string pointers in eBPF by adding a type check.", + "keywords": "BTF, string, pointers", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit allows BTF context access for string pointers in eBPF programs by implementing a type check.", + "keywords": "BTF,string,pointers", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 619/6895 - Commit ID: 35b9211c0a2427e8f39e534f442f43804fc8d5ca +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 35b9211c0a2427e8f39e534f442f43804fc8d5ca + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1579901677 + Commit Message: + libbpf: Fix realloc usage in bpf_core_find_cands Fix bug requesting invalid size of reallocated array when constructing CO-RE relocation candidate list. This can cause problems if there are many potential candidates and a very fine-grained memory allocator bucket sizes are used. Fixes: ddc7c3042614 ("libbpf: implement BPF CO-RE offset relocation algorithm") Reported-by: William Smith Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200124201847.212528-1-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.c | 4 +++-; 1 file changed, 3 insertions(+), 1 deletion(-) + Parent Hashes: d7a252708dbc950ca2064310217e8b9f85846e2f +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes a bug in libbpf for reallocating an array size in CO-RE relocation candidate construction.", + "keywords": "libbpf,bug,reallocation", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes a bug in libbpf related to reallocating array sizes for CO-RE relocation candidates.", + "keywords": "libbpf,bug,CO-RE", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 620/6895 - Commit ID: d7a252708dbc950ca2064310217e8b9f85846e2f +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: d7a252708dbc950ca2064310217e8b9f85846e2f + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1579900586 + Commit Message: + libbpf: Improve handling of failed CO-RE relocations Previously, if libbpf failed to resolve CO-RE relocation for some instructions, it would either return error immediately, or, if .relaxed_core_relocs option was set, would replace relocatable offset/imm part of an instruction with a bogus value (-1). Neither approach is good, because there are many possible scenarios where relocation is expected to fail (e.g., when some field knowingly can be missing on specific kernel versions). On the other hand, replacing offset with invalid one can hide programmer errors, if this relocation failue wasn't anticipated. This patch deprecates .relaxed_core_relocs option and changes the approach to always replacing instruction, for which relocation failed, with invalid BPF helper call instruction. For cases where this is expected, BPF program should already ensure that that instruction is unreachable, in which case this invalid instruction is going to be silently ignored. But if instruction wasn't guarded, BPF program will be rejected at verification step with verifier log pointing precisely to the place in assembly where the problem is. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200124053837.2434679-1-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.c | 95 +++++++++++++++++++++++++++++---------------------; tools/lib/bpf/libbpf.h | 6 +++-; 2 files changed, 61 insertions(+), 40 deletions(-) + Parent Hashes: 51bad0f05616c43d6d34b0a19bcc9bdab8e8fb39 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit improves libbpf's handling of failed CO-RE relocations by introducing invalid BPF helper call instructions for better error detection.", + "keywords": "libbpf, CO-RE, relocations", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit enhances libbpf by improving the error handling of failed CO-RE relocations using invalid BPF helper call instructions.", + "keywords": "libbpf, CO-RE, relocations", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 621/6895 - Commit ID: 51bad0f05616c43d6d34b0a19bcc9bdab8e8fb39 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 51bad0f05616c43d6d34b0a19bcc9bdab8e8fb39 + Author Name: Lorenz Bauer + Author Email: lmb@cloudflare.com + Commit Date: 1579900333 + Commit Message: + selftests: bpf: Reset global state between reuseport test runs Currently, there is a lot of false positives if a single reuseport test fails. This is because expected_results and the result map are not cleared. Zero both after individual test runs, which fixes the mentioned false positives. Fixes: 91134d849a0e ("bpf: Test BPF_PROG_TYPE_SK_REUSEPORT") Signed-off-by: Lorenz Bauer Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Sitnicki Acked-by: Martin KaFai Lau Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200124112754.19664-5-lmb@cloudflare.com + Changed Files: .../testing/selftests/bpf/prog_tests/select_reuseport.c | 16 ++++++++++++++--; 1 file changed, 14 insertions(+), 2 deletions(-) + Parent Hashes: 603fba9dfd0b2e2a844ece9ed98ce874c38aa98e +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Reset global state between reuseport test runs to prevent false positives in BPF selftests.", + "keywords": "selftests,bpf,reuseport", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Reset global state between reuseport test runs to prevent false positives in BPF selftests.", + "keywords": "selftests,bpf,reuseport", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 622/6895 - Commit ID: 603fba9dfd0b2e2a844ece9ed98ce874c38aa98e +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 603fba9dfd0b2e2a844ece9ed98ce874c38aa98e + Author Name: Lorenz Bauer + Author Email: lmb@cloudflare.com + Commit Date: 1579900333 + Commit Message: + selftests: bpf: Make reuseport test output more legible Include the name of the mismatching result in human readable format when reporting an error. The new output looks like the following: unexpected result result: [1, 0, 0, 0, 0, 0] expected: [0, 0, 0, 0, 0, 0] mismatch on DROP_ERR_INNER_MAP (bpf_prog_linum:153) check_results:FAIL:382 Signed-off-by: Lorenz Bauer Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Sitnicki Acked-by: Martin KaFai Lau Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200124112754.19664-4-lmb@cloudflare.com + Changed Files: .../selftests/bpf/prog_tests/select_reuseport.c | 28 ++++++++++++++++++----; 1 file changed, 24 insertions(+), 4 deletions(-) + Parent Hashes: 8bec4f665e0baecb5f1b683379fc10b3745eb612 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit enhances the legibility of error messages in the reuseport bpf selftest.", + "keywords": "selftests bpf output", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit enhances the readability of error messages in the reuseport bpf selftest output.", + "keywords": "selftests bpf reuseport", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 623/6895 - Commit ID: 8bec4f665e0baecb5f1b683379fc10b3745eb612 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 8bec4f665e0baecb5f1b683379fc10b3745eb612 + Author Name: Lorenz Bauer + Author Email: lmb@cloudflare.com + Commit Date: 1579900333 + Commit Message: + selftests: bpf: Ignore FIN packets for reuseport tests The reuseport tests currently suffer from a race condition: FIN packets count towards DROP_ERR_SKB_DATA, since they don't contain a valid struct cmd. Tests will spuriously fail depending on whether check_results is called before or after the FIN is processed. Exit the BPF program early if FIN is set. Fixes: 91134d849a0e ("bpf: Test BPF_PROG_TYPE_SK_REUSEPORT") Signed-off-by: Lorenz Bauer Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Sitnicki Acked-by: Martin KaFai Lau Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200124112754.19664-3-lmb@cloudflare.com + Changed Files: tools/testing/selftests/bpf/progs/test_select_reuseport_kern.c | 6 ++++++; 1 file changed, 6 insertions(+) + Parent Hashes: c31dbb1e41d1857b403f9bf58c87f5898519a0bc +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes a race condition in reuseport tests by ignoring FIN packets.", + "keywords": "selftests, bpf, reuseport", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes a race condition in reuseport tests by ignoring FIN packets.", + "keywords": "selftests, bpf, reuseport", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 624/6895 - Commit ID: c31dbb1e41d1857b403f9bf58c87f5898519a0bc +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: c31dbb1e41d1857b403f9bf58c87f5898519a0bc + Author Name: Lorenz Bauer + Author Email: lmb@cloudflare.com + Commit Date: 1579900333 + Commit Message: + selftests: bpf: Use a temporary file in test_sockmap Use a proper temporary file for sendpage tests. This means that running the tests doesn't clutter the working directory, and allows running the test on read-only filesystems. Fixes: 16962b2404ac ("bpf: sockmap, add selftests") Signed-off-by: Lorenz Bauer Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Sitnicki Acked-by: Martin KaFai Lau Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200124112754.19664-2-lmb@cloudflare.com + Changed Files: tools/testing/selftests/bpf/test_sockmap.c | 15 +++++----------; 1 file changed, 5 insertions(+), 10 deletions(-) + Parent Hashes: 41258289a8e9e3e110bab316e0aeded25fa8beb6 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit updates eBPF selftests to use a temporary file for sendpage tests, improving test environment compatibility.", + "keywords": "selftests,sockmap,temporary", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "This commit modifies BPF test_sockmap to use a temporary file for sendpage tests, enhancing filesystem compatibility.", + "keywords": "selftests,temporary,sockmap", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 625/6895 - Commit ID: 41258289a8e9e3e110bab316e0aeded25fa8beb6 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 41258289a8e9e3e110bab316e0aeded25fa8beb6 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1579860596 + Commit Message: + bpftool: Print function linkage in BTF dump Add printing out BTF_KIND_FUNC's linkage. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/20200124054317.2459436-1-andriin@fb.com + Changed Files: tools/bpf/bpftool/btf.c | 27 +++++++++++++++++++++++----; 1 file changed, 23 insertions(+), 4 deletions(-) + Parent Hashes: 03506297d205e5fa25b5ead0f6338b5a4a996a93 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds functionality to print function linkage in BTF dumps of bpftool.", + "keywords": "bpftool,BTF,function linkage", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit enhances bpftool by adding the capability to print function linkage in BTF dumps.", + "keywords": "bpftool,BTF,function", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 626/6895 - Commit ID: 03506297d205e5fa25b5ead0f6338b5a4a996a93 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 03506297d205e5fa25b5ead0f6338b5a4a996a93 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1579860561 + Commit Message: + selftests/bpf: Improve bpftool changes detection Detect when bpftool source code changes and trigger rebuild within selftests/bpf Makefile. Also fix few small formatting problems. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/20200124054148.2455060-1-andriin@fb.com + Changed Files: tools/testing/selftests/bpf/Makefile | 11 ++++++-----; 1 file changed, 6 insertions(+), 5 deletions(-) + Parent Hashes: 1a6fa10640d97e16d4184fa1c24aa8c3337d4653 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit improves change detection in bpftool and fixes formatting issues in the bpf selftest Makefile.", + "keywords": "bpftool,Makefile,selftests", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +Rethinking... +new content: +{ + "summary": "The commit improves change detection in bpftool and fixes formatting issues within the selftest Makefile.", + "keywords": "bpftool,Makefile,selftests", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 627/6895 - Commit ID: 1a6fa10640d97e16d4184fa1c24aa8c3337d4653 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 1a6fa10640d97e16d4184fa1c24aa8c3337d4653 + Author Name: John Sperbeck + Author Email: jsperbeck@google.com + Commit Date: 1579860345 + Commit Message: + selftests/bpf: Initialize duration variable before using The 'duration' variable is referenced in the CHECK() macro, and there are some uses of the macro before 'duration' is set. The clang compiler (validly) complains about this. Sample error: .../selftests/bpf/prog_tests/fexit_test.c:23:6: warning: variable 'duration' is uninitialized when used here [-Wuninitialized] if (CHECK(err, "prog_load sched cls", "err %d errno %d\n", err, errno)) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .../selftests/bpf/test_progs.h:134:25: note: expanded from macro 'CHECK' if (CHECK(err, "prog_load sched cls", "err %d errno %d\n", err, errno)) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _CHECK(condition, tag, duration, format) ^~~~~~~~ Signed-off-by: John Sperbeck Signed-off-by: Stanislav Fomichev Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200123235144.93610-1-sdf@google.com + Changed Files: tools/testing/selftests/bpf/prog_tests/fentry_test.c | 2 +-; tools/testing/selftests/bpf/prog_tests/fexit_bpf2bpf.c | 2 +-; tools/testing/selftests/bpf/prog_tests/fexit_test.c | 2 +-; 3 files changed, 3 insertions(+), 3 deletions(-) + Parent Hashes: 485ec2ea9cf556e9c120e07961b7b459d776a115 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit initializes the 'duration' variable in selftests/bpf to prevent compiler warnings about uninitialized use.", + "keywords": "selftests,initialize,duration", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit initializes the 'duration' variable to address compiler warnings in eBPF selftest files.", + "keywords": "selftests,initialize,duration", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 628/6895 - Commit ID: 485ec2ea9cf556e9c120e07961b7b459d776a115 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 485ec2ea9cf556e9c120e07961b7b459d776a115 + Author Name: Amol Grover + Author Email: frextrite@gmail.com + Commit Date: 1579816876 + Commit Message: + bpf, devmap: Pass lockdep expression to RCU lists head is traversed using hlist_for_each_entry_rcu outside an RCU read-side critical section but under the protection of dtab->index_lock. Hence, add corresponding lockdep expression to silence false-positive lockdep warnings, and harden RCU lists. Fixes: 6f9d451ab1a3 ("xdp: Add devmap_hash map type for looking up devices by hashed index") Signed-off-by: Amol Grover Signed-off-by: Daniel Borkmann Acked-by: Jesper Dangaard Brouer Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/20200123120437.26506-1-frextrite@gmail.com + Changed Files: kernel/bpf/devmap.c | 3 ++-; 1 file changed, 2 insertions(+), 1 deletion(-) + Parent Hashes: fd786fb1d2cad70b9aaba8c73872cbf63262bd58 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit silences false-positive lockdep warnings by adding lockdep expressions to RCU lists in devmap.", + "keywords": "RCU,lockdep,devmap", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +Rethinking... +new content: +{ + "summary": "The commit silences false-positive lockdep warnings by adding lockdep expressions to RCU lists in devmap.", + "keywords": "RCU,lockdep,devmap", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +-------------------- +-------------------- +Processing Commit 629/6895 - Commit ID: 954b3c4397792c8614aa4aaf25030ae87ece8307 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 954b3c4397792c8614aa4aaf25030ae87ece8307 + Author Name: David S. Miller + Author Email: davem@davemloft.net + Commit Date: 1579763416 + Commit Message: + Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next Alexei Starovoitov says: ==================== pull-request: bpf-next 2020-01-22 The following pull-request contains BPF updates for your *net-next* tree. We've added 92 non-merge commits during the last 16 day(s) which contain a total of 320 files changed, 7532 insertions(+), 1448 deletions(-). The main changes are: 1) function by function verification and program extensions from Alexei. 2) massive cleanup of selftests/bpf from Toke and Andrii. 3) batched bpf map operations from Brian and Yonghong. 4) tcp congestion control in bpf from Martin. 5) bulking for non-map xdp_redirect form Toke. 6) bpf_send_signal_thread helper from Yonghong. ==================== Signed-off-by: David S. Miller + Changed Files: nan + Parent Hashes: c5d19a6ecfce72d0352191d75f03eea4748a8c45 85cc12f85138f2ce3edf24833edd2179690306db +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges eBPF updates from the bpf-next branch, including verifications, cleanup of selftests, map operations, and congestion control enhancements.", + "keywords": "merge,updates,bpf", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges 92 changes improving verification map operations and TCP congestion control in the eBPF subsystem.", + "keywords": "verification,cleanup,merges", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 630/6895 - Commit ID: 85cc12f85138f2ce3edf24833edd2179690306db +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 85cc12f85138f2ce3edf24833edd2179690306db + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1579739415 + Commit Message: + Merge branch 'bpf_cubic' Martin KaFai Lau says: ==================== This set adds bpf_cubic.c example. It was separated from the earlier BPF STRUCT_OPS series. Some highlights since the last post: 1. It is based on EricD recent fixes to the kernel tcp_cubic. [1] 2. The bpf jiffies reading helper is inlined by the verifier. Different from the earlier version, it only reads jiffies alone and does not do usecs/jiffies conversion. 3. The bpf .kconfig map is used to read CONFIG_HZ. [1]: https://patchwork.ozlabs.org/cover/1215066/ v3: - Remove __weak from CONFIG_HZ in patch 3. (Andrii) v2: - Move inlining to fixup_bpf_calls() in patch 1. (Daniel) - It is inlined for 64 BITS_PER_LONG and jit_requested as the map_gen_lookup(). Other cases could be considered together with map_gen_lookup() if needed. - Use usec resolution in bictcp_update() calculation in patch 3. usecs_to_jiffies() is then removed(). (Eric) ==================== Signed-off-by: Alexei Starovoitov + Changed Files: nan + Parent Hashes: 1b2fd38de9fcc73d6994f8f6c7c23ee3435b6a12 6de4a9c430b57c6ebbccd2a1725f42e9be75f592 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit merges the bpf cubic example, based on kernel tcp cubic updates, with inline jiffies reading and kconfig map usage.", + "keywords": "bpf,cubic,merge", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "The commit merges the bpf_cubic example from a separate development branch, incorporating kernel tcp cubic improvements and inlining jiffies reading.", + "keywords": "bpf_cubic,merge,jiffies", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 631/6895 - Commit ID: 6de4a9c430b57c6ebbccd2a1725f42e9be75f592 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 6de4a9c430b57c6ebbccd2a1725f42e9be75f592 + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1579739410 + Commit Message: + bpf: tcp: Add bpf_cubic example This patch adds a bpf_cubic example. Some highlights: 1. CONFIG_HZ .kconfig map is used. 2. In bictcp_update(), calculation is changed to use usec resolution (i.e. USEC_PER_JIFFY) instead of using jiffies. Thus, usecs_to_jiffies() is not used in the bpf_cubic.c. 3. In bitctcp_update() [under tcp_friendliness], the original "while (ca->ack_cnt > delta)" loop is changed to the equivalent "ca->ack_cnt / delta" operation. Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200122233658.903774-1-kafai@fb.com + Changed Files: tools/testing/selftests/bpf/bpf_tcp_helpers.h | 16 +; .../testing/selftests/bpf/prog_tests/bpf_tcp_ca.c | 25 +; tools/testing/selftests/bpf/progs/bpf_cubic.c | 544 +++++++++++++++++++++; 3 files changed, 585 insertions(+) + Parent Hashes: 0a49c1a8e26266ad505704f54f9fdaf2ae14cbdb +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds a bpf_cubic example for TCP congestion control with changes to calculations for better resolution.", + "keywords": "bpf_cubic,tcp,example", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "tc related type programs. It affects programs managing traffic control (tc) for queuing or prioritizing network traffic." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds a bpf_cubic example for TCP congestion control with improved time resolution calculations.", + "keywords": "bpf_cubic,tcp,example", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "tc related type programs. It affects programs managing traffic control (tc) for queuing or prioritizing network traffic." + ] +} +-------------------- +-------------------- +Processing Commit 632/6895 - Commit ID: 0a49c1a8e26266ad505704f54f9fdaf2ae14cbdb +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 0a49c1a8e26266ad505704f54f9fdaf2ae14cbdb + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1579739410 + Commit Message: + bpf: Sync uapi bpf.h to tools/ This patch sync uapi bpf.h to tools/. Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200122233652.903348-1-kafai@fb.com + Changed Files: tools/include/uapi/linux/bpf.h | 9 ++++++++-; 1 file changed, 8 insertions(+), 1 deletion(-) + Parent Hashes: 5576b991e9c1a11d2cc21c4b94fc75ec27603896 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit synchronizes the uapi bpf.h file to the tools directory with minor changes.", + "keywords": "sync,uapi,bpf.h", + "commit_classification": "It's other type of commit. It does not fit into any of the categories listed above.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit synchronizes the uapi bpf.h file to the tools directory with minor changes.", + "keywords": "sync,uapi,bpf.h", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 633/6895 - Commit ID: 5576b991e9c1a11d2cc21c4b94fc75ec27603896 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 5576b991e9c1a11d2cc21c4b94fc75ec27603896 + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1579739410 + Commit Message: + bpf: Add BPF_FUNC_jiffies64 This patch adds a helper to read the 64bit jiffies. It will be used in a later patch to implement the bpf_cubic.c. The helper is inlined for jit_requested and 64 BITS_PER_LONG as the map_gen_lookup(). Other cases could be considered together with map_gen_lookup() if needed. Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200122233646.903260-1-kafai@fb.com + Changed Files: include/linux/bpf.h | 1 +; include/uapi/linux/bpf.h | 9 ++++++++-; kernel/bpf/core.c | 1 +; kernel/bpf/helpers.c | 12 ++++++++++++; kernel/bpf/verifier.c | 24 ++++++++++++++++++++++++; net/core/filter.c | 2 ++; 6 files changed, 48 insertions(+), 1 deletion(-) + Parent Hashes: 1b2fd38de9fcc73d6994f8f6c7c23ee3435b6a12 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit introduces a helper function to read 64-bit jiffies in eBPF for future use in bpf_cubic.c.", + "keywords": "helper,jiffies64,eBPF", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit introduces a helper function to read 64-bit jiffies in eBPF for future use in bpf_cubic.c.", + "keywords": "helper,jiffies64,eBPF", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 634/6895 - Commit ID: 1b2fd38de9fcc73d6994f8f6c7c23ee3435b6a12 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 1b2fd38de9fcc73d6994f8f6c7c23ee3435b6a12 + Author Name: Daniel Borkmann + Author Email: daniel@iogearbox.net + Commit Date: 1579730708 + Commit Message: + Merge branch 'bpf-dynamic-relinking' Alexei Starovoitov says: ==================== The last few month BPF community has been discussing an approach to call chaining, since exiting bpt_tail_call() mechanism used in production XDP programs has plenty of downsides. The outcome of these discussion was a conclusion to implement dynamic re-linking of BPF programs. Where rootlet XDP program attached to a netdevice can programmatically define a policy of execution of other XDP programs. Such rootlet would be compiled as normal XDP program and provide a number of placeholder global functions which later can be replaced with future XDP programs. BPF trampoline, function by function verification were building blocks towards that goal. The patch 1 is a final building block. It introduces dynamic program extensions. A number of improvements like more flexible function by function verification and better libbpf api will be implemented in future patches. v1->v2: - addressed Andrii's comments - rebase ==================== Signed-off-by: Daniel Borkmann + Changed Files: nan + Parent Hashes: 2a67a6ccb01f21b854715d86ff6432a18b97adb3 7805fe843964f81f98592bf580b9cd736ac4ad4c +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges the 'bpf-dynamic-relinking' branch, introducing dynamic program extensions for call chaining in XDP programs.", + "keywords": "dynamic,re-linking,XDP", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges the 'bpf-dynamic-relinking' branch, introducing dynamic program extensions for call chaining in XDP programs.", + "keywords": "dynamic,re-linking,XDP", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +-------------------- +-------------------- +Processing Commit 635/6895 - Commit ID: 7805fe843964f81f98592bf580b9cd736ac4ad4c +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 7805fe843964f81f98592bf580b9cd736ac4ad4c + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1579730693 + Commit Message: + selftests/bpf: Add tests for program extensions Add program extension tests that build on top of fexit_bpf2bpf tests. Replace three global functions in previously loaded test_pkt_access.c program with three new implementations: int get_skb_len(struct __sk_buff *skb); int get_constant(long val); int get_skb_ifindex(int val, struct __sk_buff *skb, int var); New function return the same results as original only if arguments match. new_get_skb_ifindex() demonstrates that 'skb' argument doesn't have to be first and only argument of BPF program. All normal skb based accesses are available. Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Acked-by: Andrii Nakryiko Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/20200121005348.2769920-4-ast@kernel.org + Changed Files: .../selftests/bpf/prog_tests/fexit_bpf2bpf.c | 20 +++++++-; tools/testing/selftests/bpf/progs/fexit_bpf2bpf.c | 57 ++++++++++++++++++++++; .../testing/selftests/bpf/progs/test_pkt_access.c | 8 ++-; 3 files changed, 83 insertions(+), 2 deletions(-) + Parent Hashes: 2db6eab18b9778d55f48c804f8efebd7097e7958 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds new program extension tests to the eBPF selftests focusing on function argument variations.", + "keywords": "selftests,program extension,tests", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds new program extension tests to the eBPF selftests to evaluate function argument compatibility in BPF programs.", + "keywords": "selftests,program,extension", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 636/6895 - Commit ID: 2db6eab18b9778d55f48c804f8efebd7097e7958 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 2db6eab18b9778d55f48c804f8efebd7097e7958 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1579730693 + Commit Message: + libbpf: Add support for program extensions Add minimal support for program extensions. bpf_object_open_opts() needs to be called with attach_prog_fd = target_prog_fd and BPF program extension needs to have in .c file section definition like SEC("freplace/func_to_be_replaced"). libbpf will search for "func_to_be_replaced" in the target_prog_fd's BTF and will pass it in attach_btf_id to the kernel. This approach works for tests, but more compex use case may need to request function name (and attach_btf_id that kernel sees) to be more dynamic. Such API will be added in future patches. Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Acked-by: Andrii Nakryiko Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/20200121005348.2769920-3-ast@kernel.org + Changed Files: tools/include/uapi/linux/bpf.h | 1 +; tools/lib/bpf/bpf.c | 3 ++-; tools/lib/bpf/libbpf.c | 13 ++++++++++---; tools/lib/bpf/libbpf.h | 2 ++; tools/lib/bpf/libbpf.map | 2 ++; tools/lib/bpf/libbpf_probes.c | 1 +; 6 files changed, 18 insertions(+), 4 deletions(-) + Parent Hashes: be8704ff07d2374bcc5c675526f95e70c6459683 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds minimal support for BPF program extensions in libbpf.", + "keywords": "libbpf,extensions,support", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit introduces initial support for BPF program extensions in the libbpf library.", + "keywords": "libbpf,extensions,support", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 637/6895 - Commit ID: be8704ff07d2374bcc5c675526f95e70c6459683 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: be8704ff07d2374bcc5c675526f95e70c6459683 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1579730692 + Commit Message: + bpf: Introduce dynamic program extensions Introduce dynamic program extensions. The users can load additional BPF functions and replace global functions in previously loaded BPF programs while these programs are executing. Global functions are verified individually by the verifier based on their types only. Hence the global function in the new program which types match older function can safely replace that corresponding function. This new function/program is called 'an extension' of old program. At load time the verifier uses (attach_prog_fd, attach_btf_id) pair to identify the function to be replaced. The BPF program type is derived from the target program into extension program. Technically bpf_verifier_ops is copied from target program. The BPF_PROG_TYPE_EXT program type is a placeholder. It has empty verifier_ops. The extension program can call the same bpf helper functions as target program. Single BPF_PROG_TYPE_EXT type is used to extend XDP, SKB and all other program types. The verifier allows only one level of replacement. Meaning that the extension program cannot recursively extend an extension. That also means that the maximum stack size is increasing from 512 to 1024 bytes and maximum function nesting level from 8 to 16. The programs don't always consume that much. The stack usage is determined by the number of on-stack variables used by the program. The verifier could have enforced 512 limit for combined original plus extension program, but it makes for difficult user experience. The main use case for extensions is to provide generic mechanism to plug external programs into policy program or function call chaining. BPF trampoline is used to track both fentry/fexit and program extensions because both are using the same nop slot at the beginning of every BPF function. Attaching fentry/fexit to a function that was replaced is not allowed. The opposite is true as well. Replacing a function that currently being analyzed with fentry/fexit is not allowed. The executable page allocated by BPF trampoline is not used by program extensions. This inefficiency will be optimized in future patches. Function by function verification of global function supports scalars and pointer to context only. Hence program extensions are supported for such class of global functions only. In the future the verifier will be extended with support to pointers to structures, arrays with sizes, etc. Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Acked-by: Andrii Nakryiko Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/20200121005348.2769920-2-ast@kernel.org + Changed Files: include/linux/bpf.h | 10 ++-; include/linux/bpf_types.h | 2 +; include/linux/btf.h | 5 ++; include/uapi/linux/bpf.h | 1 +; kernel/bpf/btf.c | 152 +++++++++++++++++++++++++++++++++++++++++++++-; kernel/bpf/syscall.c | 15 ++++-; kernel/bpf/trampoline.c | 41 ++++++++++++-; kernel/bpf/verifier.c | 85 ++++++++++++++++++++------; 8 files changed, 283 insertions(+), 28 deletions(-) + Parent Hashes: 2a67a6ccb01f21b854715d86ff6432a18b97adb3 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Introduce dynamic extensions allowing BPF programs to load new functions and replace global functions in existing BPF programs while executing.", + "keywords": "dynamic program extensions", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Introduce dynamic extensions allowing BPF programs to load new functions and replace global functions in existing BPF programs while executing.", + "keywords": "dynamic, extensions, BPF", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 638/6895 - Commit ID: 58c8db929db1c1d785a6f5d8f8692e5dbcc35e84 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 58c8db929db1c1d785a6f5d8f8692e5dbcc35e84 + Author Name: Jakub Sitnicki + Author Email: jakub@cloudflare.com + Commit Date: 1579721420 + Commit Message: + net, sk_msg: Don't check if sock is locked when tearing down psock As John Fastabend reports [0], psock state tear-down can happen on receive path *after* unlocking the socket, if the only other psock user, that is sockmap or sockhash, releases its psock reference before tcp_bpf_recvmsg does so: tcp_bpf_recvmsg() psock = sk_psock_get(sk) <- refcnt 2 lock_sock(sk); ... sock_map_free() <- refcnt 1 release_sock(sk) sk_psock_put() <- refcnt 0 Remove the lockdep check for socket lock in psock tear-down that got introduced in 7e81a3530206 ("bpf: Sockmap, ensure sock lock held during tear down"). [0] https://lore.kernel.org/netdev/5e25dc995d7d_74082aaee6e465b441@john-XPS-13-9370.notmuch/ Fixes: 7e81a3530206 ("bpf: Sockmap, ensure sock lock held during tear down") Reported-by: syzbot+d73682fcf7fee6982fe3@syzkaller.appspotmail.com Suggested-by: John Fastabend Signed-off-by: Jakub Sitnicki Acked-by: John Fastabend Acked-by: Daniel Borkmann Signed-off-by: David S. Miller + Changed Files: net/core/skmsg.c | 2 --; 1 file changed, 2 deletions(-) + Parent Hashes: d0f418516022c32ecceaf4275423e5bd3f8743a9 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Remove unnecessary socket lock check during psock teardown in sk_msg.", + "keywords": "psock,lock,tcp_bpf_recvmsg", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "Remove unnecessary socket lock check during psock teardown in sk_msg.", + "keywords": "psock,lock,tcp_bpf_recvmsg", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 639/6895 - Commit ID: 2a67a6ccb01f21b854715d86ff6432a18b97adb3 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 2a67a6ccb01f21b854715d86ff6432a18b97adb3 + Author Name: Chris Down + Author Email: chris@chrisdown.name + Commit Date: 1579711948 + Commit Message: + bpf, btf: Always output invariant hit in pahole DWARF to BTF transform When trying to compile with CONFIG_DEBUG_INFO_BTF enabled, I got this error: % make -s Failed to generate BTF for vmlinux Try to disable CONFIG_DEBUG_INFO_BTF make[3]: *** [vmlinux] Error 1 Compiling again without -s shows the true error (that pahole is missing), but since this is fatal, we should show the error unconditionally on stderr as well, not silence it using the `info` function. With this patch: % make -s BTF: .tmp_vmlinux.btf: pahole (pahole) is not available Failed to generate BTF for vmlinux Try to disable CONFIG_DEBUG_INFO_BTF make[3]: *** [vmlinux] Error 1 Signed-off-by: Chris Down Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200122000110.GA310073@chrisdown.name + Changed Files: scripts/link-vmlinux.sh | 4 ++--; 1 file changed, 2 insertions(+), 2 deletions(-) + Parent Hashes: 1222653cc0489fa9304a36f7d9593ecaeb51efe1 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit ensures unconditional output of pahole-related errors during the BTF build process for improved debugging.", + "keywords": "BTF, pahole, error", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit ensures the display of pahole errors during BTF generation for better debugging.", + "keywords": "BTF, pahole, debugging", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 640/6895 - Commit ID: 1222653cc0489fa9304a36f7d9593ecaeb51efe1 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 1222653cc0489fa9304a36f7d9593ecaeb51efe1 + Author Name: Daniel Díaz + Author Email: daniel.diaz@linaro.org + Commit Date: 1579711529 + Commit Message: + selftests/bpf: Build urandom_read with LDFLAGS and LDLIBS During cross-compilation, it was discovered that LDFLAGS and LDLIBS were not being used while building binaries, leading to defaults which were not necessarily correct. OpenEmbedded reported this kind of problem: ERROR: QA Issue: No GNU_HASH in the ELF binary [...], didn't pass LDFLAGS? Signed-off-by: Daniel Díaz Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Acked-by: John Fastabend + Changed Files: tools/testing/selftests/bpf/Makefile | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: f59bbfc2f6099e8655f9e8f585e10ffde17176d0 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit modifies the Makefile in eBPF selftests to use LDFLAGS and LDLIBS for building binaries, addressing cross-compilation issues.", + "keywords": "selftests Makefile LDFLAGS", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit modifies the Makefile in eBPF selftests to use LDFLAGS and LDLIBS for building binaries, addressing cross-compilation issues.", + "keywords": "selftests Makefile LDFLAGS", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 641/6895 - Commit ID: f59bbfc2f6099e8655f9e8f585e10ffde17176d0 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: f59bbfc2f6099e8655f9e8f585e10ffde17176d0 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1579691342 + Commit Message: + bpf: Fix error path under memory pressure Restore the 'if (env->cur_state)' check that was incorrectly removed during code move. Under memory pressure env->cur_state can be freed and zeroed inside do_check(). Hence the check is necessary. Fixes: 51c39bb1d5d1 ("bpf: Introduce function-by-function verification") Reported-by: syzbot+b296579ba5015704d9fa@syzkaller.appspotmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200122024138.3385590-1-ast@kernel.org + Changed Files: kernel/bpf/verifier.c | 9 +++++++--; 1 file changed, 7 insertions(+), 2 deletions(-) + Parent Hashes: 05d57f1793fb250c85028c9952c3720010baa853 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes a missing check for memory pressure conditions in the BPF verifier.", + "keywords": "fix, verifier, memory", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes a missing check for memory pressure conditions in the BPF verifier component.", + "keywords": "fix, verifier, memory", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 642/6895 - Commit ID: 05d57f1793fb250c85028c9952c3720010baa853 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 05d57f1793fb250c85028c9952c3720010baa853 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1579689081 + Commit Message: + bpf: Fix trampoline usage in preempt Though the second half of trampoline page is unused a task could be preempted in the middle of the first half of trampoline and two updates to trampoline would change the code from underneath the preempted task. Hence wait for tasks to voluntarily schedule or go to userspace. Add similar wait before freeing the trampoline. Fixes: fec56f5890d9 ("bpf: Introduce BPF trampoline") Reported-by: Jann Horn Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: Paul E. McKenney Link: https://lore.kernel.org/bpf/20200121032231.3292185-1-ast@kernel.org + Changed Files: kernel/bpf/trampoline.c | 10 ++++++++++; 1 file changed, 10 insertions(+) + Parent Hashes: 43a825afc91e2b06af1e8e7422198e759c2c5e20 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes a preemption issue in BPF trampoline usage by adding waiters before freeing or updating trampoline code.", + "keywords": "trampoline,preempt,fix", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes a preemption issue in BPF trampoline by adding waiters before freeing or updating trampoline code.", + "keywords": "trampoline,preempt,fix", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events." + ] +} +-------------------- +-------------------- +Processing Commit 643/6895 - Commit ID: 43a825afc91e2b06af1e8e7422198e759c2c5e20 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 43a825afc91e2b06af1e8e7422198e759c2c5e20 + Author Name: Björn Töpel + Author Email: bjorn.topel@intel.com + Commit Date: 1579648132 + Commit Message: + xsk, net: Make sock_def_readable() have external linkage XDP sockets use the default implementation of struct sock's sk_data_ready callback, which is sock_def_readable(). This function is called in the XDP socket fast-path, and involves a retpoline. By letting sock_def_readable() have external linkage, and being called directly, the retpoline can be avoided. Signed-off-by: Björn Töpel Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200120092917.13949-1-bjorn.topel@gmail.com + Changed Files: include/net/sock.h | 2 ++; net/core/sock.c | 2 +-; net/xdp/xsk.c | 2 +-; 3 files changed, 4 insertions(+), 2 deletions(-) + Parent Hashes: b87121dd3fa0a4d2636c0ad02a3b3fc5161fa26b +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit enhances XDP socket performance by avoiding retpoline via direct call to sock_def_readable with external linkage.", + "keywords": "XDP,sock_def_readable,retpoline", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +Rethinking... +new content: +{ + "summary": "The commit enhances XDP socket performance by avoiding retpoline via direct call to sock_def_readable with external linkage.", + "keywords": "XDP,sock_def_readable,retpoline", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +-------------------- +-------------------- +Processing Commit 644/6895 - Commit ID: b87121dd3fa0a4d2636c0ad02a3b3fc5161fa26b +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: b87121dd3fa0a4d2636c0ad02a3b3fc5161fa26b + Author Name: Al Viro + Author Email: viro@zeniv.linux.org.uk + Commit Date: 1579646781 + Commit Message: + bpf: don't bother with getname/kern_path - use user_path_at kernel/bpf/inode.c misuses kern_path...() - it's much simpler (and more efficient, on top of that) to use user_path...() counterparts rather than bothering with doing getname() manually. Signed-off-by: Al Viro Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200120232858.GF8904@ZenIV.linux.org.uk + Changed Files: kernel/bpf/inode.c | 43 +++++++++++++------------------------------; 1 file changed, 13 insertions(+), 30 deletions(-) + Parent Hashes: d49d0661b92478ec9362e379e7ba82450ec88048 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit refactors kernel/bpf/inode.c to use user_path_at instead of kern_path for efficiency.", + "keywords": "refactor, user_path_at, kern_path", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +Rethinking... +new content: +{ + "summary": "The commit improves efficiency by refactoring kernel/bpf/inode.c to use user_path_at instead of kern_path.", + "keywords": "refactor, efficiency, user_path_at", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The syscall interface. It changes the system calls through which user-space programs interact with eBPF.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 645/6895 - Commit ID: 9c5ed2f831c603439c699f8cd69e9998de472526 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 9c5ed2f831c603439c699f8cd69e9998de472526 + Author Name: David S. Miller + Author Email: davem@davemloft.net + Commit Date: 1579595158 + Commit Message: + Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec Steffen Klassert says: ==================== pull request (net): ipsec 2020-01-21 1) Fix packet tx through bpf_redirect() for xfrm and vti interfaces. From Nicolas Dichtel. 2) Do not confirm neighbor when do pmtu update on a virtual xfrm interface. From Xu Wang. 3) Support output_mark for offload ESP packets, this was forgotten when the output_mark was added initially. From Ulrich Weber. Please pull or let me know if there are problems. ==================== Signed-off-by: David S. Miller + Changed Files: nan + Parent Hashes: 80892772c4edac88c538165d26a0105f19b61c1c 4e4362d2bf2a49ff44dbbc9585207977ca3d71d0 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit merges a branch with fixes for packet transmissions through bpf_redirect and other ipsec enhancements.", + "keywords": "merge, ipsec, bpf_redirect", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "The commit merges a branch adding ipsec-related improvements and bpf_redirect packet transmission fixes.", + "keywords": "merge, ipsec, bpf_redirect", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 646/6895 - Commit ID: d49d0661b92478ec9362e379e7ba82450ec88048 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: d49d0661b92478ec9362e379e7ba82450ec88048 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1579567274 + Commit Message: + Merge branch 'libbpf-include-path' Toke Høiland-Jørgensen says: ==================== We are currently being somewhat inconsistent with the libbpf include paths, which makes it difficult to move files from the kernel into an external libbpf-using project without adjusting include paths. Having the bpf/ subdir of $INCLUDEDIR in the include path has never been a requirement for building against libbpf before, and indeed the libbpf pkg-config file doesn't include it. So let's make all libbpf includes across the kernel tree use the bpf/ prefix in their includes. Since bpftool skeleton generation emits code with a libbpf include, this also ensures that those can be used in existing external projects using the regular pkg-config include path. This turns out to be a somewhat invasive change in the number of files touched; however, the actual changes to files are fairly trivial (most of them are simply made with 'sed'). The series is split to make the change for one tool subdir at a time, while trying not to break the build along the way. It is structured like this: - Patch 1-3: Trivial fixes to Makefiles for issues I discovered while changing the include paths. - Patch 4-8: Change the include directives to use the bpf/ prefix, and updates Makefiles to make sure tools/lib/ is part of the include path, but without removing tools/lib/bpf - Patch 9-11: Remove tools/lib/bpf from include paths to make sure we don't inadvertently re-introduce includes without the bpf/ prefix. Changelog: v5: - Combine the libbpf build rules in selftests Makefile (using Andrii's suggestion for a make rule). - Re-use self-tests libbpf build for runqslower (new patch 10) - Formatting fixes v4: - Move runqslower error on missing BTF into make rule - Make sure we don't always force a rebuild selftests - Rebase on latest bpf-next (dropping patch 11) v3: - Don't add the kernel build dir to the runqslower Makefile, pass it in from selftests instead. - Use libbpf's 'make install_headers' in selftests instead of trying to generate bpf_helper_defs.h in-place (to also work on read-only filesystems). - Use a scratch builddir for both libbpf and bpftool when building in selftests. - Revert bpf_helpers.h to quoted include instead of angled include with a bpf/ prefix. - Fix a few style nits from Andrii v2: - Do a full cleanup of libbpf includes instead of just changing the bpf_helper_defs.h include. ==================== Acked-by: Andrii Nakryiko Tested-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov + Changed Files: nan + Parent Hashes: f1c3656c6d9c147d07d16614455aceb34932bdeb a2c9652f751e3ab39738e2b30bc45293d53604fd +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit merges changes to standardize libbpf include paths across the kernel tree.", + "keywords": "libbpf,inclusive paths,merge", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit merges changes to standardize libbpf include paths across the kernel tree.", + "keywords": "libbpf,inclusive paths,merge", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 647/6895 - Commit ID: a2c9652f751e3ab39738e2b30bc45293d53604fd +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: a2c9652f751e3ab39738e2b30bc45293d53604fd + Author Name: Toke Høiland-Jørgensen + Author Email: toke@redhat.com + Commit Date: 1579567066 + Commit Message: + selftests: Refactor build to remove tools/lib/bpf from include path To make sure no new files are introduced that doesn't include the bpf/ prefix in its #include, remove tools/lib/bpf from the include path entirely. Instead, we introduce a new header files directory under the scratch tools/ dir, and add a rule to run the 'install_headers' rule from libbpf to have a full set of consistent libbpf headers in $(OUTPUT)/tools/include/bpf, and then use $(OUTPUT)/tools/include as the include path for selftests. For consistency we also make sure we put all the scratch build files from other bpftool and libbpf into tools/build/, so everything stays within selftests/. Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/157952561246.1683545.2762245552022369203.stgit@toke.dk + Changed Files: tools/testing/selftests/bpf/.gitignore | 4 +--; tools/testing/selftests/bpf/Makefile | 59 +++++++++++++++++-----------------; 2 files changed, 30 insertions(+), 33 deletions(-) + Parent Hashes: b6580cd8999d4f6846db9f6daa0b759c75aff33e +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit refactors selftest build setup to isolate libbpf headers and use a consistent include path.", + "keywords": "refactor, selftests, libbpf", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit refactors selftest build setup to isolate libbpf headers and ensure a consistent include path.", + "keywords": "refactor, selftests, include", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 648/6895 - Commit ID: b6580cd8999d4f6846db9f6daa0b759c75aff33e +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: b6580cd8999d4f6846db9f6daa0b759c75aff33e + Author Name: Toke Høiland-Jørgensen + Author Email: toke@redhat.com + Commit Date: 1579567065 + Commit Message: + runsqslower: Support user-specified libbpf include and object paths This adds support for specifying the libbpf include and object paths as arguments to the runqslower Makefile, to support reusing the libbpf version built as part of the selftests. Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/157952561135.1683545.5660339645093141381.stgit@toke.dk + Changed Files: tools/bpf/runqslower/Makefile | 12 +++++++-----; 1 file changed, 7 insertions(+), 5 deletions(-) + Parent Hashes: a9ed34c0b7a537e38564d92eb4ff9eee91c84544 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds support for specifying libbpf include and object paths in the runqslower Makefile.", + "keywords": "libbpf,runqslower,Makefile", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds support for specifying libbpf include and object paths in the runqslower Makefile.", + "keywords": "libbpf,runqslower,Makefile", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 649/6895 - Commit ID: a9ed34c0b7a537e38564d92eb4ff9eee91c84544 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: a9ed34c0b7a537e38564d92eb4ff9eee91c84544 + Author Name: Toke Høiland-Jørgensen + Author Email: toke@redhat.com + Commit Date: 1579567065 + Commit Message: + tools/runqslower: Remove tools/lib/bpf from include path Since we are now consistently using the bpf/ prefix on #include directives, we don't need to include tools/lib/bpf in the include path. Remove it to make sure we don't inadvertently introduce new includes without the prefix. Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/157952561027.1683545.1976265477926794138.stgit@toke.dk + Changed Files: tools/bpf/runqslower/Makefile | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: 7cf245a37ef013b2c1c5ca7ae25061de2ba7ad01 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit removes an unnecessary include path in the runqslower Makefile to prevent incorrect include directives.", + "keywords": "include,path,runqslower", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit removes an unnecessary include path in the runqslower Makefile to prevent incorrect include directives.", + "keywords": "include,path,runqslower", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 650/6895 - Commit ID: 7cf245a37ef013b2c1c5ca7ae25061de2ba7ad01 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 7cf245a37ef013b2c1c5ca7ae25061de2ba7ad01 + Author Name: Toke Høiland-Jørgensen + Author Email: toke@redhat.com + Commit Date: 1579567065 + Commit Message: + samples/bpf: Use consistent include paths for libbpf Fix all files in samples/bpf to include libbpf header files with the bpf/ prefix, to be consistent with external users of the library. Also ensure that all includes of exported libbpf header files (those that are exported on 'make install' of the library) use bracketed includes instead of quoted. To make sure no new files are introduced that doesn't include the bpf/ prefix in its include, remove tools/lib/bpf from the include path entirely, and use tools/lib instead. Fixes: 6910d7d3867a ("selftests/bpf: Ensure bpf_helper_defs.h are taken from selftests dir") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Acked-by: Jesper Dangaard Brouer Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/157952560911.1683545.8795966751309534150.stgit@toke.dk + Changed Files: samples/bpf/Makefile | 3 +--; samples/bpf/cpustat_kern.c | 2 +-; samples/bpf/fds_example.c | 2 +-; samples/bpf/hbm.c | 4 ++--; samples/bpf/hbm_kern.h | 4 ++--; samples/bpf/ibumad_kern.c | 2 +-; samples/bpf/ibumad_user.c | 2 +-; samples/bpf/lathist_kern.c | 2 +-; samples/bpf/lwt_len_hist_kern.c | 2 +-; samples/bpf/map_perf_test_kern.c | 4 ++--; samples/bpf/offwaketime_kern.c | 4 ++--; samples/bpf/offwaketime_user.c | 2 +-; samples/bpf/parse_ldabs.c | 2 +-; samples/bpf/parse_simple.c | 2 +-; samples/bpf/parse_varlen.c | 2 +-; samples/bpf/sampleip_kern.c | 4 ++--; samples/bpf/sampleip_user.c | 2 +-; samples/bpf/sock_flags_kern.c | 2 +-; samples/bpf/sockex1_kern.c | 2 +-; samples/bpf/sockex1_user.c | 2 +-; samples/bpf/sockex2_kern.c | 2 +-; samples/bpf/sockex2_user.c | 2 +-; samples/bpf/sockex3_kern.c | 2 +-; samples/bpf/spintest_kern.c | 4 ++--; samples/bpf/spintest_user.c | 2 +-; samples/bpf/syscall_tp_kern.c | 2 +-; samples/bpf/task_fd_query_kern.c | 2 +-; samples/bpf/task_fd_query_user.c | 2 +-; samples/bpf/tc_l2_redirect_kern.c | 2 +-; samples/bpf/tcbpf1_kern.c | 2 +-; samples/bpf/tcp_basertt_kern.c | 4 ++--; samples/bpf/tcp_bufs_kern.c | 4 ++--; samples/bpf/tcp_clamp_kern.c | 4 ++--; samples/bpf/tcp_cong_kern.c | 4 ++--; samples/bpf/tcp_dumpstats_kern.c | 4 ++--; samples/bpf/tcp_iw_kern.c | 4 ++--; samples/bpf/tcp_rwnd_kern.c | 4 ++--; samples/bpf/tcp_synrto_kern.c | 4 ++--; samples/bpf/tcp_tos_reflect_kern.c | 4 ++--; samples/bpf/test_cgrp2_tc_kern.c | 2 +-; samples/bpf/test_current_task_under_cgroup_kern.c | 2 +-; samples/bpf/test_lwt_bpf.c | 2 +-; samples/bpf/test_map_in_map_kern.c | 4 ++--; samples/bpf/test_overhead_kprobe_kern.c | 4 ++--; samples/bpf/test_overhead_raw_tp_kern.c | 2 +-; samples/bpf/test_overhead_tp_kern.c | 2 +-; samples/bpf/test_probe_write_user_kern.c | 4 ++--; samples/bpf/trace_event_kern.c | 4 ++--; samples/bpf/trace_event_user.c | 2 +-; samples/bpf/trace_output_kern.c | 2 +-; samples/bpf/trace_output_user.c | 2 +-; samples/bpf/tracex1_kern.c | 4 ++--; samples/bpf/tracex2_kern.c | 4 ++--; samples/bpf/tracex3_kern.c | 4 ++--; samples/bpf/tracex4_kern.c | 4 ++--; samples/bpf/tracex5_kern.c | 4 ++--; samples/bpf/tracex6_kern.c | 2 +-; samples/bpf/tracex7_kern.c | 2 +-; samples/bpf/xdp1_kern.c | 2 +-; samples/bpf/xdp1_user.c | 4 ++--; samples/bpf/xdp2_kern.c | 2 +-; samples/bpf/xdp2skb_meta_kern.c | 2 +-; samples/bpf/xdp_adjust_tail_kern.c | 2 +-; samples/bpf/xdp_adjust_tail_user.c | 4 ++--; samples/bpf/xdp_fwd_kern.c | 2 +-; samples/bpf/xdp_fwd_user.c | 2 +-; samples/bpf/xdp_monitor_kern.c | 2 +-; samples/bpf/xdp_redirect_cpu_kern.c | 2 +-; samples/bpf/xdp_redirect_cpu_user.c | 2 +-; samples/bpf/xdp_redirect_kern.c | 2 +-; samples/bpf/xdp_redirect_map_kern.c | 2 +-; samples/bpf/xdp_redirect_map_user.c | 2 +-; samples/bpf/xdp_redirect_user.c | 2 +-; samples/bpf/xdp_router_ipv4_kern.c | 2 +-; samples/bpf/xdp_router_ipv4_user.c | 2 +-; samples/bpf/xdp_rxq_info_kern.c | 2 +-; samples/bpf/xdp_rxq_info_user.c | 4 ++--; samples/bpf/xdp_sample_pkts_kern.c | 2 +-; samples/bpf/xdp_sample_pkts_user.c | 2 +-; samples/bpf/xdp_tx_iptunnel_kern.c | 2 +-; samples/bpf/xdp_tx_iptunnel_user.c | 2 +-; samples/bpf/xdpsock_kern.c | 2 +-; samples/bpf/xdpsock_user.c | 6 +++---; 83 files changed, 112 insertions(+), 113 deletions(-) + Parent Hashes: 521fe8bb5874963d5f6fd58d5c5ad80fbc9c6b1c +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit standardizes include paths for libbpf in samples/bpf to ensure consistency with external users.", + "keywords": "libbpf, include, consistency", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit standardizes include paths for libbpf headers in samples/bpf to align with external usage conventions.", + "keywords": "libbpf, include, refactoring", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 651/6895 - Commit ID: 521fe8bb5874963d5f6fd58d5c5ad80fbc9c6b1c +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 521fe8bb5874963d5f6fd58d5c5ad80fbc9c6b1c + Author Name: Toke Høiland-Jørgensen + Author Email: toke@redhat.com + Commit Date: 1579567065 + Commit Message: + perf: Use consistent include paths for libbpf Fix perf to include libbpf header files with the bpf/ prefix, to be consistent with external users of the library. Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/157952560797.1683545.7685921032671386301.stgit@toke.dk + Changed Files: tools/perf/examples/bpf/5sec.c | 2 +-; tools/perf/examples/bpf/empty.c | 2 +-; tools/perf/examples/bpf/sys_enter_openat.c | 2 +-; tools/perf/include/bpf/pid_filter.h | 2 +-; tools/perf/include/bpf/stdio.h | 2 +-; tools/perf/include/bpf/unistd.h | 2 +-; 6 files changed, 6 insertions(+), 6 deletions(-) + Parent Hashes: 229c3b47b794e7257744224b21a95d3d9938d00a +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit updates perf tool code to consistently include libbpf headers using the bpf/ prefix.", + "keywords": "perf,libbpf,include", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit modifies include paths in the perf tool to use the bpf/ prefix for libbpf headers consistently.", + "keywords": "perf,libbpf,headers", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 652/6895 - Commit ID: 229c3b47b794e7257744224b21a95d3d9938d00a +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 229c3b47b794e7257744224b21a95d3d9938d00a + Author Name: Toke Høiland-Jørgensen + Author Email: toke@redhat.com + Commit Date: 1579567065 + Commit Message: + bpftool: Use consistent include paths for libbpf Fix bpftool to include libbpf header files with the bpf/ prefix, to be consistent with external users of the library. Also ensure that all includes of exported libbpf header files (those that are exported on 'make install' of the library) use bracketed includes instead of quoted. To make sure no new files are introduced that doesn't include the bpf/ prefix in its include, remove tools/lib/bpf from the include path entirely, and use tools/lib instead. Fixes: 6910d7d3867a ("selftests/bpf: Ensure bpf_helper_defs.h are taken from selftests dir") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/157952560684.1683545.4765181397974997027.stgit@toke.dk + Changed Files: tools/bpf/bpftool/Documentation/bpftool-gen.rst | 2 +-; tools/bpf/bpftool/Makefile | 2 +-; tools/bpf/bpftool/btf.c | 8 ++++----; tools/bpf/bpftool/btf_dumper.c | 2 +-; tools/bpf/bpftool/cgroup.c | 2 +-; tools/bpf/bpftool/common.c | 4 ++--; tools/bpf/bpftool/feature.c | 4 ++--; tools/bpf/bpftool/gen.c | 10 +++++-----; tools/bpf/bpftool/jit_disasm.c | 2 +-; tools/bpf/bpftool/main.c | 4 ++--; tools/bpf/bpftool/map.c | 4 ++--; tools/bpf/bpftool/map_perf_ring.c | 4 ++--; tools/bpf/bpftool/net.c | 8 ++++----; tools/bpf/bpftool/netlink_dumper.c | 4 ++--; tools/bpf/bpftool/perf.c | 2 +-; tools/bpf/bpftool/prog.c | 6 +++---; tools/bpf/bpftool/xlated_dumper.c | 2 +-; 17 files changed, 35 insertions(+), 35 deletions(-) + Parent Hashes: 3e689141e64df91b009a289c0559adedfe62f511 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Standardize include paths in bpftool for consistency with libbpf usage.", + "keywords": "bpftool,libbpf,include", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Standardize include paths in bpftool for consistency with libbpf usage.", + "keywords": "bpftool,libbpf,include", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 653/6895 - Commit ID: 3e689141e64df91b009a289c0559adedfe62f511 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 3e689141e64df91b009a289c0559adedfe62f511 + Author Name: Toke Høiland-Jørgensen + Author Email: toke@redhat.com + Commit Date: 1579567065 + Commit Message: + selftests: Use consistent include paths for libbpf Fix all selftests to include libbpf header files with the bpf/ prefix, to be consistent with external users of the library. Also ensure that all includes of exported libbpf header files (those that are exported on 'make install' of the library) use bracketed includes instead of quoted. To not break the build, keep the old include path until everything has been changed to the new one; a subsequent patch will remove that. Fixes: 6910d7d3867a ("selftests/bpf: Ensure bpf_helper_defs.h are taken from selftests dir") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/157952560568.1683545.9649335788846513446.stgit@toke.dk + Changed Files: tools/testing/selftests/bpf/Makefile | 2 +-; tools/testing/selftests/bpf/bpf_tcp_helpers.h | 4 ++--; tools/testing/selftests/bpf/bpf_trace_helpers.h | 2 +-; tools/testing/selftests/bpf/bpf_util.h | 2 +-; tools/testing/selftests/bpf/prog_tests/cpu_mask.c | 2 +-; tools/testing/selftests/bpf/prog_tests/perf_buffer.c | 2 +-; tools/testing/selftests/bpf/progs/bpf_dctcp.c | 4 ++--; tools/testing/selftests/bpf/progs/bpf_flow.c | 4 ++--; tools/testing/selftests/bpf/progs/connect4_prog.c | 4 ++--; tools/testing/selftests/bpf/progs/connect6_prog.c | 4 ++--; tools/testing/selftests/bpf/progs/dev_cgroup.c | 2 +-; tools/testing/selftests/bpf/progs/fentry_test.c | 2 +-; tools/testing/selftests/bpf/progs/fexit_bpf2bpf.c | 2 +-; tools/testing/selftests/bpf/progs/fexit_bpf2bpf_simple.c | 2 +-; tools/testing/selftests/bpf/progs/fexit_test.c | 2 +-; tools/testing/selftests/bpf/progs/get_cgroup_id_kern.c | 2 +-; tools/testing/selftests/bpf/progs/kfree_skb.c | 4 ++--; tools/testing/selftests/bpf/progs/loop1.c | 4 ++--; tools/testing/selftests/bpf/progs/loop2.c | 4 ++--; tools/testing/selftests/bpf/progs/loop3.c | 4 ++--; tools/testing/selftests/bpf/progs/loop4.c | 2 +-; tools/testing/selftests/bpf/progs/loop5.c | 2 +-; tools/testing/selftests/bpf/progs/netcnt_prog.c | 2 +-; tools/testing/selftests/bpf/progs/pyperf.h | 2 +-; tools/testing/selftests/bpf/progs/sample_map_ret0.c | 2 +-; tools/testing/selftests/bpf/progs/sendmsg4_prog.c | 4 ++--; tools/testing/selftests/bpf/progs/sendmsg6_prog.c | 4 ++--; tools/testing/selftests/bpf/progs/socket_cookie_prog.c | 4 ++--; tools/testing/selftests/bpf/progs/sockmap_parse_prog.c | 4 ++--; tools/testing/selftests/bpf/progs/sockmap_tcp_msg_prog.c | 4 ++--; tools/testing/selftests/bpf/progs/sockmap_verdict_prog.c | 4 ++--; tools/testing/selftests/bpf/progs/sockopt_inherit.c | 2 +-; tools/testing/selftests/bpf/progs/sockopt_multi.c | 2 +-; tools/testing/selftests/bpf/progs/sockopt_sk.c | 2 +-; tools/testing/selftests/bpf/progs/strobemeta.h | 2 +-; tools/testing/selftests/bpf/progs/tailcall1.c | 2 +-; tools/testing/selftests/bpf/progs/tailcall2.c | 2 +-; tools/testing/selftests/bpf/progs/tailcall3.c | 2 +-; tools/testing/selftests/bpf/progs/tailcall4.c | 2 +-; tools/testing/selftests/bpf/progs/tailcall5.c | 2 +-; tools/testing/selftests/bpf/progs/tcp_rtt.c | 2 +-; tools/testing/selftests/bpf/progs/test_adjust_tail.c | 2 +-; tools/testing/selftests/bpf/progs/test_attach_probe.c | 2 +-; tools/testing/selftests/bpf/progs/test_btf_haskv.c | 2 +-; tools/testing/selftests/bpf/progs/test_btf_newkv.c | 2 +-; tools/testing/selftests/bpf/progs/test_btf_nokv.c | 2 +-; tools/testing/selftests/bpf/progs/test_core_extern.c | 2 +-; tools/testing/selftests/bpf/progs/test_core_reloc_arrays.c | 4 ++--; .../testing/selftests/bpf/progs/test_core_reloc_bitfields_direct.c | 4 ++--; .../testing/selftests/bpf/progs/test_core_reloc_bitfields_probed.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_existence.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_flavors.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_ints.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_kernel.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_misc.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_mods.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_nesting.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_primitives.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_ptr_as_arr.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_size.c | 4 ++--; tools/testing/selftests/bpf/progs/test_get_stack_rawtp.c | 2 +-; tools/testing/selftests/bpf/progs/test_global_data.c | 2 +-; tools/testing/selftests/bpf/progs/test_global_func1.c | 2 +-; tools/testing/selftests/bpf/progs/test_global_func3.c | 2 +-; tools/testing/selftests/bpf/progs/test_global_func5.c | 2 +-; tools/testing/selftests/bpf/progs/test_global_func6.c | 2 +-; tools/testing/selftests/bpf/progs/test_global_func7.c | 2 +-; tools/testing/selftests/bpf/progs/test_l4lb.c | 4 ++--; tools/testing/selftests/bpf/progs/test_l4lb_noinline.c | 4 ++--; tools/testing/selftests/bpf/progs/test_lirc_mode2_kern.c | 2 +-; tools/testing/selftests/bpf/progs/test_lwt_ip_encap.c | 4 ++--; tools/testing/selftests/bpf/progs/test_lwt_seg6local.c | 4 ++--; tools/testing/selftests/bpf/progs/test_map_in_map.c | 2 +-; tools/testing/selftests/bpf/progs/test_map_lock.c | 2 +-; tools/testing/selftests/bpf/progs/test_mmap.c | 2 +-; tools/testing/selftests/bpf/progs/test_obj_id.c | 2 +-; tools/testing/selftests/bpf/progs/test_overhead.c | 4 ++--; tools/testing/selftests/bpf/progs/test_perf_buffer.c | 2 +-; tools/testing/selftests/bpf/progs/test_pinning.c | 2 +-; tools/testing/selftests/bpf/progs/test_pinning_invalid.c | 2 +-; tools/testing/selftests/bpf/progs/test_pkt_access.c | 4 ++--; tools/testing/selftests/bpf/progs/test_pkt_md_access.c | 2 +-; tools/testing/selftests/bpf/progs/test_probe_user.c | 4 ++--; tools/testing/selftests/bpf/progs/test_queue_stack_map.h | 2 +-; tools/testing/selftests/bpf/progs/test_rdonly_maps.c | 2 +-; tools/testing/selftests/bpf/progs/test_seg6_loop.c | 4 ++--; tools/testing/selftests/bpf/progs/test_select_reuseport_kern.c | 4 ++--; tools/testing/selftests/bpf/progs/test_send_signal_kern.c | 2 +-; tools/testing/selftests/bpf/progs/test_sk_lookup_kern.c | 4 ++--; tools/testing/selftests/bpf/progs/test_skb_cgroup_id_kern.c | 2 +-; tools/testing/selftests/bpf/progs/test_skb_ctx.c | 2 +-; tools/testing/selftests/bpf/progs/test_skeleton.c | 2 +-; tools/testing/selftests/bpf/progs/test_sock_fields_kern.c | 4 ++--; tools/testing/selftests/bpf/progs/test_spin_lock.c | 2 +-; tools/testing/selftests/bpf/progs/test_stacktrace_build_id.c | 2 +-; tools/testing/selftests/bpf/progs/test_stacktrace_map.c | 2 +-; tools/testing/selftests/bpf/progs/test_sysctl_loop1.c | 2 +-; tools/testing/selftests/bpf/progs/test_sysctl_loop2.c | 2 +-; tools/testing/selftests/bpf/progs/test_sysctl_prog.c | 2 +-; tools/testing/selftests/bpf/progs/test_tc_edt.c | 4 ++--; tools/testing/selftests/bpf/progs/test_tc_tunnel.c | 4 ++--; tools/testing/selftests/bpf/progs/test_tcp_check_syncookie_kern.c | 4 ++--; tools/testing/selftests/bpf/progs/test_tcp_estats.c | 2 +-; tools/testing/selftests/bpf/progs/test_tcpbpf_kern.c | 4 ++--; tools/testing/selftests/bpf/progs/test_tcpnotify_kern.c | 4 ++--; tools/testing/selftests/bpf/progs/test_tracepoint.c | 2 +-; tools/testing/selftests/bpf/progs/test_tunnel_kern.c | 4 ++--; tools/testing/selftests/bpf/progs/test_verif_scale1.c | 2 +-; tools/testing/selftests/bpf/progs/test_verif_scale2.c | 2 +-; tools/testing/selftests/bpf/progs/test_verif_scale3.c | 2 +-; tools/testing/selftests/bpf/progs/test_xdp.c | 4 ++--; tools/testing/selftests/bpf/progs/test_xdp_bpf2bpf.c | 2 +-; tools/testing/selftests/bpf/progs/test_xdp_loop.c | 4 ++--; tools/testing/selftests/bpf/progs/test_xdp_meta.c | 2 +-; tools/testing/selftests/bpf/progs/test_xdp_noinline.c | 4 ++--; tools/testing/selftests/bpf/progs/test_xdp_redirect.c | 2 +-; tools/testing/selftests/bpf/progs/test_xdp_vlan.c | 4 ++--; tools/testing/selftests/bpf/progs/xdp_dummy.c | 2 +-; tools/testing/selftests/bpf/progs/xdp_redirect_map.c | 2 +-; tools/testing/selftests/bpf/progs/xdp_tx.c | 2 +-; tools/testing/selftests/bpf/progs/xdping_kern.c | 4 ++--; tools/testing/selftests/bpf/test_cpp.cpp | 6 +++---; tools/testing/selftests/bpf/test_hashmap.c | 2 +-; tools/testing/selftests/bpf/test_progs.h | 2 +-; tools/testing/selftests/bpf/test_sock.c | 2 +-; tools/testing/selftests/bpf/test_sockmap_kern.h | 4 ++--; tools/testing/selftests/bpf/test_sysctl.c | 2 +-; tools/testing/selftests/bpf/trace_helpers.h | 2 +-; 128 files changed, 181 insertions(+), 181 deletions(-) + Parent Hashes: 5b554ce518afee47d4ba4330ad8fbfd6e29e1c13 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit updates selftests to use consistent include paths and formats for libbpf headers without breaking the build.", + "keywords": "selftests,libbpf,include", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit updates selftests to use consistent include paths and formats for libbpf headers without breaking the build.", + "keywords": "selftests,libbpf,include", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 654/6895 - Commit ID: 5b554ce518afee47d4ba4330ad8fbfd6e29e1c13 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 5b554ce518afee47d4ba4330ad8fbfd6e29e1c13 + Author Name: Toke Høiland-Jørgensen + Author Email: toke@redhat.com + Commit Date: 1579567065 + Commit Message: + tools/runqslower: Use consistent include paths for libbpf Fix the runqslower tool to include libbpf header files with the bpf/ prefix, to be consistent with external users of the library. Also ensure that all includes of exported libbpf header files (those that are exported on 'make install' of the library) use bracketed includes instead of quoted. To not break the build, keep the old include path until everything has been changed to the new one; a subsequent patch will remove that. Fixes: 6910d7d3867a ("selftests/bpf: Ensure bpf_helper_defs.h are taken from selftests dir") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/157952560457.1683545.9913736511685743625.stgit@toke.dk + Changed Files: tools/bpf/runqslower/Makefile | 5 +++--; tools/bpf/runqslower/runqslower.bpf.c | 2 +-; tools/bpf/runqslower/runqslower.c | 4 ++--; 3 files changed, 6 insertions(+), 5 deletions(-) + Parent Hashes: bfe42797bc7e962f01028436e106769ca9338b65 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes include paths in runqslower tool for consistent usage of libbpf headers with external users.", + "keywords": "include paths, libbpf, runqslower", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes include paths in runqslower tool for consistent usage of libbpf headers with external users.", + "keywords": "include paths, libbpf, runqslower", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 655/6895 - Commit ID: bfe42797bc7e962f01028436e106769ca9338b65 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: bfe42797bc7e962f01028436e106769ca9338b65 + Author Name: Toke Høiland-Jørgensen + Author Email: toke@redhat.com + Commit Date: 1579567065 + Commit Message: + selftests: Pass VMLINUX_BTF to runqslower Makefile Add a VMLINUX_BTF variable with the locally-built path when calling the runqslower Makefile from selftests. This makes sure a simple 'make' invocation in the selftests dir works even when there is no BTF information for the running kernel. Do a wildcard expansion and include the same paths for BTF for the running kernel as in the runqslower Makefile, to make it possible to build selftests without having a vmlinux in the local tree. Also fix the make invocation to use $(OUTPUT)/tools as the destination directory instead of $(CURDIR)/tools. Fixes: 3a0d3092a4ed ("selftests/bpf: Build runqslower from selftests") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/157952560344.1683545.2723631988771664417.stgit@toke.dk + Changed Files: tools/testing/selftests/bpf/Makefile | 8 ++++++--; 1 file changed, 6 insertions(+), 2 deletions(-) + Parent Hashes: a835d38d41ca4f8eab5f97512446212f42f094a1 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit modifies the selftests Makefile to ensure proper BTF path handling and output directory configuration for the runqslower tool.", + "keywords": "selftests, Makefile, runqslower", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit modifies the selftests Makefile to ensure proper BTF path handling and output directory configuration for the runqslower tool.", + "keywords": "selftests, Makefile, runqslower", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 656/6895 - Commit ID: a835d38d41ca4f8eab5f97512446212f42f094a1 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: a835d38d41ca4f8eab5f97512446212f42f094a1 + Author Name: Toke Høiland-Jørgensen + Author Email: toke@redhat.com + Commit Date: 1579567065 + Commit Message: + tools/bpf/runqslower: Fix override option for VMLINUX_BTF The runqslower tool refuses to build without a file to read vmlinux BTF from. The build fails with an error message to override the location by setting the VMLINUX_BTF variable if autodetection fails. However, the Makefile doesn't actually work with that override - the error message is still emitted. Fix this by including the value of VMLINUX_BTF in the expansion, and only emitting the error message if the *result* is empty. Also permit running 'make clean' even though no VMLINUX_BTF is set. Fixes: 9c01546d26d2 ("tools/bpf: Add runqslower tool to tools/bpf") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/157952560237.1683545.17771785178857224877.stgit@toke.dk + Changed Files: tools/bpf/runqslower/Makefile | 19 ++++++++++---------; 1 file changed, 10 insertions(+), 9 deletions(-) + Parent Hashes: b2e5e93ae8af6a34bca536cdc4b453ab1e707b8b +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit fixes the override option for the VMLINUX_BTF variable in the runqslower tool's Makefile.", + "keywords": "runqslower,VMLINUX_BTF,Makefile", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit fixes the Makefile to correctly handle the VMLINUX_BTF variable override in the runqslower tool.", + "keywords": "runqslower,VMLINUX_BTF,Makefile", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 657/6895 - Commit ID: b2e5e93ae8af6a34bca536cdc4b453ab1e707b8b +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: b2e5e93ae8af6a34bca536cdc4b453ab1e707b8b + Author Name: Toke Høiland-Jørgensen + Author Email: toke@redhat.com + Commit Date: 1579567065 + Commit Message: + samples/bpf: Don't try to remove user's homedir on clean The 'clean' rule in the samples/bpf Makefile tries to remove backup files (ending in ~). However, if no such files exist, it will instead try to remove the user's home directory. While the attempt is mostly harmless, it does lead to a somewhat scary warning like this: rm: cannot remove '~': Is a directory Fix this by using find instead of shell expansion to locate any actual backup files that need to be removed. Fixes: b62a796c109c ("samples/bpf: allow make to be run from samples/bpf/ directory") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Acked-by: Jesper Dangaard Brouer Link: https://lore.kernel.org/bpf/157952560126.1683545.7273054725976032511.stgit@toke.dk + Changed Files: samples/bpf/Makefile | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: f1c3656c6d9c147d07d16614455aceb34932bdeb +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes the Makefile in samples/bpf to correctly remove only backup files without attempting to delete the user's home directory.", + "keywords": "Makefile, clean, backup", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes the Makefile in samples/bpf to only remove backup files and avoid unintended deletion attempts.", + "keywords": "Makefile, clean, backup", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 658/6895 - Commit ID: 4f29ad200f7b40fbcf73cd65f95087535ba78380 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 4f29ad200f7b40fbcf73cd65f95087535ba78380 + Author Name: Alexander Lobakin + Author Email: alobakin@dlink.ru + Commit Date: 1579563574 + Commit Message: + MIPS: syscalls: fix indentation of the 'SYSNR' message It also lacks a whitespace (copy'n'paste error?) and also messes up the output: SYSHDR arch/mips/include/generated/uapi/asm/unistd_n32.h SYSHDR arch/mips/include/generated/uapi/asm/unistd_n64.h SYSHDR arch/mips/include/generated/uapi/asm/unistd_o32.h SYSNR arch/mips/include/generated/uapi/asm/unistd_nr_n32.h SYSNR arch/mips/include/generated/uapi/asm/unistd_nr_n64.h SYSNR arch/mips/include/generated/uapi/asm/unistd_nr_o32.h WRAP arch/mips/include/generated/uapi/asm/bpf_perf_event.h WRAP arch/mips/include/generated/uapi/asm/ipcbuf.h After: SYSHDR arch/mips/include/generated/uapi/asm/unistd_n32.h SYSHDR arch/mips/include/generated/uapi/asm/unistd_n64.h SYSHDR arch/mips/include/generated/uapi/asm/unistd_o32.h SYSNR arch/mips/include/generated/uapi/asm/unistd_nr_n32.h SYSNR arch/mips/include/generated/uapi/asm/unistd_nr_n64.h SYSNR arch/mips/include/generated/uapi/asm/unistd_nr_o32.h WRAP arch/mips/include/generated/uapi/asm/bpf_perf_event.h WRAP arch/mips/include/generated/uapi/asm/ipcbuf.h Present since day 0 of syscall table generation introduction for MIPS. Fixes: 9bcbf97c6293 ("mips: add system call table generation support") Cc: # v5.0+ Signed-off-by: Alexander Lobakin Signed-off-by: Paul Burton Cc: Ralf Baechle Cc: James Hogan Cc: Masahiro Yamada Cc: Rob Herring Cc: linux-mips@vger.kernel.org Cc: linux-kernel@vger.kernel.org + Changed Files: arch/mips/kernel/syscalls/Makefile | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: 16202c09577f3d0c533274c0410b7de05fb0d458 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit fixes indentation in the 'SYSNR' message for MIPS syscall headers to correct a formatting issue.", + "keywords": "MIPS, indentation, syscalls", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +Rethinking... +new content: +{ + "summary": "This commit fixes indentation and formatting issues in the MIPS syscall header message.", + "keywords": "MIPS, syscalls, indentation", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +-------------------- +-------------------- +Processing Commit 659/6895 - Commit ID: f1c3656c6d9c147d07d16614455aceb34932bdeb +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: f1c3656c6d9c147d07d16614455aceb34932bdeb + Author Name: Hangbin Liu + Author Email: liuhangbin@gmail.com + Commit Date: 1579559218 + Commit Message: + selftests/bpf: Skip perf hw events test if the setup disabled it The same with commit 4e59afbbed96 ("selftests/bpf: skip nmi test when perf hw events are disabled"), it would make more sense to skip the test_stacktrace_build_id_nmi test if the setup (e.g. virtual machines) has disabled hardware perf events. Fixes: 13790d1cc72c ("bpf: add selftest for stackmap with build_id in NMI context") Signed-off-by: Hangbin Liu Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200117100656.10359-1-liuhangbin@gmail.com + Changed Files: tools/testing/selftests/bpf/prog_tests/stacktrace_build_id_nmi.c | 8 ++++++--; 1 file changed, 6 insertions(+), 2 deletions(-) + Parent Hashes: 396b83fa75a3deb9aa68296c090f4eb540917d9d +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit skips a BPF self-test for stackmap with build_id if hardware perf events are disabled.", + "keywords": "selftests,bpf,perf", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit modifies a BPF self-test to skip when hardware perf events are disabled on the setup.", + "keywords": "selftests,bpf,skip", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events." + ] +} +-------------------- +-------------------- +Processing Commit 660/6895 - Commit ID: 396b83fa75a3deb9aa68296c090f4eb540917d9d +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 396b83fa75a3deb9aa68296c090f4eb540917d9d + Author Name: Stanislav Fomichev + Author Email: sdf@google.com + Commit Date: 1579556943 + Commit Message: + selftests/bpf: Don't check for btf fd in test_btf After commit 0d13bfce023a ("libbpf: Don't require root for bpf_object__open()") we no longer load BTF during bpf_object__open(), so let's remove the expectation from test_btf that the fd is not -1. The test currently fails. Before: BTF libbpf test[1] (test_btf_haskv.o): do_test_file:4152:FAIL bpf_object__btf_fd: -1 BTF libbpf test[2] (test_btf_newkv.o): do_test_file:4152:FAIL bpf_object__btf_fd: -1 BTF libbpf test[3] (test_btf_nokv.o): do_test_file:4152:FAIL bpf_object__btf_fd: -1 After: BTF libbpf test[1] (test_btf_haskv.o): OK BTF libbpf test[2] (test_btf_newkv.o): OK BTF libbpf test[3] (test_btf_nokv.o): OK Fixes: 0d13bfce023a ("libbpf: Don't require root for bpf_object__open()") Signed-off-by: Stanislav Fomichev Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200118010546.74279-1-sdf@google.com + Changed Files: tools/testing/selftests/bpf/test_btf.c | 4 ----; 1 file changed, 4 deletions(-) + Parent Hashes: 2e3a94aa2bfc6de95a0700f0a868c6f5db3a9592 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit removes unnecessary BTF file descriptor checks in selftests for libbpf after changes allowing bpf_object__open() without loading BTF.", + "keywords": "selftests,BTF,libbpf", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit modifies libbpf selftests to remove BTF file descriptor checks after changes in bpf_object__open().", + "keywords": "selftests,BTF,libbpf", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 661/6895 - Commit ID: 2e3a94aa2bfc6de95a0700f0a868c6f5db3a9592 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 2e3a94aa2bfc6de95a0700f0a868c6f5db3a9592 + Author Name: Brian Vazquez + Author Email: brianvv@google.com + Commit Date: 1579555671 + Commit Message: + bpf: Fix memory leaks in generic update/delete batch ops Generic update/delete batch ops functions were using __bpf_copy_key without properly freeing the memory. Handle the memory allocation and copy_from_user separately. Fixes: aa2e93b8e58e ("bpf: Add generic support for update and delete batch ops") Reported-by: Dan Carpenter Signed-off-by: Brian Vazquez Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200119194040.128369-1-brianvv@google.com + Changed Files: kernel/bpf/syscall.c | 30 +++++++++++++++++++-----------; 1 file changed, 19 insertions(+), 11 deletions(-) + Parent Hashes: a6ed02cac690b635dbb938690e795812ce1e14ca +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit fixes memory leaks in bpf generic update/delete batch operations by handling memory allocation separately.", + "keywords": "memory, update, batch", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The syscall interface. It changes the system calls through which user-space programs interact with eBPF.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit addresses memory leaks in bpf's generic update and delete batch operations by separating memory allocation and copying.", + "keywords": "memory, update, leaks", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The syscall interface. It changes the system calls through which user-space programs interact with eBPF.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 662/6895 - Commit ID: 11a827294755ce3d07e14cfe257b3ec16ab56f34 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 11a827294755ce3d07e14cfe257b3ec16ab56f34 + Author Name: Linus Torvalds + Author Email: torvalds@linux-foundation.org + Commit Date: 1579464233 + Commit Message: + Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from David Miller: 1) Fix non-blocking connect() in x25, from Martin Schiller. 2) Fix spurious decryption errors in kTLS, from Jakub Kicinski. 3) Netfilter use-after-free in mtype_destroy(), from Cong Wang. 4) Limit size of TSO packets properly in lan78xx driver, from Eric Dumazet. 5) r8152 probe needs an endpoint sanity check, from Johan Hovold. 6) Prevent looping in tcp_bpf_unhash() during sockmap/tls free, from John Fastabend. 7) hns3 needs short frames padded on transmit, from Yunsheng Lin. 8) Fix netfilter ICMP header corruption, from Eyal Birger. 9) Fix soft lockup when low on memory in hns3, from Yonglong Liu. 10) Fix NTUPLE firmware command failures in bnxt_en, from Michael Chan. 11) Fix memory leak in act_ctinfo, from Eric Dumazet. * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (91 commits) cxgb4: reject overlapped queues in TC-MQPRIO offload cxgb4: fix Tx multi channel port rate limit net: sched: act_ctinfo: fix memory leak bnxt_en: Do not treat DSN (Digital Serial Number) read failure as fatal. bnxt_en: Fix ipv6 RFS filter matching logic. bnxt_en: Fix NTUPLE firmware command failures. net: systemport: Fixed queue mapping in internal ring map net: dsa: bcm_sf2: Configure IMP port for 2Gb/sec net: dsa: sja1105: Don't error out on disabled ports with no phy-mode net: phy: dp83867: Set FORCE_LINK_GOOD to default after reset net: hns: fix soft lockup when there is not enough memory net: avoid updating qdisc_xmit_lock_key in netdev_update_lockdep_key() net/sched: act_ife: initalize ife->metalist earlier netfilter: nat: fix ICMP header corruption on ICMP errors net: wan: lapbether.c: Use built-in RCU list checking netfilter: nf_tables: fix flowtable list del corruption netfilter: nf_tables: fix memory leak in nf_tables_parse_netdev_hooks() netfilter: nf_tables: remove WARN and add NLA_STRING upper limits netfilter: nft_tunnel: ERSPAN_VERSION must not be null netfilter: nft_tunnel: fix null-attribute check ... + Changed Files: nan + Parent Hashes: 5f43644394a96a8bcd8fc29a8bbd9c40b4465b54 b2383ad987a61bdd3a0a4ec3f343fbf0e3d9067b +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit merges networking fixes including memory leak resolutions and driver improvements from multiple contributors.", + "keywords": "networking, fixes, merge", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "The commit merges networking fixes including memory leak resolutions and driver improvements from multiple contributors.", + "keywords": "networking, fixes, merge", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 663/6895 - Commit ID: a6ed02cac690b635dbb938690e795812ce1e14ca +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: a6ed02cac690b635dbb938690e795812ce1e14ca + Author Name: KP Singh + Author Email: kpsingh@google.com + Commit Date: 1579298374 + Commit Message: + libbpf: Load btf_vmlinux only once per object. As more programs (TRACING, STRUCT_OPS, and upcoming LSM) use vmlinux BTF information, loading the BTF vmlinux information for every program in an object is sub-optimal. The fix was originally proposed in: https://lore.kernel.org/bpf/CAEf4BzZodr3LKJuM7QwD38BiEH02Cc1UbtnGpVkCJ00Mf+V_Qg@mail.gmail.com/ The btf_vmlinux is populated in the object if any of the programs in the object requires it just before the programs are loaded and freed after the programs finish loading. Reported-by: Andrii Nakryiko Signed-off-by: KP Singh Signed-off-by: Alexei Starovoitov Reviewed-by: Brendan Jackman Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200117212825.11755-1-kpsingh@chromium.org + Changed Files: tools/lib/bpf/libbpf.c | 153 ++++++++++++++++++++++++++++++++-----------------; 1 file changed, 101 insertions(+), 52 deletions(-) + Parent Hashes: c701917e647c6aaee5e7bbb7a2c1ca99e8552c58 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Optimize libbpf to load vmlinux BTF information only once per object, improving efficiency for tracing, struct_ops, and LSM programs.", + "keywords": "libbpf BTF vmlinux", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "LSM type related programs. It relates to eBPF programs used with Linux Security Modules (LSMs) for security enhancements.", + "Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems." + ] +} +Rethinking... +new content: +{ + "summary": "Optimize libbpf to load vmlinux BTF information only once per object, improving efficiency for tracing, struct_ops, and LSM programs.", + "keywords": "libbpf BTF vmlinux", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "LSM type related programs. It relates to eBPF programs used with Linux Security Modules (LSMs) for security enhancements.", + "Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems." + ] +} +-------------------- +-------------------- +Processing Commit 664/6895 - Commit ID: c701917e647c6aaee5e7bbb7a2c1ca99e8552c58 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: c701917e647c6aaee5e7bbb7a2c1ca99e8552c58 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1579278798 + Commit Message: + libbpf: Fix potential multiplication overflow in mmap() size calculation Prevent potential overflow performed in 32-bit integers, before assigning result to size_t. Reported by LGTM static analysis. Fixes: eba9c5f498a1 ("libbpf: Refactor global data map initialization") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200117060801.1311525-4-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: b7d7f3e185b6e643dcd49d1486b11cade8519008 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes a potential integer overflow issue in libbpf's mmap size calculation.", + "keywords": "libbpf, overflow, mmap", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes a potential integer overflow issue in libbpf's mmap size calculation.", + "keywords": "libbpf, overflow, mmap", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 665/6895 - Commit ID: b7d7f3e185b6e643dcd49d1486b11cade8519008 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: b7d7f3e185b6e643dcd49d1486b11cade8519008 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1579278798 + Commit Message: + libbpf: Simplify BTF initialization logic Current implementation of bpf_object's BTF initialization is very convoluted and thus prone to errors. It doesn't have to be like that. This patch simplifies it significantly. This code also triggered static analysis issues over logically dead code due to redundant error checks. This simplification should fix that as well. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200117060801.1311525-3-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.c | 19 ++++++-------------; 1 file changed, 6 insertions(+), 13 deletions(-) + Parent Hashes: bc0eb9a333918d2cc4f42f7f4cf09eaf029ac9de +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit simplifies the BTF initialization logic in libbpf to reduce errors and eliminate redundant code.", + "keywords": "BTF,libbpf,simplification", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit simplifies the BTF initialization logic in libbpf to reduce errors and eliminate redundant code.", + "keywords": "BTF,libbpf,simplification", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 666/6895 - Commit ID: bc0eb9a333918d2cc4f42f7f4cf09eaf029ac9de +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: bc0eb9a333918d2cc4f42f7f4cf09eaf029ac9de + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1579278797 + Commit Message: + libbpf: Fix error handling bug in btf_dump__new Fix missing jump to error handling in btf_dump__new, found by Coverity static code analysis. Fixes: 9f81654eebe8 ("libbpf: Expose BTF-to-C type declaration emitting API") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200117060801.1311525-2-andriin@fb.com + Changed Files: tools/lib/bpf/btf_dump.c | 1 +; 1 file changed, 1 insertion(+) + Parent Hashes: 81f2b572cf4fd5c4178fe0e2b5bb1ab096385fd8 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixed an error handling bug in btf_dump__new function detected by Coverity static code analysis.", + "keywords": "error, handling, bug", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Fixed an error handling bug in btf_dump__new function detected by Coverity static code analysis.", + "keywords": "error, handling, bug", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 667/6895 - Commit ID: 81f2b572cf4fd5c4178fe0e2b5bb1ab096385fd8 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 81f2b572cf4fd5c4178fe0e2b5bb1ab096385fd8 + Author Name: YueHaibing + Author Email: yuehaibing@huawei.com + Commit Date: 1579234524 + Commit Message: + bpf: Remove set but not used variable 'first_key' kernel/bpf/syscall.c: In function generic_map_lookup_batch: kernel/bpf/syscall.c:1339:7: warning: variable first_key set but not used [-Wunused-but-set-variable] It is never used, so remove it. Reported-by: Hulk Robot Signed-off-by: YueHaibing Signed-off-by: Alexei Starovoitov Acked-by: Brian Vazquez Link: https://lore.kernel.org/bpf/20200116145300.59056-1-yuehaibing@huawei.com + Changed Files: kernel/bpf/syscall.c | 2 --; 1 file changed, 2 deletions(-) + Parent Hashes: ba92660362ec42db3baee5af2b47b85d70c1c4be +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit removes an unused variable 'first_key' in the bpf syscall code to resolve a compiler warning.", + "keywords": "remove, unused, variable", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The syscall interface. It changes the system calls through which user-space programs interact with eBPF.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit removes an unused variable 'first_key' from the bpf syscall code.", + "keywords": "remove, unused, variable", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The syscall interface. It changes the system calls through which user-space programs interact with eBPF.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 668/6895 - Commit ID: ba92660362ec42db3baee5af2b47b85d70c1c4be +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: ba92660362ec42db3baee5af2b47b85d70c1c4be + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1579233821 + Commit Message: + Merge branch 'xdp_redirect-bulking' Toke Høiland-Jørgensen says: ==================== Since commit 96360004b862 ("xdp: Make devmap flush_list common for all map instances"), devmap flushing is a global operation instead of tied to a particular map. This means that with a bit of refactoring, we can finally fix the performance delta between the bpf_redirect_map() and bpf_redirect() helper functions, by introducing bulking for the latter as well. This series makes this change by moving the data structure used for the bulking into struct net_device itself, so we can access it even when there is not devmap. Once this is done, moving the bpf_redirect() helper to use the bulking mechanism becomes quite trivial, and brings bpf_redirect() up to the same as bpf_redirect_map(): Before: After: 1 CPU: bpf_redirect_map: 8.4 Mpps 8.4 Mpps (no change) bpf_redirect: 5.0 Mpps 8.4 Mpps (+68%) 2 CPUs: bpf_redirect_map: 15.9 Mpps 16.1 Mpps (+1% or ~no change) bpf_redirect: 9.5 Mpps 15.9 Mpps (+67%) After this patch series, the only semantics different between the two variants of the bpf() helper (apart from the absence of a map argument, obviously) is that the _map() variant will return an error if passed an invalid map index, whereas the bpf_redirect() helper will succeed, but drop packets on xdp_do_redirect(). This is because the helper has no reference to the calling netdev, so unfortunately we can't do the ifindex lookup directly in the helper. Changelog: v3: - Switch two more fields to avoid a list_head spanning two cache lines - Include Jesper's tracepoint patch - Also rename xdp_do_flush_map() - Fix a few nits from Maciej v2: - Consolidate code paths and tracepoints for map and non-map redirect variants (Björn) - Add performance data for 2-CPU test (Jesper) - Move fields to avoid shifting cache lines in struct net_device (Eric) ==================== Signed-off-by: Alexei Starovoitov + Changed Files: nan + Parent Hashes: 20f21d98cf12b8ecd69e8defc93fae9e3b353b13 58aa94f922c1b44e0919d1814d2eab5b9e8bf945 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges the 'xdp_redirect-bulking' branch to enhance performance of the bpf_redirect() helper function by introducing bulking mechanism similar to bpf_redirect_map().", + "keywords": "xdp_redirect bulking performance", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges the 'xdp_redirect-bulking' branch to improve bpf_redirect() performance by applying similar bulking to bpf_redirect_map().", + "keywords": "xdp_redirect bulking performance", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 669/6895 - Commit ID: 58aa94f922c1b44e0919d1814d2eab5b9e8bf945 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 58aa94f922c1b44e0919d1814d2eab5b9e8bf945 + Author Name: Jesper Dangaard Brouer + Author Email: brouer@redhat.com + Commit Date: 1579233814 + Commit Message: + devmap: Adjust tracepoint for map-less queue flush Now that we don't have a reference to a devmap when flushing the device bulk queue, let's change the the devmap_xmit tracepoint to remote the map_id and map_index fields entirely. Rearrange the fields so 'drops' and 'sent' stay in the same position in the tracepoint struct, to make it possible for the xdp_monitor utility to read both the old and the new format. Signed-off-by: Jesper Dangaard Brouer Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/157918768613.1458396.9165902403373826572.stgit@toke.dk + Changed Files: include/trace/events/xdp.h | 29 ++++++++++++-----------------; kernel/bpf/devmap.c | 2 +-; samples/bpf/xdp_monitor_kern.c | 8 +++-----; 3 files changed, 16 insertions(+), 23 deletions(-) + Parent Hashes: 1d233886dd904edbf239eeffe435c3308ae97625 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adjusts the devmap_xmit tracepoint to remove map_id and map_index fields for compatibility with both old and new formats.", + "keywords": "devmap,tracepoint,flush", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +Rethinking... +new content: +{ + "summary": "The commit refactors the devmap_xmit tracepoint by removing map_id and map_index fields for compatibility across formats.", + "keywords": "devmap,tracepoint,refactor", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +-------------------- +-------------------- +Processing Commit 670/6895 - Commit ID: 1d233886dd904edbf239eeffe435c3308ae97625 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 1d233886dd904edbf239eeffe435c3308ae97625 + Author Name: Toke Høiland-Jørgensen + Author Email: toke@redhat.com + Commit Date: 1579233814 + Commit Message: + xdp: Use bulking for non-map XDP_REDIRECT and consolidate code paths Since the bulk queue used by XDP_REDIRECT now lives in struct net_device, we can re-use the bulking for the non-map version of the bpf_redirect() helper. This is a simple matter of having xdp_do_redirect_slow() queue the frame on the bulk queue instead of sending it out with __bpf_tx_xdp(). Unfortunately we can't make the bpf_redirect() helper return an error if the ifindex doesn't exit (as bpf_redirect_map() does), because we don't have a reference to the network namespace of the ingress device at the time the helper is called. So we have to leave it as-is and keep the device lookup in xdp_do_redirect_slow(). Since this leaves less reason to have the non-map redirect code in a separate function, so we get rid of the xdp_do_redirect_slow() function entirely. This does lose us the tracepoint disambiguation, but fortunately the xdp_redirect and xdp_redirect_map tracepoints use the same tracepoint entry structures. This means both can contain a map index, so we can just amend the tracepoint definitions so we always emit the xdp_redirect(_err) tracepoints, but with the map ID only populated if a map is present. This means we retire the xdp_redirect_map(_err) tracepoints entirely, but keep the definitions around in case someone is still listening for them. With this change, the performance of the xdp_redirect sample program goes from 5Mpps to 8.4Mpps (a 68% increase). Since the flush functions are no longer map-specific, rename the flush() functions to drop _map from their names. One of the renamed functions is the xdp_do_flush_map() callback used in all the xdp-enabled drivers. To keep from having to update all drivers, use a #define to keep the old name working, and only update the virtual drivers in this patch. Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/157918768505.1458396.17518057312953572912.stgit@toke.dk + Changed Files: drivers/net/tun.c | 4 +-; drivers/net/veth.c | 2 +-; drivers/net/virtio_net.c | 2 +-; include/linux/bpf.h | 13 +++++-; include/linux/filter.h | 10 ++++-; include/trace/events/xdp.h | 101 ++++++++++++++++++++-------------------------; kernel/bpf/devmap.c | 32 +++++++++-----; net/core/filter.c | 90 +++++++++-------------------------------; 8 files changed, 108 insertions(+), 146 deletions(-) + Parent Hashes: 75ccae62cb8d42a619323a85c577107b8b37d797 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit optimizes the XDP_REDIRECT process by consolidating code paths and improving performance by using bulk queuing, resulting in a 68% performance increase for xdp_redirect.", + "keywords": "XDP_REDIRECT,bulking,performance", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +Rethinking... +new content: +{ + "summary": "This commit optimizes non-map XDP_REDIRECT by consolidating code paths and increasing performance using bulk queuing.", + "keywords": "XDP_REDIRECT,bulking,performance", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +-------------------- +-------------------- +Processing Commit 671/6895 - Commit ID: 75ccae62cb8d42a619323a85c577107b8b37d797 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 75ccae62cb8d42a619323a85c577107b8b37d797 + Author Name: Toke Høiland-Jørgensen + Author Email: toke@redhat.com + Commit Date: 1579233814 + Commit Message: + xdp: Move devmap bulk queue into struct net_device Commit 96360004b862 ("xdp: Make devmap flush_list common for all map instances"), changed devmap flushing to be a global operation instead of a per-map operation. However, the queue structure used for bulking was still allocated as part of the containing map. This patch moves the devmap bulk queue into struct net_device. The motivation for this is reusing it for the non-map variant of XDP_REDIRECT, which will be changed in a subsequent commit. To avoid other fields of struct net_device moving to different cache lines, we also move a couple of other members around. We defer the actual allocation of the bulk queue structure until the NETDEV_REGISTER notification devmap.c. This makes it possible to check for ndo_xdp_xmit support before allocating the structure, which is not possible at the time struct net_device is allocated. However, we keep the freeing in free_netdev() to avoid adding another RCU callback on NETDEV_UNREGISTER. Because of this change, we lose the reference back to the map that originated the redirect, so change the tracepoint to always return 0 as the map ID and index. Otherwise no functional change is intended with this patch. After this patch, the relevant part of struct net_device looks like this, according to pahole: /* --- cacheline 14 boundary (896 bytes) --- */ struct netdev_queue * _tx __attribute__((__aligned__(64))); /* 896 8 */ unsigned int num_tx_queues; /* 904 4 */ unsigned int real_num_tx_queues; /* 908 4 */ struct Qdisc * qdisc; /* 912 8 */ unsigned int tx_queue_len; /* 920 4 */ spinlock_t tx_global_lock; /* 924 4 */ struct xdp_dev_bulk_queue * xdp_bulkq; /* 928 8 */ struct xps_dev_maps * xps_cpus_map; /* 936 8 */ struct xps_dev_maps * xps_rxqs_map; /* 944 8 */ struct mini_Qdisc * miniq_egress; /* 952 8 */ /* --- cacheline 15 boundary (960 bytes) --- */ struct hlist_head qdisc_hash[16]; /* 960 128 */ /* --- cacheline 17 boundary (1088 bytes) --- */ struct timer_list watchdog_timer; /* 1088 40 */ /* XXX last struct has 4 bytes of padding */ int watchdog_timeo; /* 1128 4 */ /* XXX 4 bytes hole, try to pack */ struct list_head todo_list; /* 1136 16 */ /* --- cacheline 18 boundary (1152 bytes) --- */ Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Acked-by: Björn Töpel Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/157918768397.1458396.12673224324627072349.stgit@toke.dk + Changed Files: include/linux/netdevice.h | 13 ++++++----; include/trace/events/xdp.h | 2 +-; kernel/bpf/devmap.c | 63 ++++++++++++++++++++--------------------------; net/core/dev.c | 2 ++; 4 files changed, 38 insertions(+), 42 deletions(-) + Parent Hashes: 20f21d98cf12b8ecd69e8defc93fae9e3b353b13 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The devmap bulk queue is moved into struct net_device to facilitate XDP_REDIRECT improvements and manageable allocation during NETDEV_REGISTER.", + "keywords": "devmap, net_device, XDP_REDIRECT", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The devmap bulk queue is relocated into struct net_device to facilitate improvements in XDP_REDIRECT functionality.", + "keywords": "devmap, net_device, XDP_REDIRECT", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 672/6895 - Commit ID: 20f21d98cf12b8ecd69e8defc93fae9e3b353b13 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 20f21d98cf12b8ecd69e8defc93fae9e3b353b13 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1579233693 + Commit Message: + libbpf: Revert bpf_helper_defs.h inclusion regression Revert bpf_helpers.h's change to include auto-generated bpf_helper_defs.h through <> instead of "", which causes it to be searched in include path. This can break existing applications that don't have their include path pointing directly to where libbpf installs its headers. There is ongoing work to make all (not just bpf_helper_defs.h) includes more consistent across libbpf and its consumers, but this unbreaks user code as is right now without any regressions. Selftests still behave sub-optimally (taking bpf_helper_defs.h from libbpf's source directory, if it's present there), which will be fixed in subsequent patches. Fixes: 6910d7d3867a ("selftests/bpf: Ensure bpf_helper_defs.h are taken from selftests dir") Reported-by: Toke Høiland-Jørgensen Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200117004103.148068-1-andriin@fb.com + Changed Files: tools/lib/bpf/bpf_helpers.h | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: 35697c12d7ffd31a56d3c9604066a166b75d0169 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Reverts a header file inclusion change in libbpf to avoid breaking existing applications.", + "keywords": "revert, libbpf, headers", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Reverts a header inclusion method in libbpf to prevent application breakage due to path issues.", + "keywords": "revert, libbpf, include", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 673/6895 - Commit ID: 35697c12d7ffd31a56d3c9604066a166b75d0169 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 35697c12d7ffd31a56d3c9604066a166b75d0169 + Author Name: Yonghong Song + Author Email: yhs@fb.com + Commit Date: 1579210137 + Commit Message: + selftests/bpf: Fix test_progs send_signal flakiness with nmi mode Alexei observed that test_progs send_signal may fail if run with command line "./test_progs" and the tests will pass if just run "./test_progs -n 40". I observed similar issue with nmi subtest failure and added a delay 100 us in Commit ab8b7f0cb358 ("tools/bpf: Add self tests for bpf_send_signal_thread()") and the problem is gone for me. But the issue still exists in Alexei's testing environment. The current code uses sample_freq = 50 (50 events/second), which may not be enough. But if the sample_freq value is larger than sysctl kernel/perf_event_max_sample_rate, the perf_event_open syscall will fail. This patch changed nmi perf testing to use sample_period = 1, which means trying to sampling every event. This seems fixing the issue. Fixes: ab8b7f0cb358 ("tools/bpf: Add self tests for bpf_send_signal_thread()") Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200116174004.1522812-1-yhs@fb.com + Changed Files: tools/testing/selftests/bpf/prog_tests/send_signal.c | 6 +-----; 1 file changed, 1 insertion(+), 5 deletions(-) + Parent Hashes: 858e284f0ec18bff2620d9a6afe764dc683f8ba1 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes flakiness in test_progs' send_signal by adjusting the sample period in nmi mode.", + "keywords": "selftests,bpf,send_signal", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit resolves flakiness in bpf selftests by adjusting the sampling period for send_signal tests in nmi mode.", + "keywords": "selftests,bpf,flakiness", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 674/6895 - Commit ID: 858e284f0ec18bff2620d9a6afe764dc683f8ba1 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 858e284f0ec18bff2620d9a6afe764dc683f8ba1 + Author Name: Brian Vazquez + Author Email: brianvv@google.com + Commit Date: 1579185112 + Commit Message: + libbpf: Fix unneeded extra initialization in bpf_map_batch_common bpf_attr doesn't required to be declared with '= {}' as memset is used in the code. Fixes: 2ab3d86ea1859 ("libbpf: Add libbpf support to batch ops") Reported-by: Andrii Nakryiko Signed-off-by: Brian Vazquez Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200116045918.75597-1-brianvv@google.com + Changed Files: tools/lib/bpf/bpf.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: b65053cd94f46619b4aae746b98f2d8d9274540e +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit removes unnecessary initialization in libbpf's bpf_map_batch_common function.", + "keywords": "libbpf,initialization,bpf_map_batch_common", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit removes unnecessary initialization in libbpf's bpf_map_batch_common function.", + "keywords": "libbpf,initialization,bpf_map_batch_common", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 675/6895 - Commit ID: 3981f955eb27fd4f52b8cef198091530811229f2 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 3981f955eb27fd4f52b8cef198091530811229f2 + Author Name: David S. Miller + Author Email: davem@davemloft.net + Commit Date: 1579165480 + Commit Message: + Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf Daniel Borkmann says: ==================== pull-request: bpf 2020-01-15 The following pull-request contains BPF updates for your *net* tree. We've added 12 non-merge commits during the last 9 day(s) which contain a total of 13 files changed, 95 insertions(+), 43 deletions(-). The main changes are: 1) Fix refcount leak for TCP time wait and request sockets for socket lookup related BPF helpers, from Lorenz Bauer. 2) Fix wrong verification of ARSH instruction under ALU32, from Daniel Borkmann. 3) Batch of several sockmap and related TLS fixes found while operating more complex BPF programs with Cilium and OpenSSL, from John Fastabend. 4) Fix sockmap to read psock's ingress_msg queue before regular sk_receive_queue() to avoid purging data upon teardown, from Lingpeng Chen. 5) Fix printing incorrect pointer in bpftool's btf_dump_ptr() in order to properly dump a BPF map's value with BTF, from Martin KaFai Lau. ==================== Signed-off-by: David S. Miller + Changed Files: nan + Parent Hashes: 567110f147b352020138573a90476a1522210f62 85ddd9c3173102930c16b0cfe8dbb771af434532 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges BPF updates including fixes for socket-related helpers and improved sockmap handling.", + "keywords": "BPF, fixes, sockmap", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges various BPF updates with multiple bug fixes and improvements.", + "keywords": "BPF, fixes, updates", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 676/6895 - Commit ID: b65053cd94f46619b4aae746b98f2d8d9274540e +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: b65053cd94f46619b4aae746b98f2d8d9274540e + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1579142319 + Commit Message: + selftests/bpf: Add whitelist/blacklist of test names to test_progs Add ability to specify a list of test name substrings for selecting which tests to run. So now -t is accepting a comma-separated list of strings, similarly to how -n accepts a comma-separated list of test numbers. Additionally, add ability to blacklist tests by name. Blacklist takes precedence over whitelist. Blacklisting is important for cases where it's known that some tests can't pass (e.g., due to perf hardware events that are not available within VM). This is going to be used for libbpf testing in Travis CI in its Github repo. Example runs with just whitelist and whitelist + blacklist: $ sudo ./test_progs -tattach,core/existence #1 attach_probe:OK #6 cgroup_attach_autodetach:OK #7 cgroup_attach_multi:OK #8 cgroup_attach_override:OK #9 core_extern:OK #10/44 existence:OK #10/45 existence___minimal:OK #10/46 existence__err_int_sz:OK #10/47 existence__err_int_type:OK #10/48 existence__err_int_kind:OK #10/49 existence__err_arr_kind:OK #10/50 existence__err_arr_value_type:OK #10/51 existence__err_struct_type:OK #10 core_reloc:OK #19 flow_dissector_reattach:OK #60 tp_attach_query:OK Summary: 8/8 PASSED, 0 SKIPPED, 0 FAILED $ sudo ./test_progs -tattach,core/existence -bcgroup,flow/arr #1 attach_probe:OK #9 core_extern:OK #10/44 existence:OK #10/45 existence___minimal:OK #10/46 existence__err_int_sz:OK #10/47 existence__err_int_type:OK #10/48 existence__err_int_kind:OK #10/51 existence__err_struct_type:OK #10 core_reloc:OK #60 tp_attach_query:OK Summary: 4/6 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Cc: Julia Kartseva Link: https://lore.kernel.org/bpf/20200116005549.3644118-1-andriin@fb.com + Changed Files: tools/testing/selftests/bpf/test_progs.c | 83 ++++++++++++++++++++++++++++----; tools/testing/selftests/bpf/test_progs.h | 8 ++-; 2 files changed, 80 insertions(+), 11 deletions(-) + Parent Hashes: 7bcfea9615f60506e6573e35bb7596f776640509 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds functionality to whitelist and blacklist test names in the test_progs for better selecting tests to run, especially for libbpf testing.", + "keywords": "whitelist,blacklist,tests", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit enhances test infrastructure by adding whitelist and blacklist capabilities for selecting specific test names in test_progs.", + "keywords": "whitelist,blacklist,tests", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 677/6895 - Commit ID: 7bcfea9615f60506e6573e35bb7596f776640509 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 7bcfea9615f60506e6573e35bb7596f776640509 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1579130657 + Commit Message: + Merge branch 'bpftool-improvements' Martin Lau says: ==================== When a map is storing a kernel's struct, its map_info->btf_vmlinux_value_type_id is set. The first map type supporting it is BPF_MAP_TYPE_STRUCT_OPS. This series adds support to dump this kind of map with BTF. The first two patches are bug fixes which are only applicable to bpf-next. Please see individual patches for details. v3: - Remove unnecessary #include "libbpf_internal.h" from patch 5 v2: - Expose bpf_find_kernel_btf() as a LIBBPF_API in patch 3 (Andrii) - Cache btf_vmlinux in bpftool/map.c (Andrii) ==================== Signed-off-by: Alexei Starovoitov + Changed Files: nan + Parent Hashes: 990bca1fc8ad48f7f8b0786b739a9408017b7a74 4e1ea33292ff2ea0a82f52b2600abb4aba752094 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges the 'bpftool-improvements' branch, adding support to dump BPF_MAP_TYPE_STRUCT_OPS with BTF.", + "keywords": "bpftool, BTF, struct_ops", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges branch 'bpftool-improvements', adding features for handling BPF_MAP_TYPE_STRUCT_OPS with BTF.", + "keywords": "bpftool,BTF,struct_ops", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 678/6895 - Commit ID: 4e1ea33292ff2ea0a82f52b2600abb4aba752094 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 4e1ea33292ff2ea0a82f52b2600abb4aba752094 + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1579130607 + Commit Message: + bpftool: Support dumping a map with btf_vmlinux_value_type_id This patch makes bpftool support dumping a map's value properly when the map's value type is a type of the running kernel's btf. (i.e. map_info.btf_vmlinux_value_type_id is set instead of map_info.btf_value_type_id). The first usecase is for the BPF_MAP_TYPE_STRUCT_OPS. Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200115230044.1103008-1-kafai@fb.com + Changed Files: tools/bpf/bpftool/map.c | 61 ++++++++++++++++++++++++++++++++++++++++---------; 1 file changed, 50 insertions(+), 11 deletions(-) + Parent Hashes: 84c72ceee91c166e19b506d618dbe9df6eacce97 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit enhances bpftool to support dumping map values using kernel BTF value types, specifically for BPF_MAP_TYPE_STRUCT_OPS.", + "keywords": "bpftool,map,BTF", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems." + ] +} +Rethinking... +new content: +{ + "summary": "Enhances bpftool for dumping map values using kernel BTF types, focused on BPF_MAP_TYPE_STRUCT_OPS.", + "keywords": "bpftool,map,BTF", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems." + ] +} +-------------------- +-------------------- +Processing Commit 679/6895 - Commit ID: 84c72ceee91c166e19b506d618dbe9df6eacce97 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 84c72ceee91c166e19b506d618dbe9df6eacce97 + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1579130607 + Commit Message: + bpftool: Add struct_ops map name This patch adds BPF_MAP_TYPE_STRUCT_OPS to "struct_ops" name mapping so that "bpftool map show" can print the "struct_ops" map type properly. [root@arch-fb-vm1 bpf]# ~/devshare/fb-kernel/linux/tools/bpf/bpftool/bpftool map show id 8 8: struct_ops name dctcp flags 0x0 key 4B value 256B max_entries 1 memlock 4096B btf_id 7 Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200115230037.1102674-1-kafai@fb.com + Changed Files: tools/bpf/bpftool/map.c | 1 +; 1 file changed, 1 insertion(+) + Parent Hashes: fb2426ad00b136c88d57457504d1e843159a367a +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds BPF_MAP_TYPE_STRUCT_OPS to struct_ops name mapping in bpftool for proper map type display.", + "keywords": "struct_ops, bpftool, map", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds support for displaying BPF_MAP_TYPE_STRUCT_OPS map type in bpftool.", + "keywords": "bpftool, struct_ops, map", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems." + ] +} +-------------------- +-------------------- +Processing Commit 680/6895 - Commit ID: fb2426ad00b136c88d57457504d1e843159a367a +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: fb2426ad00b136c88d57457504d1e843159a367a + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1579130607 + Commit Message: + libbpf: Expose bpf_find_kernel_btf as a LIBBPF_API This patch exposes bpf_find_kernel_btf() as a LIBBPF_API. It will be used in 'bpftool map dump' in a following patch to dump a map with btf_vmlinux_value_type_id set. bpf_find_kernel_btf() is renamed to libbpf_find_kernel_btf() and moved to btf.c. As is included, some of the max/min type casting needs to be fixed. Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200115230031.1102305-1-kafai@fb.com + Changed Files: tools/lib/bpf/btf.c | 102 ++++++++++++++++++++++++++++++++++++++++++++---; tools/lib/bpf/btf.h | 2 +; tools/lib/bpf/libbpf.c | 93 ++----------------------------------------; tools/lib/bpf/libbpf.map | 1 +; 4 files changed, 102 insertions(+), 96 deletions(-) + Parent Hashes: 188a486619e6c9d7b8531ba6c4215b31304d293f +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit exposes bpf_find_kernel_btf as a LIBBPF_API and prepares it for use in bpftool map dump operations.", + "keywords": "libbpf, btf, api", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit exposes bpf_find_kernel_btf as a LIBBPF_API, renaming and moving the function, and fixing type casting issues.", + "keywords": "libbpf, btf, api", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 681/6895 - Commit ID: 188a486619e6c9d7b8531ba6c4215b31304d293f +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 188a486619e6c9d7b8531ba6c4215b31304d293f + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1579130607 + Commit Message: + bpftool: Fix missing BTF output for json during map dump The btf availability check is only done for plain text output. It causes the whole BTF output went missing when json_output is used. This patch simplifies the logic a little by avoiding passing "int btf" to map_dump(). For plain text output, the btf_wtr is only created when the map has BTF (i.e. info->btf_id != 0). The nullness of "json_writer_t *wtr" in map_dump() alone can decide if dumping BTF output is needed. As long as wtr is not NULL, map_dump() will print out the BTF-described data whenever a map has BTF available (i.e. info->btf_id != 0) regardless of json or plain-text output. In do_dump(), the "int btf" is also renamed to "int do_plain_btf". Fixes: 99f9863a0c45 ("bpftool: Match maps by name") Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Cc: Paul Chaignon Link: https://lore.kernel.org/bpf/20200115230025.1101828-1-kafai@fb.com + Changed Files: tools/bpf/bpftool/map.c | 42 ++++++++++++++++++++----------------------; 1 file changed, 20 insertions(+), 22 deletions(-) + Parent Hashes: d7de72674af53c3839eff091899f18c221dd30d2 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fix missing BTF output in JSON format during map dumps in bpftool.", + "keywords": "BTF, JSON, map", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Fix missing BTF output in JSON format during map dumps in bpftool.", + "keywords": "BTF, JSON, bpftool", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 682/6895 - Commit ID: d7de72674af53c3839eff091899f18c221dd30d2 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: d7de72674af53c3839eff091899f18c221dd30d2 + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1579130607 + Commit Message: + bpftool: Fix a leak of btf object When testing a map has btf or not, maps_have_btf() tests it by actually getting a btf_fd from sys_bpf(BPF_BTF_GET_FD_BY_ID). However, it forgot to btf__free() it. In maps_have_btf() stage, there is no need to test it by really calling sys_bpf(BPF_BTF_GET_FD_BY_ID). Testing non zero info.btf_id is good enough. Also, the err_close case is unnecessary, and also causes double close() because the calling func do_dump() will close() all fds again. Fixes: 99f9863a0c45 ("bpftool: Match maps by name") Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Cc: Paul Chaignon Link: https://lore.kernel.org/bpf/20200115230019.1101352-1-kafai@fb.com + Changed Files: tools/bpf/bpftool/map.c | 16 ++--------------; 1 file changed, 2 insertions(+), 14 deletions(-) + Parent Hashes: 990bca1fc8ad48f7f8b0786b739a9408017b7a74 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes a memory leak in bpftool related to handling BTF objects during map operations.", + "keywords": "bpftool, BTF, memory leak", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes a memory leak in bpftool related to handling BTF objects during map operations.", + "keywords": "bpftool,BTF,memory", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 683/6895 - Commit ID: 85ddd9c3173102930c16b0cfe8dbb771af434532 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 85ddd9c3173102930c16b0cfe8dbb771af434532 + Author Name: Daniel Borkmann + Author Email: daniel@iogearbox.net + Commit Date: 1579127183 + Commit Message: + Merge branch 'bpf-sockmap-tls-fixes' John Fastabend says: ==================== To date our usage of sockmap/tls has been fairly simple, the BPF programs did only well-defined pop, push, pull and apply/cork operations. Now that we started to push more complex programs into sockmap we uncovered a series of issues addressed here. Further OpenSSL3.0 version should be released soon with kTLS support so its important to get any remaining issues on BPF and kTLS support resolved. Additionally, I have a patch under development to allow sockmap to be enabled/disabled at runtime for Cilium endpoints. This allows us to stress the map insert/delete with kTLS more than previously where Cilium only added the socket to the map when it entered ESTABLISHED state and never touched it from the control path side again relying on the sockets own close() hook to remove it. To test I have a set of test cases in test_sockmap.c that expose these issues. Once we get fixes here merged and in bpf-next I'll submit the tests to bpf-next tree to ensure we don't regress again. Also I've run these patches in the Cilium CI with OpenSSL (master branch) this will run tools such as netperf, ab, wrk2, curl, etc. to get a broad set of testing. I'm aware of two more issues that we are working to resolve in another couple (probably two) patches. First we see an auth tag corruption in kTLS when sending small 1byte chunks under stress. I've not pinned this down yet. But, guessing because its under 1B stress tests it must be some error path being triggered. And second we need to ensure BPF RX programs are not skipped when kTLS ULP is loaded. This breaks some of the sockmap selftests when running with kTLS. I'll send a follow up for this. v2: I dropped a patch that added !0 size check in tls_push_record this originated from a panic I caught awhile ago with a trace in the crypto stack. But I can not reproduce it anymore so will dig into that and send another patch later if needed. Anyways after a bit of thought it would be nicer if tls/crypto/bpf didn't require special case handling for the !0 size. ==================== Signed-off-by: Daniel Borkmann + Changed Files: nan + Parent Hashes: 0af2ffc93a4b50948f9dad2786b7f1bd253bf0b9 7361d44896ff20d48bdd502d1a0cd66308055d45 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges branch 'bpf-sockmap-tls-fixes' to address issues with BPF programs in sockmap for kTLS support.", + "keywords": "sockmap, kTLS, BPF", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges branch 'bpf-sockmap-tls-fixes' to address BPF program issues in sockmap for enhanced kTLS support.", + "keywords": "sockmap, kTLS, BPF", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 684/6895 - Commit ID: 7361d44896ff20d48bdd502d1a0cd66308055d45 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 7361d44896ff20d48bdd502d1a0cd66308055d45 + Author Name: John Fastabend + Author Email: john.fastabend@gmail.com + Commit Date: 1579127173 + Commit Message: + bpf: Sockmap/tls, fix pop data with SK_DROP return code When user returns SK_DROP we need to reset the number of copied bytes to indicate to the user the bytes were dropped and not sent. If we don't reset the copied arg sendmsg will return as if those bytes were copied giving the user a positive return value. This works as expected today except in the case where the user also pops bytes. In the pop case the sg.size is reduced but we don't correctly account for this when copied bytes is reset. The popped bytes are not accounted for and we return a small positive value potentially confusing the user. The reason this happens is due to a typo where we do the wrong comparison when accounting for pop bytes. In this fix notice the if/else is not needed and that we have a similar problem if we push data except its not visible to the user because if delta is larger the sg.size we return a negative value so it appears as an error regardless. Fixes: 7246d8ed4dcce ("bpf: helper to pop data from messages") Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Acked-by: Jonathan Lemon Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20200111061206.8028-9-john.fastabend@gmail.com + Changed Files: net/ipv4/tcp_bpf.c | 5 +----; net/tls/tls_sw.c | 5 +----; 2 files changed, 2 insertions(+), 8 deletions(-) + Parent Hashes: 9aaaa56845a06aeabdd597cbe19492dc01f281ec +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes the handling of pop data when SK_DROP is returned by correcting the byte accounting.", + "keywords": "SK_DROP, pop, fix", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes popping data handling in Sockmap/tls when the SK_DROP return code is used by resetting copied byte counts.", + "keywords": "Sockmap,tls,SK_DROP", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 685/6895 - Commit ID: 9aaaa56845a06aeabdd597cbe19492dc01f281ec +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 9aaaa56845a06aeabdd597cbe19492dc01f281ec + Author Name: John Fastabend + Author Email: john.fastabend@gmail.com + Commit Date: 1579127173 + Commit Message: + bpf: Sockmap/tls, skmsg can have wrapped skmsg that needs extra chaining Its possible through a set of push, pop, apply helper calls to construct a skmsg, which is just a ring of scatterlist elements, with the start value larger than the end value. For example, end start |_0_|_1_| ... |_n_|_n+1_| Where end points at 1 and start points and n so that valid elements is the set {n, n+1, 0, 1}. Currently, because we don't build the correct chain only {n, n+1} will be sent. This adds a check and sg_chain call to correctly submit the above to the crypto and tls send path. Fixes: d3b18ad31f93d ("tls: add bpf support to sk_msg handling") Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Acked-by: Jonathan Lemon Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20200111061206.8028-8-john.fastabend@gmail.com + Changed Files: net/tls/tls_sw.c | 6 ++++++; 1 file changed, 6 insertions(+) + Parent Hashes: d468e4775c1c351616947ba0cccc43273963b9b5 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes a skmsg chaining issue in sockmap/tls to ensure proper handling of wrapped skmsg for crypto and TLS send paths.", + "keywords": "skmsg,chaining,tls", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes a skmsg chaining issue in sockmap/tls to ensure proper handling of wrapped skmsg for crypto and TLS send paths.", + "keywords": "skmsg,chaining,tls", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here." + ] +} +-------------------- +-------------------- +Processing Commit 686/6895 - Commit ID: d468e4775c1c351616947ba0cccc43273963b9b5 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: d468e4775c1c351616947ba0cccc43273963b9b5 + Author Name: John Fastabend + Author Email: john.fastabend@gmail.com + Commit Date: 1579127173 + Commit Message: + bpf: Sockmap/tls, tls_sw can create a plaintext buf > encrypt buf It is possible to build a plaintext buffer using push helper that is larger than the allocated encrypt buffer. When this record is pushed to crypto layers this can result in a NULL pointer dereference because the crypto API expects the encrypt buffer is large enough to fit the plaintext buffer. Kernel splat below. To resolve catch the cases this can happen and split the buffer into two records to send individually. Unfortunately, there is still one case to handle where the split creates a zero sized buffer. In this case we merge the buffers and unmark the split. This happens when apply is zero and user pushed data beyond encrypt buffer. This fixes the original case as well because the split allocated an encrypt buffer larger than the plaintext buffer and the merge simply moves the pointers around so we now have a reference to the new (larger) encrypt buffer. Perhaps its not ideal but it seems the best solution for a fixes branch and avoids handling these two cases, (a) apply that needs split and (b) non apply case. The are edge cases anyways so optimizing them seems not necessary unless someone wants later in next branches. [ 306.719107] BUG: kernel NULL pointer dereference, address: 0000000000000008 [...] [ 306.747260] RIP: 0010:scatterwalk_copychunks+0x12f/0x1b0 [...] [ 306.770350] Call Trace: [ 306.770956] scatterwalk_map_and_copy+0x6c/0x80 [ 306.772026] gcm_enc_copy_hash+0x4b/0x50 [ 306.772925] gcm_hash_crypt_remain_continue+0xef/0x110 [ 306.774138] gcm_hash_crypt_continue+0xa1/0xb0 [ 306.775103] ? gcm_hash_crypt_continue+0xa1/0xb0 [ 306.776103] gcm_hash_assoc_remain_continue+0x94/0xa0 [ 306.777170] gcm_hash_assoc_continue+0x9d/0xb0 [ 306.778239] gcm_hash_init_continue+0x8f/0xa0 [ 306.779121] gcm_hash+0x73/0x80 [ 306.779762] gcm_encrypt_continue+0x6d/0x80 [ 306.780582] crypto_gcm_encrypt+0xcb/0xe0 [ 306.781474] crypto_aead_encrypt+0x1f/0x30 [ 306.782353] tls_push_record+0x3b9/0xb20 [tls] [ 306.783314] ? sk_psock_msg_verdict+0x199/0x300 [ 306.784287] bpf_exec_tx_verdict+0x3f2/0x680 [tls] [ 306.785357] tls_sw_sendmsg+0x4a3/0x6a0 [tls] test_sockmap test signature to trigger bug, [TEST]: (1, 1, 1, sendmsg, pass,redir,start 1,end 2,pop (1,2),ktls,): Fixes: d3b18ad31f93d ("tls: add bpf support to sk_msg handling") Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Acked-by: Jonathan Lemon Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20200111061206.8028-7-john.fastabend@gmail.com + Changed Files: net/tls/tls_sw.c | 20 ++++++++++++++++++++; 1 file changed, 20 insertions(+) + Parent Hashes: cf21e9ba1eb86c9333ca5b05b2f1cc94021bcaef +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes a NULL pointer dereference bug in crypto layers by splitting and merging buffers in sockmap/tls.", + "keywords": "tls,plaintext,buffer", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "The commit resolves a bug causing NULL pointer dereference in sockmap/tls by handling buffer splitting issues during encryption.", + "keywords": "tls,plaintext,bug", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 687/6895 - Commit ID: cf21e9ba1eb86c9333ca5b05b2f1cc94021bcaef +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: cf21e9ba1eb86c9333ca5b05b2f1cc94021bcaef + Author Name: John Fastabend + Author Email: john.fastabend@gmail.com + Commit Date: 1579127173 + Commit Message: + bpf: Sockmap/tls, msg_push_data may leave end mark in place Leaving an incorrect end mark in place when passing to crypto layer will cause crypto layer to stop processing data before all data is encrypted. To fix clear the end mark on push data instead of expecting users of the helper to clear the mark value after the fact. This happens when we push data into the middle of a skmsg and have room for it so we don't do a set of copies that already clear the end flag. Fixes: 6fff607e2f14b ("bpf: sk_msg program helper bpf_msg_push_data") Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Acked-by: Song Liu Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20200111061206.8028-6-john.fastabend@gmail.com + Changed Files: net/core/filter.c | 1 +; 1 file changed, 1 insertion(+) + Parent Hashes: 6562e29cf6f0ddd368657d97a8d484ffc30df5ef +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes an issue in the bpf_msg_push_data helper function to ensure all data is correctly encrypted by clearing the end mark.", + "keywords": "fix,messaging,tls", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes a bug where the bpf_msg_push_data helper leaves an end mark affecting data encryption in socket messaging.", + "keywords": "bug,msg_push_data,tls", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 688/6895 - Commit ID: 6562e29cf6f0ddd368657d97a8d484ffc30df5ef +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 6562e29cf6f0ddd368657d97a8d484ffc30df5ef + Author Name: John Fastabend + Author Email: john.fastabend@gmail.com + Commit Date: 1579127173 + Commit Message: + bpf: Sockmap, skmsg helper overestimates push, pull, and pop bounds In the push, pull, and pop helpers operating on skmsg objects to make data writable or insert/remove data we use this bounds check to ensure specified data is valid, /* Bounds checks: start and pop must be inside message */ if (start >= offset + l || last >= msg->sg.size) return -EINVAL; The problem here is offset has already included the length of the current element the 'l' above. So start could be past the end of the scatterlist element in the case where start also points into an offset on the last skmsg element. To fix do the accounting slightly different by adding the length of the previous entry to offset at the start of the iteration. And ensure its initialized to zero so that the first iteration does nothing. Fixes: 604326b41a6fb ("bpf, sockmap: convert to generic sk_msg interface") Fixes: 6fff607e2f14b ("bpf: sk_msg program helper bpf_msg_push_data") Fixes: 7246d8ed4dcce ("bpf: helper to pop data from messages") Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Acked-by: Song Liu Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20200111061206.8028-5-john.fastabend@gmail.com + Changed Files: net/core/filter.c | 10 +++++-----; 1 file changed, 5 insertions(+), 5 deletions(-) + Parent Hashes: 33bfe20dd7117dd81fd896a53f743a233e1ad64f +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes an overestimation issue in skmsg helper bounds checks for push, pull, and pop operations in eBPF socket maps.", + "keywords": "skmsg,bounds,helper", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes an overestimation issue in skmsg helper bounds checks for push, pull, and pop operations in eBPF socket maps.", + "keywords": "skmsg,bounds,helper", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 689/6895 - Commit ID: 33bfe20dd7117dd81fd896a53f743a233e1ad64f +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 33bfe20dd7117dd81fd896a53f743a233e1ad64f + Author Name: John Fastabend + Author Email: john.fastabend@gmail.com + Commit Date: 1579127173 + Commit Message: + bpf: Sockmap/tls, push write_space updates through ulp updates When sockmap sock with TLS enabled is removed we cleanup bpf/psock state and call tcp_update_ulp() to push updates to TLS ULP on top. However, we don't push the write_space callback up and instead simply overwrite the op with the psock stored previous op. This may or may not be correct so to ensure we don't overwrite the TLS write space hook pass this field to the ULP and have it fixup the ctx. This completes a previous fix that pushed the ops through to the ULP but at the time missed doing this for write_space, presumably because write_space TLS hook was added around the same time. Fixes: 95fa145479fbc ("bpf: sockmap/tls, close can race with map free") Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Sitnicki Acked-by: Jonathan Lemon Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20200111061206.8028-4-john.fastabend@gmail.com + Changed Files: include/linux/skmsg.h | 12 ++++++++----; include/net/tcp.h | 6 ++++--; net/ipv4/tcp_ulp.c | 6 ++++--; net/tls/tls_main.c | 10 +++++++---; 4 files changed, 23 insertions(+), 11 deletions(-) + Parent Hashes: 7e81a35302066c5a00b4c72d83e3ea4cad6eeb5b +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit ensures proper handling of the write_space callback during sockmap sock removal when TLS is enabled by updating the ULP context.", + "keywords": "write_space, sockmap, TLS", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +Rethinking... +new content: +{ + "summary": "The commit ensures proper handling of the write_space callback during sockmap sock removal when TLS is enabled by updating the ULP context.", + "keywords": "write_space, sockmap, TLS", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +-------------------- +-------------------- +Processing Commit 690/6895 - Commit ID: 7e81a35302066c5a00b4c72d83e3ea4cad6eeb5b +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 7e81a35302066c5a00b4c72d83e3ea4cad6eeb5b + Author Name: John Fastabend + Author Email: john.fastabend@gmail.com + Commit Date: 1579127173 + Commit Message: + bpf: Sockmap, ensure sock lock held during tear down The sock_map_free() and sock_hash_free() paths used to delete sockmap and sockhash maps walk the maps and destroy psock and bpf state associated with the socks in the map. When done the socks no longer have BPF programs attached and will function normally. This can happen while the socks in the map are still "live" meaning data may be sent/received during the walk. Currently, though we don't take the sock_lock when the psock and bpf state is removed through this path. Specifically, this means we can be writing into the ops structure pointers such as sendmsg, sendpage, recvmsg, etc. while they are also being called from the networking side. This is not safe, we never used proper READ_ONCE/WRITE_ONCE semantics here if we believed it was safe. Further its not clear to me its even a good idea to try and do this on "live" sockets while networking side might also be using the socket. Instead of trying to reason about using the socks from both sides lets realize that every use case I'm aware of rarely deletes maps, in fact kubernetes/Cilium case builds map at init and never tears it down except on errors. So lets do the simple fix and grab sock lock. This patch wraps sock deletes from maps in sock lock and adds some annotations so we catch any other cases easier. Fixes: 604326b41a6fb ("bpf, sockmap: convert to generic sk_msg interface") Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Acked-by: Song Liu Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20200111061206.8028-3-john.fastabend@gmail.com + Changed Files: net/core/skmsg.c | 2 ++; net/core/sock_map.c | 7 ++++++-; 2 files changed, 8 insertions(+), 1 deletion(-) + Parent Hashes: 4da6a196f93b1af7612340e8c1ad8ce71e18f955 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds sock lock to ensure thread safety during sockmap teardown.", + "keywords": "sockmap, lock, teardown", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit ensures thread safety by adding a sock lock during sockmap teardown.", + "keywords": "sockmap, lock, teardown", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 691/6895 - Commit ID: 4da6a196f93b1af7612340e8c1ad8ce71e18f955 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 4da6a196f93b1af7612340e8c1ad8ce71e18f955 + Author Name: John Fastabend + Author Email: john.fastabend@gmail.com + Commit Date: 1579127173 + Commit Message: + bpf: Sockmap/tls, during free we may call tcp_bpf_unhash() in loop When a sockmap is free'd and a socket in the map is enabled with tls we tear down the bpf context on the socket, the psock struct and state, and then call tcp_update_ulp(). The tcp_update_ulp() call is to inform the tls stack it needs to update its saved sock ops so that when the tls socket is later destroyed it doesn't try to call the now destroyed psock hooks. This is about keeping stacked ULPs in good shape so they always have the right set of stacked ops. However, recently unhash() hook was removed from TLS side. But, the sockmap/bpf side is not doing any extra work to update the unhash op when is torn down instead expecting TLS side to manage it. So both TLS and sockmap believe the other side is managing the op and instead no one updates the hook so it continues to point at tcp_bpf_unhash(). When unhash hook is called we call tcp_bpf_unhash() which detects the psock has already been destroyed and calls sk->sk_prot_unhash() which calls tcp_bpf_unhash() yet again and so on looping and hanging the core. To fix have sockmap tear down logic fixup the stale pointer. Fixes: 5d92e631b8be ("net/tls: partially revert fix transition through disconnect with close") Reported-by: syzbot+83979935eb6304f8cd46@syzkaller.appspotmail.com Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Sitnicki Acked-by: Song Liu Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20200111061206.8028-2-john.fastabend@gmail.com + Changed Files: include/linux/skmsg.h | 1 +; 1 file changed, 1 insertion(+) + Parent Hashes: 0af2ffc93a4b50948f9dad2786b7f1bd253bf0b9 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes a looping issue involving unloading unhash hooks in sockmap/tls when freeing sockets.", + "keywords": "sockmap,tls,unhash", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes a looping issue in sockmap with TLS by correcting unhash hook management.", + "keywords": "sockmap,TLS,unhash", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 692/6895 - Commit ID: 990bca1fc8ad48f7f8b0786b739a9408017b7a74 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 990bca1fc8ad48f7f8b0786b739a9408017b7a74 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1579126067 + Commit Message: + Merge branch 'bpf-batch-ops' Brian Vazquez says: ==================== This patch series introduce batch ops that can be added to bpf maps to lookup/lookup_and_delete/update/delete more than 1 element at the time, this is specially useful when syscall overhead is a problem and in case of hmap it will provide a reliable way of traversing them. The implementation inclues a generic approach that could potentially be used by any bpf map and adds it to arraymap, it also includes the specific implementation of hashmaps which are traversed using buckets instead of keys. The bpf syscall subcommands introduced are: BPF_MAP_LOOKUP_BATCH BPF_MAP_LOOKUP_AND_DELETE_BATCH BPF_MAP_UPDATE_BATCH BPF_MAP_DELETE_BATCH The UAPI attribute is: struct { /* struct used by BPF_MAP_*_BATCH commands */ __aligned_u64 in_batch; /* start batch, * NULL to start from beginning */ __aligned_u64 out_batch; /* output: next start batch */ __aligned_u64 keys; __aligned_u64 values; __u32 count; /* input/output: * input: # of key/value * elements * output: # of filled elements */ __u32 map_fd; __u64 elem_flags; __u64 flags; } batch; in_batch and out_batch are only used for lookup and lookup_and_delete since those are the only two operations that attempt to traverse the map. update/delete batch ops should provide the keys/values that user wants to modify. Here are the previous discussions on the batch processing: - https://lore.kernel.org/bpf/20190724165803.87470-1-brianvv@google.com/ - https://lore.kernel.org/bpf/20190829064502.2750303-1-yhs@fb.com/ - https://lore.kernel.org/bpf/20190906225434.3635421-1-yhs@fb.com/ Changelog sinve v4: - Remove unnecessary checks from libbpf API (Andrii Nakryiko) - Move DECLARE_LIBBPF_OPTS with all var declarations (Andrii Nakryiko) - Change bucket internal buffer size to 5 entries (Yonghong Song) - Fix some minor bugs in hashtab batch ops implementation (Yonghong Song) Changelog sinve v3: - Do not use copy_to_user inside atomic region (Yonghong Song) - Use _opts approach on libbpf APIs (Andrii Nakryiko) - Drop generic_map_lookup_and_delete_batch support - Free malloc-ed memory in tests (Yonghong Song) - Reverse christmas tree (Yonghong Song) - Add acked labels Changelog sinve v2: - Add generic batch support for lpm_trie and test it (Yonghong Song) - Use define MAP_LOOKUP_RETRIES for retries (John Fastabend) - Return errors directly and remove labels (Yonghong Song) - Insert new API functions into libbpf alphabetically (Yonghong Song) - Change hlist_nulls_for_each_entry_rcu to hlist_nulls_for_each_entry_safe in htab batch ops (Yonghong Song) Changelog since v1: - Fix SOB ordering and remove Co-authored-by tag (Alexei Starovoitov) Changelog since RFC: - Change batch to in_batch and out_batch to support more flexible opaque values to iterate the bpf maps. - Remove update/delete specific batch ops for htab and use the generic implementations instead. ==================== Acked-by: Yonghong Song Signed-off-by: Alexei Starovoitov + Changed Files: nan + Parent Hashes: 83e4b88be1ff9671f2a2fb040a09c45cc3fb40e6 f0fac2cec2861abc6fc0c094fb2584d9a33f868d +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit introduces batch operations for bpf maps to improve performance by reducing syscall overhead.", + "keywords": "batch, bpf, maps", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges batch operations for BPF maps to reduce syscall overhead and improve traversal efficiency.", + "keywords": "batch,bpf,maps", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 693/6895 - Commit ID: f0fac2cec2861abc6fc0c094fb2584d9a33f868d +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: f0fac2cec2861abc6fc0c094fb2584d9a33f868d + Author Name: Brian Vazquez + Author Email: brianvv@google.com + Commit Date: 1579125635 + Commit Message: + selftests/bpf: Add batch ops testing to array bpf map Tested bpf_map_lookup_batch() and bpf_map_update_batch() functionality. $ ./test_maps ... test_array_map_batch_ops:PASS ... Signed-off-by: Brian Vazquez Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200115184308.162644-10-brianvv@google.com + Changed Files: .../selftests/bpf/map_tests/array_map_batch_ops.c | 129 +++++++++++++++++++++; 1 file changed, 129 insertions(+) + Parent Hashes: 30ff3c59137d00e083f68437665e00895cc271c7 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds batch operation tests for array BPF maps in the selftests directory.", + "keywords": "selftests,batch,testing", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds batch operation tests for array BPF maps in the selftests directory.", + "keywords": "selftests,batch,testing", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 694/6895 - Commit ID: 30ff3c59137d00e083f68437665e00895cc271c7 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 30ff3c59137d00e083f68437665e00895cc271c7 + Author Name: Yonghong Song + Author Email: yhs@fb.com + Commit Date: 1579125635 + Commit Message: + selftests/bpf: Add batch ops testing for htab and htab_percpu map Tested bpf_map_lookup_batch(), bpf_map_lookup_and_delete_batch(), bpf_map_update_batch(), and bpf_map_delete_batch() functionality. $ ./test_maps ... test_htab_map_batch_ops:PASS test_htab_percpu_map_batch_ops:PASS ... Signed-off-by: Yonghong Song Signed-off-by: Brian Vazquez Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200115184308.162644-9-brianvv@google.com + Changed Files: .../selftests/bpf/map_tests/htab_map_batch_ops.c | 283 +++++++++++++++++++++; 1 file changed, 283 insertions(+) + Parent Hashes: 2ab3d86ea1859d1a4b830ce3551cba725620593a +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds batch operation tests for htab and htab_percpu maps in bpf selftests.", + "keywords": "batch, htab, map", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit introduces tests for batch operations on htab and htab_percpu maps in eBPF selftests.", + "keywords": "batch, htab, testing", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 695/6895 - Commit ID: 2ab3d86ea1859d1a4b830ce3551cba725620593a +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 2ab3d86ea1859d1a4b830ce3551cba725620593a + Author Name: Yonghong Song + Author Email: yhs@fb.com + Commit Date: 1579125635 + Commit Message: + libbpf: Add libbpf support to batch ops Added four libbpf API functions to support map batch operations: . int bpf_map_delete_batch( ... ) . int bpf_map_lookup_batch( ... ) . int bpf_map_lookup_and_delete_batch( ... ) . int bpf_map_update_batch( ... ) Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200115184308.162644-8-brianvv@google.com + Changed Files: tools/lib/bpf/bpf.c | 58 ++++++++++++++++++++++++++++++++++++++++++++++++; tools/lib/bpf/bpf.h | 22 ++++++++++++++++++; tools/lib/bpf/libbpf.map | 4 ++++; 3 files changed, 84 insertions(+) + Parent Hashes: a1e3a3b8ba2c381a043d0c4273837895c1d3cf9c +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds batch operation support to libbpf with new API functions for map operations.", + "keywords": "libbpf,batch,operations", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds batch operation API support to libbpf for map operations.", + "keywords": "libbpf,batch,maps", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 696/6895 - Commit ID: a1e3a3b8ba2c381a043d0c4273837895c1d3cf9c +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: a1e3a3b8ba2c381a043d0c4273837895c1d3cf9c + Author Name: Yonghong Song + Author Email: yhs@fb.com + Commit Date: 1579125635 + Commit Message: + tools/bpf: Sync uapi header bpf.h sync uapi header include/uapi/linux/bpf.h to tools/include/uapi/linux/bpf.h Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200115184308.162644-7-brianvv@google.com + Changed Files: tools/include/uapi/linux/bpf.h | 21 +++++++++++++++++++++; 1 file changed, 21 insertions(+) + Parent Hashes: 057996380a42bb64ccc04383cfa9c0ace4ea11f0 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Synchronize uapi header bpf.h between source directories in the Linux tools.", + "keywords": "sync,uapi,header", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Synchronize the bpf.h uapi header between kernel and tools directory for consistency.", + "keywords": "sync,uapi,header", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 697/6895 - Commit ID: 057996380a42bb64ccc04383cfa9c0ace4ea11f0 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 057996380a42bb64ccc04383cfa9c0ace4ea11f0 + Author Name: Yonghong Song + Author Email: yhs@fb.com + Commit Date: 1579125635 + Commit Message: + bpf: Add batch ops to all htab bpf map htab can't use generic batch support due some problematic behaviours inherent to the data structre, i.e. while iterating the bpf map a concurrent program might delete the next entry that batch was about to use, in that case there's no easy solution to retrieve the next entry, the issue has been discussed multiple times (see [1] and [2]). The only way hmap can be traversed without the problem previously exposed is by making sure that the map is traversing entire buckets. This commit implements those strict requirements for hmap, the implementation follows the same interaction that generic support with some exceptions: - If keys/values buffer are not big enough to traverse a bucket, ENOSPC will be returned. - out_batch contains the value of the next bucket in the iteration, not the next key, but this is transparent for the user since the user should never use out_batch for other than bpf batch syscalls. This commits implements BPF_MAP_LOOKUP_BATCH and adds support for new command BPF_MAP_LOOKUP_AND_DELETE_BATCH. Note that for update/delete batch ops it is possible to use the generic implementations. [1] https://lore.kernel.org/bpf/20190724165803.87470-1-brianvv@google.com/ [2] https://lore.kernel.org/bpf/20190906225434.3635421-1-yhs@fb.com/ Signed-off-by: Yonghong Song Signed-off-by: Brian Vazquez Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200115184308.162644-6-brianvv@google.com + Changed Files: include/linux/bpf.h | 3 +; include/uapi/linux/bpf.h | 1 +; kernel/bpf/hashtab.c | 264 +++++++++++++++++++++++++++++++++++++++++++++++; kernel/bpf/syscall.c | 9 +-; 4 files changed, 276 insertions(+), 1 deletion(-) + Parent Hashes: c60f2d2861778de6370a4f4ca6ab1d7d4a32efae +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds batch operations to htab bpf map for improved iteration handling across buckets.", + "keywords": "bpf,map,batch", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit introduces batch lookup and delete operations for htab BPF maps to manage concurrent entry iteration.", + "keywords": "batch,lookup,htab", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 698/6895 - Commit ID: c60f2d2861778de6370a4f4ca6ab1d7d4a32efae +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: c60f2d2861778de6370a4f4ca6ab1d7d4a32efae + Author Name: Brian Vazquez + Author Email: brianvv@google.com + Commit Date: 1579125635 + Commit Message: + bpf: Add lookup and update batch ops to arraymap This adds the generic batch ops functionality to bpf arraymap, note that since deletion is not a valid operation for arraymap, only batch and lookup are added. Signed-off-by: Brian Vazquez Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200115184308.162644-5-brianvv@google.com + Changed Files: kernel/bpf/arraymap.c | 2 ++; 1 file changed, 2 insertions(+) + Parent Hashes: aa2e93b8e58e18442edfb2427446732415bc215e +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds batch lookup and update operations to the bpf arraymap, excluding deletion.", + "keywords": "batch, arraymap, operations", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit introduces batch lookup and update functionality to bpf arraymaps, excluding deletion operations.", + "keywords": "batch,arraymap,operations", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 699/6895 - Commit ID: aa2e93b8e58e18442edfb2427446732415bc215e +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: aa2e93b8e58e18442edfb2427446732415bc215e + Author Name: Brian Vazquez + Author Email: brianvv@google.com + Commit Date: 1579125635 + Commit Message: + bpf: Add generic support for update and delete batch ops This commit adds generic support for update and delete batch ops that can be used for almost all the bpf maps. These commands share the same UAPI attr that lookup and lookup_and_delete batch ops use and the syscall commands are: BPF_MAP_UPDATE_BATCH BPF_MAP_DELETE_BATCH The main difference between update/delete and lookup batch ops is that for update/delete keys/values must be specified for userspace and because of that, neither in_batch nor out_batch are used. Suggested-by: Stanislav Fomichev Signed-off-by: Brian Vazquez Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200115184308.162644-4-brianvv@google.com + Changed Files: include/linux/bpf.h | 10 +++++; include/uapi/linux/bpf.h | 2 +; kernel/bpf/syscall.c | 115 +++++++++++++++++++++++++++++++++++++++++++++++; 3 files changed, 127 insertions(+) + Parent Hashes: cb4d03ab499d4c040f4ab6fd4389d2b49f42b5a5 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit introduces generic support for batch update and delete operations for almost all BPF maps.", + "keywords": "batch,update,delete", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit introduces generic support for batch update and delete operations for almost all BPF maps.", + "keywords": "batch,update,delete", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 700/6895 - Commit ID: cb4d03ab499d4c040f4ab6fd4389d2b49f42b5a5 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: cb4d03ab499d4c040f4ab6fd4389d2b49f42b5a5 + Author Name: Brian Vazquez + Author Email: brianvv@google.com + Commit Date: 1579125635 + Commit Message: + bpf: Add generic support for lookup batch op This commit introduces generic support for the bpf_map_lookup_batch. This implementation can be used by almost all the bpf maps since its core implementation is relying on the existing map_get_next_key and map_lookup_elem. The bpf syscall subcommand introduced is: BPF_MAP_LOOKUP_BATCH The UAPI attribute is: struct { /* struct used by BPF_MAP_*_BATCH commands */ __aligned_u64 in_batch; /* start batch, * NULL to start from beginning */ __aligned_u64 out_batch; /* output: next start batch */ __aligned_u64 keys; __aligned_u64 values; __u32 count; /* input/output: * input: # of key/value * elements * output: # of filled elements */ __u32 map_fd; __u64 elem_flags; __u64 flags; } batch; in_batch/out_batch are opaque values use to communicate between user/kernel space, in_batch/out_batch must be of key_size length. To start iterating from the beginning in_batch must be null, count is the # of key/value elements to retrieve. Note that the 'keys' buffer must be a buffer of key_size * count size and the 'values' buffer must be value_size * count, where value_size must be aligned to 8 bytes by userspace if it's dealing with percpu maps. 'count' will contain the number of keys/values successfully retrieved. Note that 'count' is an input/output variable and it can contain a lower value after a call. If there's no more entries to retrieve, ENOENT will be returned. If error is ENOENT, count might be > 0 in case it copied some values but there were no more entries to retrieve. Note that if the return code is an error and not -EFAULT, count indicates the number of elements successfully processed. Suggested-by: Stanislav Fomichev Signed-off-by: Brian Vazquez Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200115184308.162644-3-brianvv@google.com + Changed Files: include/linux/bpf.h | 5 ++; include/uapi/linux/bpf.h | 18 ++++++; kernel/bpf/syscall.c | 160 +++++++++++++++++++++++++++++++++++++++++++++--; 3 files changed, 179 insertions(+), 4 deletions(-) + Parent Hashes: 15c14a3dca421f086c187155afba3222b879472d +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds generic support for the bpf_map_lookup_batch operation in eBPF, enabling batch retrieval of map elements.", + "keywords": "bpf,lookup,batch", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The syscall interface. It changes the system calls through which user-space programs interact with eBPF.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds generic support for batch processing in eBPF maps, introducing the bpf_map_lookup_batch operation.", + "keywords": "bpf,map,batch", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The syscall interface. It changes the system calls through which user-space programs interact with eBPF.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 701/6895 - Commit ID: 15c14a3dca421f086c187155afba3222b879472d +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 15c14a3dca421f086c187155afba3222b879472d + Author Name: Brian Vazquez + Author Email: brianvv@google.com + Commit Date: 1579125634 + Commit Message: + bpf: Add bpf_map_{value_size, update_value, map_copy_value} functions This commit moves reusable code from map_lookup_elem and map_update_elem to avoid code duplication in kernel/bpf/syscall.c. Signed-off-by: Brian Vazquez Signed-off-by: Alexei Starovoitov Acked-by: John Fastabend Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200115184308.162644-2-brianvv@google.com + Changed Files: kernel/bpf/syscall.c | 280 ++++++++++++++++++++++++++++-----------------------; 1 file changed, 152 insertions(+), 128 deletions(-) + Parent Hashes: 83e4b88be1ff9671f2a2fb040a09c45cc3fb40e6 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit refactors code in kernel/bpf/syscall.c by extracting reusable functions to reduce duplication in bpf map operations.", + "keywords": "refactor, bpf_map, syscall", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The syscall interface. It changes the system calls through which user-space programs interact with eBPF.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit refactors code in kernel/bpf/syscall.c by extracting reusable functions to reduce duplication in bpf map operations.", + "keywords": "refactor, bpf_map, syscall", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The syscall interface. It changes the system calls through which user-space programs interact with eBPF.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 702/6895 - Commit ID: 0af2ffc93a4b50948f9dad2786b7f1bd253bf0b9 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 0af2ffc93a4b50948f9dad2786b7f1bd253bf0b9 + Author Name: Daniel Borkmann + Author Email: daniel@iogearbox.net + Commit Date: 1579124399 + Commit Message: + bpf: Fix incorrect verifier simulation of ARSH under ALU32 Anatoly has been fuzzing with kBdysch harness and reported a hang in one of the outcomes: 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 0: (85) call bpf_get_socket_cookie#46 1: R0_w=invP(id=0) R10=fp0 1: (57) r0 &= 808464432 2: R0_w=invP(id=0,umax_value=808464432,var_off=(0x0; 0x30303030)) R10=fp0 2: (14) w0 -= 810299440 3: R0_w=invP(id=0,umax_value=4294967295,var_off=(0xcf800000; 0x3077fff0)) R10=fp0 3: (c4) w0 s>>= 1 4: R0_w=invP(id=0,umin_value=1740636160,umax_value=2147221496,var_off=(0x67c00000; 0x183bfff8)) R10=fp0 4: (76) if w0 s>= 0x30303030 goto pc+216 221: R0_w=invP(id=0,umin_value=1740636160,umax_value=2147221496,var_off=(0x67c00000; 0x183bfff8)) R10=fp0 221: (95) exit processed 6 insns (limit 1000000) [...] Taking a closer look, the program was xlated as follows: # ./bpftool p d x i 12 0: (85) call bpf_get_socket_cookie#7800896 1: (bf) r6 = r0 2: (57) r6 &= 808464432 3: (14) w6 -= 810299440 4: (c4) w6 s>>= 1 5: (76) if w6 s>= 0x30303030 goto pc+216 6: (05) goto pc-1 7: (05) goto pc-1 8: (05) goto pc-1 [...] 220: (05) goto pc-1 221: (05) goto pc-1 222: (95) exit Meaning, the visible effect is very similar to f54c7898ed1c ("bpf: Fix precision tracking for unbounded scalars"), that is, the fall-through branch in the instruction 5 is considered to be never taken given the conclusion from the min/max bounds tracking in w6, and therefore the dead-code sanitation rewrites it as goto pc-1. However, real-life input disagrees with verification analysis since a soft-lockup was observed. The bug sits in the analysis of the ARSH. The definition is that we shift the target register value right by K bits through shifting in copies of its sign bit. In adjust_scalar_min_max_vals(), we do first coerce the register into 32 bit mode, same happens after simulating the operation. However, for the case of simulating the actual ARSH, we don't take the mode into account and act as if it's always 64 bit, but location of sign bit is different: dst_reg->smin_value >>= umin_val; dst_reg->smax_value >>= umin_val; dst_reg->var_off = tnum_arshift(dst_reg->var_off, umin_val); Consider an unknown R0 where bpf_get_socket_cookie() (or others) would for example return 0xffff. With the above ARSH simulation, we'd see the following results: [...] 1: R1=ctx(id=0,off=0,imm=0) R2_w=invP65535 R10=fp0 1: (85) call bpf_get_socket_cookie#46 2: R0_w=invP(id=0) R10=fp0 2: (57) r0 &= 808464432 -> R0_runtime = 0x3030 3: R0_w=invP(id=0,umax_value=808464432,var_off=(0x0; 0x30303030)) R10=fp0 3: (14) w0 -= 810299440 -> R0_runtime = 0xcfb40000 4: R0_w=invP(id=0,umax_value=4294967295,var_off=(0xcf800000; 0x3077fff0)) R10=fp0 (0xffffffff) 4: (c4) w0 s>>= 1 -> R0_runtime = 0xe7da0000 5: R0_w=invP(id=0,umin_value=1740636160,umax_value=2147221496,var_off=(0x67c00000; 0x183bfff8)) R10=fp0 (0x67c00000) (0x7ffbfff8) [...] In insn 3, we have a runtime value of 0xcfb40000, which is '1100 1111 1011 0100 0000 0000 0000 0000', the result after the shift has 0xe7da0000 that is '1110 0111 1101 1010 0000 0000 0000 0000', where the sign bit is correctly retained in 32 bit mode. In insn4, the umax was 0xffffffff, and changed into 0x7ffbfff8 after the shift, that is, '0111 1111 1111 1011 1111 1111 1111 1000' and means here that the simulation didn't retain the sign bit. With above logic, the updates happen on the 64 bit min/max bounds and given we coerced the register, the sign bits of the bounds are cleared as well, meaning, we need to force the simulation into s32 space for 32 bit alu mode. Verification after the fix below. We're first analyzing the fall-through branch on 32 bit signed >= test eventually leading to rejection of the program in this specific case: 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 0: (b7) r2 = 808464432 1: R1=ctx(id=0,off=0,imm=0) R2_w=invP808464432 R10=fp0 1: (85) call bpf_get_socket_cookie#46 2: R0_w=invP(id=0) R10=fp0 2: (bf) r6 = r0 3: R0_w=invP(id=0) R6_w=invP(id=0) R10=fp0 3: (57) r6 &= 808464432 4: R0_w=invP(id=0) R6_w=invP(id=0,umax_value=808464432,var_off=(0x0; 0x30303030)) R10=fp0 4: (14) w6 -= 810299440 5: R0_w=invP(id=0) R6_w=invP(id=0,umax_value=4294967295,var_off=(0xcf800000; 0x3077fff0)) R10=fp0 5: (c4) w6 s>>= 1 6: R0_w=invP(id=0) R6_w=invP(id=0,umin_value=3888119808,umax_value=4294705144,var_off=(0xe7c00000; 0x183bfff8)) R10=fp0 (0x67c00000) (0xfffbfff8) 6: (76) if w6 s>= 0x30303030 goto pc+216 7: R0_w=invP(id=0) R6_w=invP(id=0,umin_value=3888119808,umax_value=4294705144,var_off=(0xe7c00000; 0x183bfff8)) R10=fp0 7: (30) r0 = *(u8 *)skb[808464432] BPF_LD_[ABS|IND] uses reserved fields processed 8 insns (limit 1000000) [...] Fixes: 9cbe1f5a32dc ("bpf/verifier: improve register value range tracking with ARSH") Reported-by: Anatoly Trosinenko Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200115204733.16648-1-daniel@iogearbox.net + Changed Files: include/linux/tnum.h | 2 +-; kernel/bpf/tnum.c | 9 +++++++--; kernel/bpf/verifier.c | 13 ++++++++++---; 3 files changed, 18 insertions(+), 6 deletions(-) + Parent Hashes: 555089fdfc37ad65e0ee9b42ca40c238ff546f83 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes a verifier bug with ARSH simulation under ALU32, addressing incorrect sign bit retention in 32-bit mode.", + "keywords": "verifier,ARSH,bug", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes a verifier bug with ARSH simulation under ALU32 by correcting sign bit handling in 32-bit mode.", + "keywords": "verifier,ARSH,bug", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 703/6895 - Commit ID: 83e4b88be1ff9671f2a2fb040a09c45cc3fb40e6 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 83e4b88be1ff9671f2a2fb040a09c45cc3fb40e6 + Author Name: Eelco Chaudron + Author Email: echaudro@redhat.com + Commit Date: 1579123345 + Commit Message: + selftests/bpf: Add a test for attaching a bpf fentry/fexit trace to an XDP program Add a test that will attach a FENTRY and FEXIT program to the XDP test program. It will also verify data from the XDP context on FENTRY and verifies the return code on exit. Signed-off-by: Eelco Chaudron Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/157909410480.47481.11202505690938004673.stgit@xdp-tutorial + Changed Files: .../testing/selftests/bpf/prog_tests/xdp_bpf2bpf.c | 65 ++++++++++++++++++++++; .../testing/selftests/bpf/progs/test_xdp_bpf2bpf.c | 44 +++++++++++++++; 2 files changed, 109 insertions(+) + Parent Hashes: 9173cac3b64e6785dd604f5075e6035b045a0026 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Add a selftest for attaching eBPF fentry/fexit trace programs to an XDP program and verifying functionality.", + "keywords": "selftests,XDP,fentry", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Add a selftest for attaching eBPF fentry/fexit trace programs to an XDP program and verifying functionality and return behavior.", + "keywords": "selftests,XDP,fentry", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 704/6895 - Commit ID: 9173cac3b64e6785dd604f5075e6035b045a0026 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 9173cac3b64e6785dd604f5075e6035b045a0026 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1579117908 + Commit Message: + libbpf: Support .text sub-calls relocations The LLVM patch https://reviews.llvm.org/D72197 makes LLVM emit function call relocations within the same section. This includes a default .text section, which contains any BPF sub-programs. This wasn't the case before and so libbpf was able to get a way with slightly simpler handling of subprogram call relocations. This patch adds support for .text section relocations. It needs to ensure correct order of relocations, so does two passes: - first, relocate .text instructions, if there are any relocations in it; - then process all the other programs and copy over patched .text instructions for all sub-program calls. v1->v2: - break early once .text program is processed. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Cc: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200115190856.2391325-1-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.c | 29 ++++++++++++++++++++++-------; 1 file changed, 22 insertions(+), 7 deletions(-) + Parent Hashes: 5640a771d7971412049d1934d2d030edfdd1c28e +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds support for .text section relocations in libbpf due to new LLVM requirements.", + "keywords": "libbpf relocations LLVM", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit enhances libbpf to support internal function call relocations within .text sections due to an LLVM update.", + "keywords": "libbpf, relocations, LLVM", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 705/6895 - Commit ID: 5640a771d7971412049d1934d2d030edfdd1c28e +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 5640a771d7971412049d1934d2d030edfdd1c28e + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1579117592 + Commit Message: + Merge branch 'bpf_send_signal_thread' Yonghong Song says: ==================== Commit 8b401f9ed244 ("bpf: implement bpf_send_signal() helper") added helper bpf_send_signal() which permits bpf program to send a signal to the current process. The signal may send to any thread of the process. This patch implemented a new helper bpf_send_signal_thread() to send a signal to the thread corresponding to the kernel current task. This helper can simplify user space code if the thread context of bpf sending signal is needed in user space. Please see Patch #1 for details of use case and kernel implementation. Patch #2 added some bpf self tests for the new helper. Changelogs: v2 -> v3: - More simplification for skeleton codes by removing not-needed mmap code and redundantly created tracepoint link. v1 -> v2: - More description for the difference between bpf_send_signal() and bpf_send_signal_thread() in the uapi header bpf.h. - Use skeleton and mmap for send_signal test. ==================== Acked-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov + Changed Files: nan + Parent Hashes: d3a56931f9c8644a52e7a6735954c84ea895e8c3 ab8b7f0cb3585ecb40e3305850f28658a1b8940e +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges a branch adding the bpf_send_signal_thread() helper to simplify sending signals in specific thread contexts.", + "keywords": "bpf,signal,helper", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges a branch adding a new helper function for sending signals to specific thread contexts in eBPF programs.", + "keywords": "merge,signal,helper", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 706/6895 - Commit ID: ab8b7f0cb3585ecb40e3305850f28658a1b8940e +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: ab8b7f0cb3585ecb40e3305850f28658a1b8940e + Author Name: Yonghong Song + Author Email: yhs@fb.com + Commit Date: 1579117491 + Commit Message: + tools/bpf: Add self tests for bpf_send_signal_thread() The test_progs send_signal() is amended to test bpf_send_signal_thread() as well. $ ./test_progs -n 40 #40/1 send_signal_tracepoint:OK #40/2 send_signal_perf:OK #40/3 send_signal_nmi:OK #40/4 send_signal_tracepoint_thread:OK #40/5 send_signal_perf_thread:OK #40/6 send_signal_nmi_thread:OK #40 send_signal:OK Summary: 1/6 PASSED, 0 SKIPPED, 0 FAILED Also took this opportunity to rewrite the send_signal test using skeleton framework and array mmap to make code simpler and more readable. Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200115035003.602425-1-yhs@fb.com + Changed Files: .../testing/selftests/bpf/prog_tests/send_signal.c | 128 ++++++++-------------; .../selftests/bpf/progs/test_send_signal_kern.c | 51 ++++----; 2 files changed, 73 insertions(+), 106 deletions(-) + Parent Hashes: 8482941f09067da42f9c3362e15bfb3f3c19d610 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds self-tests for bpf_send_signal_thread() and refactors the send_signal test using the skeleton framework.", + "keywords": "self-tests send_signal_thread refactor", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds self-tests for bpf_send_signal_thread() and refactors send_signal test with a simpler framework.", + "keywords": "self-tests bpf_send_signal_thread refactor", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 707/6895 - Commit ID: 8482941f09067da42f9c3362e15bfb3f3c19d610 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 8482941f09067da42f9c3362e15bfb3f3c19d610 + Author Name: Yonghong Song + Author Email: yhs@fb.com + Commit Date: 1579117491 + Commit Message: + bpf: Add bpf_send_signal_thread() helper Commit 8b401f9ed244 ("bpf: implement bpf_send_signal() helper") added helper bpf_send_signal() which permits bpf program to send a signal to the current process. The signal may be delivered to any threads in the process. We found a use case where sending the signal to the current thread is more preferable. - A bpf program will collect the stack trace and then send signal to the user application. - The user application will add some thread specific information to the just collected stack trace for later analysis. If bpf_send_signal() is used, user application will need to check whether the thread receiving the signal matches the thread collecting the stack by checking thread id. If not, it will need to send signal to another thread through pthread_kill(). This patch proposed a new helper bpf_send_signal_thread(), which sends the signal to the thread corresponding to the current kernel task. This way, user space is guaranteed that bpf_program execution context and user space signal handling context are the same thread. Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200115035002.602336-1-yhs@fb.com + Changed Files: include/uapi/linux/bpf.h | 19 +++++++++++++++++--; kernel/trace/bpf_trace.c | 27 ++++++++++++++++++++++++---; tools/include/uapi/linux/bpf.h | 19 +++++++++++++++++--; 3 files changed, 58 insertions(+), 7 deletions(-) + Parent Hashes: d3a56931f9c8644a52e7a6735954c84ea895e8c3 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds the bpf_send_signal_thread() helper to send signals to specific threads within a process, facilitating thread-specific stack trace analysis.", + "keywords": "bpf,signal,helper", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here." + ] +} +Rethinking... +new content: +{ + "summary": "This commit introduces the bpf_send_signal_thread() helper for sending signals to the current thread for better stack trace analysis.", + "keywords": "bpf,signal,helper", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here." + ] +} +-------------------- +-------------------- +Processing Commit 708/6895 - Commit ID: d3a56931f9c8644a52e7a6735954c84ea895e8c3 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: d3a56931f9c8644a52e7a6735954c84ea895e8c3 + Author Name: Magnus Karlsson + Author Email: magnus.karlsson@intel.com + Commit Date: 1579117312 + Commit Message: + xsk: Support allocations of large umems When registering a umem area that is sufficiently large (>1G on an x86), kmalloc cannot be used to allocate one of the internal data structures, as the size requested gets too large. Use kvmalloc instead that falls back on vmalloc if the allocation is too large for kmalloc. Also add accounting for this structure as it is triggered by a user space action (the XDP_UMEM_REG setsockopt) and it is by far the largest structure of kernel allocated memory in xsk. Reported-by: Ryan Goodfellow Signed-off-by: Magnus Karlsson Signed-off-by: Alexei Starovoitov Acked-by: Jonathan Lemon Link: https://lore.kernel.org/bpf/1578995365-7050-1-git-send-email-magnus.karlsson@intel.com + Changed Files: net/xdp/xdp_umem.c | 7 ++++---; 1 file changed, 4 insertions(+), 3 deletions(-) + Parent Hashes: 0a29275b6300f39f78a87f2038bbfe5bdbaeca47 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit updates xsk to use kvmalloc for allocating large umems exceeding 1G on x86 architectures.", + "keywords": "xsk kvmalloc umem", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit modifies xsk to use kvmalloc for large umem allocations exceeding 1G, enhancing memory handling.", + "keywords": "xsk kvmalloc umem", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 709/6895 - Commit ID: 0a29275b6300f39f78a87f2038bbfe5bdbaeca47 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 0a29275b6300f39f78a87f2038bbfe5bdbaeca47 + Author Name: Li RongQing + Author Email: lirongqing@baidu.com + Commit Date: 1579030344 + Commit Message: + bpf: Return -EBADRQC for invalid map type in __bpf_tx_xdp_map A negative value should be returned if map->map_type is invalid although that is impossible now, but if we run into such situation in future, then xdpbuff could be leaked. Daniel Borkmann suggested: -EBADRQC should be returned to stay consistent with generic XDP for the tracepoint output and not to be confused with -EOPNOTSUPP from other locations like dev_map_enqueue() when ndo_xdp_xmit is missing and such. Suggested-by: Daniel Borkmann Signed-off-by: Li RongQing Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/1578618277-18085-1-git-send-email-lirongqing@baidu.com + Changed Files: net/core/filter.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: 3b4130418f62b0e7a4685cc2c03bb41c6cb8922d +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit changes the return value for an invalid map type in __bpf_tx_xdp_map to prevent xdpbuff leaks.", + "keywords": "invalid map type, xdpbuff, consistency", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +Rethinking... +new content: +{ + "summary": "The commit ensures a consistent error return for invalid map types in __bpf_tx_xdp_map to prevent potential xdpbuff leaks.", + "keywords": "invalid map type, xdpbuff, error", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +-------------------- +-------------------- +Processing Commit 710/6895 - Commit ID: 3b4130418f62b0e7a4685cc2c03bb41c6cb8922d +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 3b4130418f62b0e7a4685cc2c03bb41c6cb8922d + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1579024471 + Commit Message: + bpf: Fix seq_show for BPF_MAP_TYPE_STRUCT_OPS Instead of using bpf_struct_ops_map_lookup_elem() which is not implemented, bpf_struct_ops_map_seq_show_elem() should also use bpf_struct_ops_map_sys_lookup_elem() which does an inplace update to the value. The change allocates a value to pass to bpf_struct_ops_map_sys_lookup_elem(). [root@arch-fb-vm1 bpf]# cat /sys/fs/bpf/dctcp {{{1}},BPF_STRUCT_OPS_STATE_INUSE,{{00000000df93eebc,00000000df93eebc},0,2, ... Fixes: 85d33df357b6 ("bpf: Introduce BPF_MAP_TYPE_STRUCT_OPS") Reported-by: Dan Carpenter Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200114072647.3188298-1-kafai@fb.com + Changed Files: kernel/bpf/bpf_struct_ops.c | 14 ++++++++++----; 1 file changed, 10 insertions(+), 4 deletions(-) + Parent Hashes: 6dd42aa17fdd59f383998c6c3e0ecc89414f4a04 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes seq_show for BPF_MAP_TYPE_STRUCT_OPS by using the correct lookup function and updating the value accordingly.", + "keywords": "seq_show, STRUCT_OPS, bpf", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes seq_show for BPF_MAP_TYPE_STRUCT_OPS by using the correct lookup function and updating the value appropriately.", + "keywords": "seq_show, STRUCT_OPS, lookup", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems." + ] +} +-------------------- +-------------------- +Processing Commit 711/6895 - Commit ID: 6dd42aa17fdd59f383998c6c3e0ecc89414f4a04 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 6dd42aa17fdd59f383998c6c3e0ecc89414f4a04 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1579022600 + Commit Message: + Merge branch 'runqslower' Andrii Nakryiko says: ==================== Based on recent BPF CO-RE, tp_btf, and BPF skeleton changes, re-implement BCC-based runqslower tool as a portable pre-compiled BPF CO-RE-based tool. Make sure it's built as part of selftests to ensure it doesn't bit rot. As part of this patch set, augment `format c` output of `bpftool btf dump` sub-command with applying `preserve_access_index` attribute to all structs and unions. This makes all such structs and unions automatically relocatable under BPF CO-RE, which improves user experience of writing TRACING programs with direct kernel memory read access. Also, further clean up selftest/bpf Makefile output and make it conforming to libbpf and bpftool succinct output format. v1->v2: - build in-tree bpftool for runqslower (Yonghong); - drop `format core` and augment `format c` instead (Alexei); - move runqslower under tools/bpf (Daniel). ==================== Signed-off-by: Alexei Starovoitov + Changed Files: nan + Parent Hashes: ac065870d92824ee0bc275ab71fd8901dbde5055 3a0d3092a4edbbcd62360c44a931c8feaf4b4ff1 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges changes to implement a portable CO-RE-based runqslower tool and updates bpftool to enhance BPF CO-RE usability.", + "keywords": "runqslower, CO-RE, bpftool", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges updates to make runqslower a portable CO-RE-based tool and improves bpftool for better BPF CO-RE usability.", + "keywords": "runqslower, CO-RE, bpftool", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 712/6895 - Commit ID: 3a0d3092a4edbbcd62360c44a931c8feaf4b4ff1 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 3a0d3092a4edbbcd62360c44a931c8feaf4b4ff1 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1579022592 + Commit Message: + selftests/bpf: Build runqslower from selftests Ensure runqslower tool is built as part of selftests to prevent it from bit rotting. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200113073143.1779940-7-andriin@fb.com + Changed Files: tools/bpf/runqslower/Makefile | 2 +-; tools/testing/selftests/bpf/Makefile | 7 ++++++-; 2 files changed, 7 insertions(+), 2 deletions(-) + Parent Hashes: 9c01546d26d28cf57341d8380ba900bf68e26b18 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit ensures the runqslower tool is built as part of BPF selftests to prevent neglect.", + "keywords": "selftests,runqslower,build", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit ensures the runqslower tool is included in BPF selftests to prevent it from being neglected.", + "keywords": "selftests,runqslower,build", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 713/6895 - Commit ID: 49e0b6f4e95aa3ade8f512c50d1ccc113fe917b4 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 49e0b6f4e95aa3ade8f512c50d1ccc113fe917b4 + Author Name: Cengiz Can + Author Email: cengiz@kernel.wtf + Commit Date: 1579016546 + Commit Message: + perf beauty sockaddr: Fix augmented syscall format warning The sockaddr related examples given in `tools/perf/examples/bpf/augmented_syscalls.c` almost always use `long`s to represent most of their fields. However, `size_t syscall_arg__scnprintf_sockaddr(..)` has a `scnprintf` call that uses `"%#x"` as format string. This throws a warning (whenever the syscall argument is `unsigned long`). Added `l` identifier to indicate that the `arg->value` is an unsigned long. Not sure about the complications of this with x86 though. Signed-off-by: Cengiz Can Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/20200113174438.102975-1-cengiz@kernel.wtf Signed-off-by: Arnaldo Carvalho de Melo + Changed Files: tools/perf/trace/beauty/sockaddr.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: 93e843f95f095aeb533ab67ac4718f848d38dfa0 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit fixes a format warning for augmented syscalls in perf trace beauty sockaddr by updating format specifier for unsigned long.", + "keywords": "format,warning,syscall", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here." + ] +} +Rethinking... +new content: +{ + "summary": "This commit fixes a format warning for augmented syscalls in perf trace beauty sockaddr by updating format specifier for unsigned long.", + "keywords": "format,warning,syscall", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here." + ] +} +-------------------- +-------------------- +Processing Commit 714/6895 - Commit ID: f042365dbffea98fb8148c98c700402e8d099f02 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: f042365dbffea98fb8148c98c700402e8d099f02 + Author Name: Nicolas Dichtel + Author Email: nicolas.dichtel@6wind.com + Commit Date: 1578988538 + Commit Message: + xfrm interface: fix packet tx through bpf_redirect() With an ebpf program that redirects packets through a xfrm interface, packets are dropped because no dst is attached to skb. This could also be reproduced with an AF_PACKET socket, with the following python script (xfrm1 is a xfrm interface): import socket send_s = socket.socket(socket.AF_PACKET, socket.SOCK_RAW, 0) # scapy # p = IP(src='10.100.0.2', dst='10.200.0.1')/ICMP(type='echo-request') # raw(p) req = b'E\x00\x00\x1c\x00\x01\x00\x00@\x01e\xb2\nd\x00\x02\n\xc8\x00\x01\x08\x00\xf7\xff\x00\x00\x00\x00' send_s.sendto(req, ('xfrm1', 0x800, 0, 0)) It was also not possible to send an ip packet through an AF_PACKET socket because a LL header was expected. Let's remove those LL header constraints. Signed-off-by: Nicolas Dichtel Signed-off-by: Steffen Klassert + Changed Files: net/xfrm/xfrm_interface.c | 32 +++++++++++++++++++++++++-------; 1 file changed, 25 insertions(+), 7 deletions(-) + Parent Hashes: 95224166a9032ff5d08fca633d37113078ce7d01 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes packet drop issue by removing the need for a LL header when redirecting packets via bpf_redirect() through xfrm interfaces.", + "keywords": "packet, xfrm, redirect", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "tc related type programs. It affects programs managing traffic control (tc) for queuing or prioritizing network traffic.", + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes dropped packets issue by ensuring the correct handling when redirecting packets through a xfrm interface without requiring a link layer header.", + "keywords": "packet, xfrm, bpf_redirect", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +-------------------- +-------------------- +Processing Commit 715/6895 - Commit ID: 95224166a9032ff5d08fca633d37113078ce7d01 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 95224166a9032ff5d08fca633d37113078ce7d01 + Author Name: Nicolas Dichtel + Author Email: nicolas.dichtel@6wind.com + Commit Date: 1578988538 + Commit Message: + vti[6]: fix packet tx through bpf_redirect() With an ebpf program that redirects packets through a vti[6] interface, the packets are dropped because no dst is attached. This could also be reproduced with an AF_PACKET socket, with the following python script (vti1 is an ip_vti interface): import socket send_s = socket.socket(socket.AF_PACKET, socket.SOCK_RAW, 0) # scapy # p = IP(src='10.100.0.2', dst='10.200.0.1')/ICMP(type='echo-request') # raw(p) req = b'E\x00\x00\x1c\x00\x01\x00\x00@\x01e\xb2\nd\x00\x02\n\xc8\x00\x01\x08\x00\xf7\xff\x00\x00\x00\x00' send_s.sendto(req, ('vti1', 0x800, 0, 0)) Signed-off-by: Nicolas Dichtel Signed-off-by: Steffen Klassert + Changed Files: net/ipv4/ip_vti.c | 13 +++++++++++--; net/ipv6/ip6_vti.c | 13 +++++++++++--; 2 files changed, 22 insertions(+), 4 deletions(-) + Parent Hashes: a112adafcb47760feff959ee1ecd10b74d2c5467 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit fixes packet transmission issues through bpf_redirect() when using vti[6] interfaces by attaching a destination to packets.", + "keywords": "bpf_redirect,vti6,packet", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here." + ] +} +Rethinking... +new content: +{ + "summary": "The commit resolves packet dropping issues in bpf_redirect() for vti[6] interfaces by ensuring packets have a destination attached.", + "keywords": "bpf_redirect,vti,packet", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here." + ] +} +-------------------- +-------------------- +Processing Commit 716/6895 - Commit ID: 9c01546d26d28cf57341d8380ba900bf68e26b18 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 9c01546d26d28cf57341d8380ba900bf68e26b18 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1578966493 + Commit Message: + tools/bpf: Add runqslower tool to tools/bpf Convert one of BCC tools (runqslower [0]) to BPF CO-RE + libbpf. It matches its BCC-based counterpart 1-to-1, supporting all the same parameters and functionality. runqslower tool utilizes BPF skeleton, auto-generated from BPF object file, as well as memory-mapped interface to global (read-only, in this case) data. Its Makefile also ensures auto-generation of "relocatable" vmlinux.h, which is necessary for BTF-typed raw tracepoints with direct memory access. [0] https://github.com/iovisor/bcc/blob/11bf5d02c895df9646c117c713082eb192825293/tools/runqslower.py Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200113073143.1779940-6-andriin@fb.com + Changed Files: tools/bpf/Makefile | 20 +++-; tools/bpf/runqslower/.gitignore | 1 +; tools/bpf/runqslower/Makefile | 80 +++++++++++++++; tools/bpf/runqslower/runqslower.bpf.c | 100 ++++++++++++++++++; tools/bpf/runqslower/runqslower.c | 187 ++++++++++++++++++++++++++++++++++; tools/bpf/runqslower/runqslower.h | 13 +++; 6 files changed, 396 insertions(+), 5 deletions(-) + Parent Hashes: 1cf5b23988ea0086a252a5c8b005b075f1e9b030 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds the runqslower tool to the BPF tools directory, converting it from BCC to BPF CO-RE and libbpf.", + "keywords": "runqslower, BPF CO-RE, libbpf", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds the runqslower tool to the BPF tools directory by converting it from BCC to BPF CO-RE and libbpf.", + "keywords": "runqslower,BPF CO-RE,libbpf", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 717/6895 - Commit ID: 1cf5b23988ea0086a252a5c8b005b075f1e9b030 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 1cf5b23988ea0086a252a5c8b005b075f1e9b030 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1578966493 + Commit Message: + bpftool: Apply preserve_access_index attribute to all types in BTF dump This patch makes structs and unions, emitted through BTF dump, automatically CO-RE-relocatable (unless disabled with `#define BPF_NO_PRESERVE_ACCESS_INDEX`, specified before including generated header file). This effectivaly turns usual bpf_probe_read() call into equivalent of bpf_core_read(), by automatically applying builtin_preserve_access_index to any field accesses of types in generated C types header. This is especially useful for tp_btf/fentry/fexit BPF program types. They allow direct memory access, so BPF C code just uses straightfoward a->b->c access pattern to read data from kernel. But without kernel structs marked as CO-RE relocatable through preserve_access_index attribute, one has to enclose all the data reads into a special __builtin_preserve_access_index code block, like so: __builtin_preserve_access_index(({ x = p->pid; /* where p is struct task_struct *, for example */ })); This is very inconvenient and obscures the logic quite a bit. By marking all auto-generated types with preserve_access_index attribute the above code is reduced to just a clean and natural `x = p->pid;`. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200113073143.1779940-5-andriin@fb.com + Changed Files: tools/bpf/bpftool/btf.c | 8 ++++++++; 1 file changed, 8 insertions(+) + Parent Hashes: 2cc51d34d93c9cf76128da6535a2a0a38c9faddb +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit updates bpftool to use preserve_access_index attribute for BTF dump types, simplifying direct memory access in BPF programs.", + "keywords": "bpftool,BTF,preserve_access_index", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "Scheduler related type programs. It modifies programs that interact with kernel-level scheduling mechanisms.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit updates bpftool to use preserve_access_index attribute for BTF dump types, simplifying direct memory access in BPF programs.", + "keywords": "bpftool,BTF,preserve_access_index", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "Scheduler related type programs. It modifies programs that interact with kernel-level scheduling mechanisms.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 718/6895 - Commit ID: 2cc51d34d93c9cf76128da6535a2a0a38c9faddb +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 2cc51d34d93c9cf76128da6535a2a0a38c9faddb + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1578966493 + Commit Message: + selftests/bpf: Conform selftests/bpf Makefile output to libbpf and bpftool Bring selftest/bpf's Makefile output to the same format used by libbpf and bpftool: 2 spaces of padding on the left + 8-character left-aligned build step identifier. Also, hide feature detection output by default. Can be enabled back by setting V=1. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200113073143.1779940-4-andriin@fb.com + Changed Files: tools/testing/selftests/bpf/Makefile | 47 +++++++++++++++++++-----------------; 1 file changed, 25 insertions(+), 22 deletions(-) + Parent Hashes: 292e1d73b125d7a3fd7ff382557e003ece3c0d65 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit modifies the selftests/bpf Makefile to conform its output format with libbpf and bpftool.", + "keywords": "selftests, Makefile, libbpf", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit updates the selftests/bpf Makefile for consistent output formatting with libbpf and bpftool.", + "keywords": "selftests, Makefile, formatting", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 719/6895 - Commit ID: 292e1d73b125d7a3fd7ff382557e003ece3c0d65 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 292e1d73b125d7a3fd7ff382557e003ece3c0d65 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1578966493 + Commit Message: + libbpf: Clean up bpf_helper_defs.h generation output bpf_helpers_doc.py script, used to generate bpf_helper_defs.h, unconditionally emits one informational message to stderr. Remove it and preserve stderr to contain only relevant errors. Also make sure script invocations command is muted by default in libbpf's Makefile. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200113073143.1779940-3-andriin@fb.com + Changed Files: scripts/bpf_helpers_doc.py | 2 --; tools/lib/bpf/Makefile | 2 +-; 2 files changed, 1 insertion(+), 3 deletions(-) + Parent Hashes: 533420a4151e28e6a38a830cb876afddb5587d7d +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit cleans up the stderr output in bpf_helper_defs.h generation and mutes command output by default in libbpf's Makefile.", + "keywords": "libbpf, stderr, Makefile", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit refines console output during bpf_helper_defs.h generation and adjusts default command verbosity in libbpf Makefile.", + "keywords": "libbpf, generation, Makefile", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 720/6895 - Commit ID: 533420a4151e28e6a38a830cb876afddb5587d7d +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 533420a4151e28e6a38a830cb876afddb5587d7d + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1578966492 + Commit Message: + tools: Sync uapi/linux/if_link.h Sync uapi/linux/if_link.h into tools to avoid out of sync warnings during libbpf build. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200113073143.1779940-2-andriin@fb.com + Changed Files: tools/include/uapi/linux/if_link.h | 1 +; 1 file changed, 1 insertion(+) + Parent Hashes: ac065870d92824ee0bc275ab71fd8901dbde5055 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Sync uapi/linux/if_link.h in tools to prevent out-of-sync warnings during libbpf build.", + "keywords": "sync,uapi,tools", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Sync uapi/linux/if_link.h in tools to avoid out-of-sync warnings during libbpf build.", + "keywords": "sync,uapi,libbpf", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 721/6895 - Commit ID: 8649c322f75c96e7ced2fec201e123b2b073bf09 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 8649c322f75c96e7ced2fec201e123b2b073bf09 + Author Name: Sargun Dhillon + Author Email: sargun@sargun.me + Commit Date: 1578948576 + Commit Message: + pid: Implement pidfd_getfd syscall This syscall allows for the retrieval of file descriptors from other processes, based on their pidfd. This is possible using ptrace, and injection of parasitic code to inject code which leverages SCM_RIGHTS to move file descriptors between a tracee and a tracer. Unfortunately, ptrace comes with a high cost of requiring the process to be stopped, and breaks debuggers. This does not require stopping the process under manipulation. One reason to use this is to allow sandboxers to take actions on file descriptors on the behalf of another process. For example, this can be combined with seccomp-bpf's user notification to do on-demand fd extraction and take privileged actions. One such privileged action is binding a socket to a privileged port. /* prototype */ /* flags is currently reserved and should be set to 0 */ int sys_pidfd_getfd(int pidfd, int fd, unsigned int flags); /* testing */ Ran self-test suite on x86_64 Signed-off-by: Sargun Dhillon Acked-by: Christian Brauner Reviewed-by: Arnd Bergmann Link: https://lore.kernel.org/r/20200107175927.4558-3-sargun@sargun.me Signed-off-by: Christian Brauner + Changed Files: kernel/pid.c | 90 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++; 1 file changed, 90 insertions(+) + Parent Hashes: 5e876fb43dbf24c941a323139752bcb2f0a80da0 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit implements the new syscall pidfd_getfd to retrieve file descriptors from other processes without stopping them.", + "keywords": "pidfd_getfd, syscall, file_descriptors", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +Rethinking... +new content: +{ + "summary": "This commit implements the new syscall pidfd_getfd to retrieve file descriptors from other processes without stopping them.", + "keywords": "pidfd_getfd, syscall, file_descriptors", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +-------------------- +-------------------- +Processing Commit 722/6895 - Commit ID: 555089fdfc37ad65e0ee9b42ca40c238ff546f83 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 555089fdfc37ad65e0ee9b42ca40c238ff546f83 + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1578798501 + Commit Message: + bpftool: Fix printing incorrect pointer in btf_dump_ptr For plain text output, it incorrectly prints the pointer value "void *data". The "void *data" is actually pointing to memory that contains a bpf-map's value. The intention is to print the content of the bpf-map's value instead of printing the pointer pointing to the bpf-map's value. In this case, a member of the bpf-map's value is a pointer type. Thus, it should print the "*(void **)data". Fixes: 22c349e8db89 ("tools: bpftool: fix format strings and arguments for jsonw_printf()") Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200110231644.3484151-1-kafai@fb.com + Changed Files: tools/bpf/bpftool/btf_dumper.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: 2e012c74823629d9db27963c79caa3f5b2010746 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes incorrect pointer printing in bpftool's btf_dump_ptr function for plain text output to display bpf-map's value content correctly.", + "keywords": "bpftool, btf_dump_ptr, pointer", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit corrects bpftool to properly print the content of bpf-maps' values instead of pointer addresses.", + "keywords": "bpftool, pointer, bpf-map", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 723/6895 - Commit ID: ac065870d92824ee0bc275ab71fd8901dbde5055 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: ac065870d92824ee0bc275ab71fd8901dbde5055 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1578693727 + Commit Message: + selftests/bpf: Add BPF_PROG, BPF_KPROBE, and BPF_KRETPROBE macros Streamline BPF_TRACE_x macro by moving out return type and section attribute definition out of macro itself. That makes those function look in source code similar to other BPF programs. Additionally, simplify its usage by determining number of arguments automatically (so just single BPF_TRACE vs a family of BPF_TRACE_1, BPF_TRACE_2, etc). Also, allow more natural function argument syntax without commas inbetween argument type and name. Given this helper is useful not only for tracing tp_btf/fenty/fexit programs, but could be used for LSM programs and others following the same pattern, rename BPF_TRACE macro into more generic BPF_PROG. Existing BPF_TRACE_x usages in selftests are converted to new BPF_PROG macro. Following the same pattern, define BPF_KPROBE and BPF_KRETPROBE macros for nicer usage of kprobe/kretprobe arguments, respectively. BPF_KRETPROBE, adopts same convention used by fexit programs, that last defined argument is probed function's return result. v4->v5: - fix test_overhead test (__set_task_comm is void) (Alexei); v3->v4: - rebased and fixed one more BPF_TRACE_x occurence (Alexei); v2->v3: - rename to shorter and as generic BPF_PROG (Alexei); v1->v2: - verified GCC handles pragmas as expected; - added descriptions to macros; - converted new STRUCT_OPS selftest to BPF_HANDLER (worked as expected); - added original context as 'ctx' parameter, for cases where it has to be passed into BPF helpers. This might cause an accidental naming collision, unfortunately, but at least it's easy to work around. Fortunately, this situation produces quite legible compilation error: progs/bpf_dctcp.c:46:6: error: redefinition of 'ctx' with a different type: 'int' vs 'unsigned long long *' int ctx = 123; ^ progs/bpf_dctcp.c:42:6: note: previous definition is here void BPF_HANDLER(dctcp_init, struct sock *sk) ^ ./bpf_trace_helpers.h:58:32: note: expanded from macro 'BPF_HANDLER' ____##name(unsigned long long *ctx, ##args) Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200110211634.1614739-1-andriin@fb.com + Changed Files: tools/testing/selftests/bpf/bpf_tcp_helpers.h | 9 --; tools/testing/selftests/bpf/bpf_trace_helpers.h | 166 ++++++++++++++-------; tools/testing/selftests/bpf/progs/bpf_dctcp.c | 26 ++--; tools/testing/selftests/bpf/progs/fentry_test.c | 21 +--; tools/testing/selftests/bpf/progs/fexit_bpf2bpf.c | 12 +-; .../selftests/bpf/progs/fexit_bpf2bpf_simple.c | 5 +-; tools/testing/selftests/bpf/progs/fexit_test.c | 23 +--; tools/testing/selftests/bpf/progs/kfree_skb.c | 16 +-; tools/testing/selftests/bpf/progs/test_overhead.c | 30 ++--; .../testing/selftests/bpf/progs/test_perf_buffer.c | 3 +-; .../testing/selftests/bpf/progs/test_probe_user.c | 3 +-; 11 files changed, 193 insertions(+), 121 deletions(-) + Parent Hashes: 1d1a3bcffe360a56fd8cc287ed74d4c3066daf42 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit introduces BPF_PROG, BPF_KPROBE, and BPF_KRETPROBE macros for improved macro usage and consistency in tracing BPF programs.", + "keywords": "macros, BPF_PROG, tracing", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit introduces new macros for BPF programs to streamline and simplify function declaration and usage in selftests.", + "keywords": "macros,BPF_PROG,selftests", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 724/6895 - Commit ID: db885e66d268884dc72967279b7e84f522556abc +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: db885e66d268884dc72967279b7e84f522556abc + Author Name: Jakub Kicinski + Author Email: jakub.kicinski@netronome.com + Commit Date: 1578684046 + Commit Message: + net/tls: fix async operation Mallesham reports the TLS with async accelerator was broken by commit d10523d0b3d7 ("net/tls: free the record on encryption error") because encryption can return -EINPROGRESS in such setups, which should not be treated as an error. The error is also present in the BPF path (likely copied from there). Reported-by: Mallesham Jatharakonda Fixes: d3b18ad31f93 ("tls: add bpf support to sk_msg handling") Fixes: d10523d0b3d7 ("net/tls: free the record on encryption error") Signed-off-by: Jakub Kicinski Reviewed-by: Simon Horman Signed-off-by: David S. Miller + Changed Files: net/tls/tls_sw.c | 4 ++--; 1 file changed, 2 insertions(+), 2 deletions(-) + Parent Hashes: 5c5d22a750d4bcf35e9539dccec397b0edcce176 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes an issue with async TLS operations incorrectly treating -EINPROGRESS as an error.", + "keywords": "TLS, async, fix", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes an issue with async TLS operations incorrectly treating -EINPROGRESS as an error.", + "keywords": "TLS, async, fix", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +-------------------- +-------------------- +Processing Commit 725/6895 - Commit ID: 2e012c74823629d9db27963c79caa3f5b2010746 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 2e012c74823629d9db27963c79caa3f5b2010746 + Author Name: Lorenz Bauer + Author Email: lmb@cloudflare.com + Commit Date: 1578681743 + Commit Message: + net: bpf: Don't leak time wait and request sockets It's possible to leak time wait and request sockets via the following BPF pseudo code:   sk = bpf_skc_lookup_tcp(...) if (sk) bpf_sk_release(sk) If sk->sk_state is TCP_NEW_SYN_RECV or TCP_TIME_WAIT the refcount taken by bpf_skc_lookup_tcp is not undone by bpf_sk_release. This is because sk_flags is re-used for other data in both kinds of sockets. The check !sock_flag(sk, SOCK_RCU_FREE) therefore returns a bogus result. Check that sk_flags is valid by calling sk_fullsock. Skip checking SOCK_RCU_FREE if we already know that sk is not a full socket. Fixes: edbf8c01de5a ("bpf: add skc_lookup_tcp helper") Fixes: f7355a6c0497 ("bpf: Check sk_fullsock() before returning from bpf_sk_lookup()") Signed-off-by: Lorenz Bauer Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200110132336.26099-1-lmb@cloudflare.com + Changed Files: net/core/filter.c | 9 ++++-----; 1 file changed, 4 insertions(+), 5 deletions(-) + Parent Hashes: e7a5f1f1cd0008e5ad379270a8657e121eedb669 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes a socket reference leak in eBPF when using the bpf_skc_lookup_tcp helper function.", + "keywords": "socket,leak,bpf_skc_lookup_tcp", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes a socket reference leak in eBPF when using the bpf_skc_lookup_tcp helper function.", + "keywords": "socket,leak,bpf_skc_lookup_tcp", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 726/6895 - Commit ID: 1d1a3bcffe360a56fd8cc287ed74d4c3066daf42 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 1d1a3bcffe360a56fd8cc287ed74d4c3066daf42 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1578681480 + Commit Message: + libbpf: Poison kernel-only integer types It's been a recurring issue with types like u32 slipping into libbpf source code accidentally. This is not detected during builds inside kernel source tree, but becomes a compilation error in libbpf's Github repo. Libbpf is supposed to use only __{s,u}{8,16,32,64} typedefs, so poison {s,u}{8,16,32,64} explicitly in every .c file. Doing that in a bit more centralized way, e.g., inside libbpf_internal.h breaks selftests, which are both using kernel u32 and libbpf_internal.h. This patch also fixes a new u32 occurence in libbpf.c, added recently. Fixes: 590a00888250 ("bpf: libbpf: Add STRUCT_OPS support") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200110181916.271446-1-andriin@fb.com + Changed Files: tools/lib/bpf/bpf.c | 3 +++; tools/lib/bpf/bpf_prog_linfo.c | 3 +++; tools/lib/bpf/btf.c | 3 +++; tools/lib/bpf/btf_dump.c | 3 +++; tools/lib/bpf/hashmap.c | 3 +++; tools/lib/bpf/libbpf.c | 5 ++++-; tools/lib/bpf/libbpf_errno.c | 3 +++; tools/lib/bpf/libbpf_probes.c | 3 +++; tools/lib/bpf/netlink.c | 3 +++; tools/lib/bpf/nlattr.c | 3 +++; tools/lib/bpf/str_error.c | 3 +++; tools/lib/bpf/xsk.c | 3 +++; 12 files changed, 37 insertions(+), 1 deletion(-) + Parent Hashes: 7a2d070f91db83a1e08bf212e8f6a34d852efb7f +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit poisons kernel-only integer types in libbpf to prevent accidental use outside the kernel.", + "keywords": "libbpf,integer,types", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit poisons kernel-only integer types in libbpf to prevent accidental use outside the kernel repository.", + "keywords": "libbpf,integer,types", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 727/6895 - Commit ID: 7a2d070f91db83a1e08bf212e8f6a34d852efb7f +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 7a2d070f91db83a1e08bf212e8f6a34d852efb7f + Author Name: Daniel Borkmann + Author Email: daniel@iogearbox.net + Commit Date: 1578673219 + Commit Message: + Merge branch 'bpf-global-funcs' Alexei Starovoitov says: ==================== Introduce static vs global functions and function by function verification. This is another step toward dynamic re-linking (or replacement) of global functions. See patch 2 for details. v2->v3: - cleaned up a check spotted by Song. - rebased and dropped patch 2 that was trying to improve BTF based on ELF. - added one more unit test for scalar return value from global func. v1->v2: - addressed review comments from Song, Andrii, Yonghong - fixed memory leak in error path - added modified ctx check - added more tests in patch 7 ==================== Signed-off-by: Daniel Borkmann + Changed Files: nan + Parent Hashes: f41aa387a7896c193b384c5fb531cd2cb9e00128 360301a6c21be87fe881546bd5f22eccf7a165c5 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit merges changes introducing static vs global functions and function-by-function verification for eBPF, aiming towards dynamic re-linking of global functions.", + "keywords": "static functions,global functions,function verification", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit merges changes to introduce static vs global functions and function-by-function verification towards dynamic re-linking of global functions in eBPF.", + "keywords": "static functions,global functions,verification", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 728/6895 - Commit ID: 360301a6c21be87fe881546bd5f22eccf7a165c5 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 360301a6c21be87fe881546bd5f22eccf7a165c5 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1578673207 + Commit Message: + selftests/bpf: Add unit tests for global functions test_global_func[12] - check 512 stack limit. test_global_func[34] - check 8 frame call chain limit. test_global_func5 - check that non-ctx pointer cannot be passed into a function that expects context. test_global_func6 - check that ctx pointer is unmodified. test_global_func7 - check that global function returns scalar. Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200110064124.1760511-7-ast@kernel.org + Changed Files: .../selftests/bpf/prog_tests/test_global_funcs.c | 82 ++++++++++++++++++++++; .../selftests/bpf/progs/test_global_func1.c | 45 ++++++++++++; .../selftests/bpf/progs/test_global_func2.c | 4 ++; .../selftests/bpf/progs/test_global_func3.c | 65 +++++++++++++++++; .../selftests/bpf/progs/test_global_func4.c | 4 ++; .../selftests/bpf/progs/test_global_func5.c | 31 ++++++++; .../selftests/bpf/progs/test_global_func6.c | 31 ++++++++; .../selftests/bpf/progs/test_global_func7.c | 18 +++++; 8 files changed, 280 insertions(+) + Parent Hashes: e528d1c0127accbc2be48f57dd67ab89b32fd815 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds unit tests for global functions in eBPF to verify stack and call chain limits, context pointer handling, and return values.", + "keywords": "unit tests, global functions, eBPF", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds unit tests for global eBPF functions to enforce stack, call chain limits, and context handling.", + "keywords": "unit tests, stack limit, call chain", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 729/6895 - Commit ID: e528d1c0127accbc2be48f57dd67ab89b32fd815 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: e528d1c0127accbc2be48f57dd67ab89b32fd815 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1578673207 + Commit Message: + selftests/bpf: Modify a test to check global functions Make two static functions in test_xdp_noinline.c global: before: processed 2790 insns after: processed 2598 insns Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200110064124.1760511-6-ast@kernel.org + Changed Files: tools/testing/selftests/bpf/progs/test_xdp_noinline.c | 4 ++--; 1 file changed, 2 insertions(+), 2 deletions(-) + Parent Hashes: 6db2d81a46f99edb5690cf0b03bbe3b7f29dfd7b +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit modifies a test to check global functions by making two static functions global in a selftest file.", + "keywords": "selftests,bpf,functions", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +Rethinking... +new content: +{ + "summary": "The commit modifies a selftest to evaluate global function behavior by converting static functions to global in a BPF test file.", + "keywords": "selftests,bpf,global", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +-------------------- +-------------------- +Processing Commit 730/6895 - Commit ID: 6db2d81a46f99edb5690cf0b03bbe3b7f29dfd7b +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 6db2d81a46f99edb5690cf0b03bbe3b7f29dfd7b + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1578673207 + Commit Message: + selftests/bpf: Add a test for a large global function test results: pyperf50 with always_inlined the same function five times: processed 46378 insns pyperf50 with global function: processed 6102 insns Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200110064124.1760511-5-ast@kernel.org + Changed Files: tools/testing/selftests/bpf/prog_tests/bpf_verif_scale.c | 2 ++; tools/testing/selftests/bpf/progs/pyperf.h | 9 +++++++--; tools/testing/selftests/bpf/progs/pyperf_global.c | 5 +++++; 3 files changed, 14 insertions(+), 2 deletions(-) + Parent Hashes: 7608e4db6ded8e965dd213baddedba9602959e7d +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds a selftest for large global functions in eBPF to compare inline and global function processing.", + "keywords": "selftests,global,function", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds selftests for large global function processing in eBPF, comparing inline and global function results.", + "keywords": "selftests,global,function", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 731/6895 - Commit ID: 7608e4db6ded8e965dd213baddedba9602959e7d +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 7608e4db6ded8e965dd213baddedba9602959e7d + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1578673207 + Commit Message: + selftests/bpf: Add fexit-to-skb test for global funcs Add simple fexit prog type to skb prog type test when subprogram is a global function. Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200110064124.1760511-4-ast@kernel.org + Changed Files: .../selftests/bpf/prog_tests/fexit_bpf2bpf.c | 1 +; tools/testing/selftests/bpf/progs/fexit_bpf2bpf.c | 15 ++++++++++++; .../testing/selftests/bpf/progs/test_pkt_access.c | 28 ++++++++++++++++++++++; 3 files changed, 44 insertions(+) + Parent Hashes: 51c39bb1d5d105a02e29aa7960f0a395086e6342 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds a test for fexit programs targeting skb program type with global functions.", + "keywords": "selftests,bpf,fexit", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds a test to verify fexit programs with global functions in skb program type.", + "keywords": "selftests,bpf,tests", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing." + ] +} +-------------------- +-------------------- +Processing Commit 732/6895 - Commit ID: 51c39bb1d5d105a02e29aa7960f0a395086e6342 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 51c39bb1d5d105a02e29aa7960f0a395086e6342 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1578673207 + Commit Message: + bpf: Introduce function-by-function verification New llvm and old llvm with libbpf help produce BTF that distinguish global and static functions. Unlike arguments of static function the arguments of global functions cannot be removed or optimized away by llvm. The compiler has to use exactly the arguments specified in a function prototype. The argument type information allows the verifier validate each global function independently. For now only supported argument types are pointer to context and scalars. In the future pointers to structures, sizes, pointer to packet data can be supported as well. Consider the following example: static int f1(int ...) { ... } int f3(int b); int f2(int a) { f1(a) + f3(a); } int f3(int b) { ... } int main(...) { f1(...) + f2(...) + f3(...); } The verifier will start its safety checks from the first global function f2(). It will recursively descend into f1() because it's static. Then it will check that arguments match for the f3() invocation inside f2(). It will not descend into f3(). It will finish f2() that has to be successfully verified for all possible values of 'a'. Then it will proceed with f3(). That function also has to be safe for all possible values of 'b'. Then it will start subprog 0 (which is main() function). It will recursively descend into f1() and will skip full check of f2() and f3(), since they are global. The order of processing global functions doesn't affect safety, since all global functions must be proven safe based on their arguments only. Such function by function verification can drastically improve speed of the verification and reduce complexity. Note that the stack limit of 512 still applies to the call chain regardless whether functions were static or global. The nested level of 8 also still applies. The same recursion prevention checks are in place as well. The type information and static/global kind is preserved after the verification hence in the above example global function f2() and f3() can be replaced later by equivalent functions with the same types that are loaded and verified later without affecting safety of this main() program. Such replacement (re-linking) of global functions is a subject of future patches. Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200110064124.1760511-3-ast@kernel.org + Changed Files: include/linux/bpf.h | 7 +-; include/linux/bpf_verifier.h | 10 +-; include/uapi/linux/btf.h | 6 ++; kernel/bpf/btf.c | 175 ++++++++++++++++++++++++------; kernel/bpf/verifier.c | 252 ++++++++++++++++++++++++++++++++++---------; 5 files changed, 366 insertions(+), 84 deletions(-) + Parent Hashes: 2d3eb67f64ec317bbfe340cfcc8325d40a6ff317 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit introduces a function-by-function verification approach in eBPF to improve verification speed and reduce complexity.", + "keywords": "eBPF,verification,llvm", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit introduces a function-by-function verification approach in eBPF to improve verification speed and reduce complexity.", + "keywords": "eBPF,verification,llvm", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 733/6895 - Commit ID: 2d3eb67f64ec317bbfe340cfcc8325d40a6ff317 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 2d3eb67f64ec317bbfe340cfcc8325d40a6ff317 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1578673207 + Commit Message: + libbpf: Sanitize global functions In case the kernel doesn't support BTF_FUNC_GLOBAL sanitize BTF produced by the compiler for global functions. Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200110064124.1760511-2-ast@kernel.org + Changed Files: tools/include/uapi/linux/btf.h | 6 ++++++; tools/lib/bpf/libbpf.c | 35 ++++++++++++++++++++++++++++++++++-; 2 files changed, 40 insertions(+), 1 deletion(-) + Parent Hashes: f41aa387a7896c193b384c5fb531cd2cb9e00128 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit sanitizes BTF produced for global functions in libbpf when kernel lacks BTF_FUNC_GLOBAL support.", + "keywords": "sanitize, global, BTF", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit sanitizes BTF data for global functions in libbpf when kernel lacks BTF_FUNC_GLOBAL support.", + "keywords": "sanitize, global, BTF", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 734/6895 - Commit ID: f41aa387a7896c193b384c5fb531cd2cb9e00128 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: f41aa387a7896c193b384c5fb531cd2cb9e00128 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1578635776 + Commit Message: + Merge branch 'selftest-makefile-cleanup' Andrii Nakryiko says: ==================== Fix issues with bpf_helper_defs.h usage in selftests/bpf. As part of that, fix the way clean up is performed for libbpf and selftests/bpf. Some for Makefile output clean ups as well. ==================== Signed-off-by: Alexei Starovoitov + Changed Files: nan + Parent Hashes: 492ab0205f500ebd20b4f0c9e95a1ba007b0c542 965b9fee28d062c79a5fdaa3dfbe04c5129ee63d +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Merge branch for selftest Makefile cleanup and fix issues with bpf_helper_defs.h in libbpf and selftests.", + "keywords": "selftest, makefile, cleanup", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "Merge commit addressing selftest Makefile cleanup and bpf_helper_defs.h issues with libbpf adjustments.", + "keywords": "selftest, libbpf, Makefile", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 735/6895 - Commit ID: 965b9fee28d062c79a5fdaa3dfbe04c5129ee63d +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 965b9fee28d062c79a5fdaa3dfbe04c5129ee63d + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1578635708 + Commit Message: + selftests/bpf: Further clean up Makefile output Further clean up Makefile output: - hide "entering directory" messages; - silvence sub-Make command echoing; - succinct MKDIR messages. Also remove few test binaries that are not produced anymore from .gitignore. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200110051716.1591485-4-andriin@fb.com + Changed Files: tools/testing/selftests/bpf/.gitignore | 2 --; tools/testing/selftests/bpf/Makefile | 10 +++++++---; 2 files changed, 7 insertions(+), 5 deletions(-) + Parent Hashes: 6910d7d3867a8e65eaecb18a9527ecc9eb2e5edf +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit cleans up the Makefile output and updates the .gitignore for unused test binaries in selftests/bpf.", + "keywords": "Makefile, clean, .gitignore", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit improves Makefile output readability and updates .gitignore by removing obsolete test binaries in selftests/bpf.", + "keywords": "Makefile, output, .gitignore", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 736/6895 - Commit ID: 6910d7d3867a8e65eaecb18a9527ecc9eb2e5edf +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 6910d7d3867a8e65eaecb18a9527ecc9eb2e5edf + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1578635708 + Commit Message: + selftests/bpf: Ensure bpf_helper_defs.h are taken from selftests dir Reorder includes search path to ensure $(OUTPUT) and $(CURDIR) go before libbpf's directory. Also fix bpf_helpers.h to include bpf_helper_defs.h in such a way as to leverage includes search path. This allows selftests to not use libbpf's local and potentially stale bpf_helper_defs.h. It's important because selftests/bpf's Makefile only re-generates bpf_helper_defs.h in seltests' output directory, not the one in libbpf's directory. Also force regeneration of bpf_helper_defs.h when libbpf.a is updated to reduce staleness. Fixes: fa633a0f8919 ("libbpf: Fix build on read-only filesystems") Reported-by: Alexei Starovoitov Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200110051716.1591485-3-andriin@fb.com + Changed Files: tools/lib/bpf/bpf_helpers.h | 2 +-; tools/testing/selftests/bpf/Makefile | 12 ++++++------; 2 files changed, 7 insertions(+), 7 deletions(-) + Parent Hashes: 2031af28a42f18cc65ec3aa85b4e5cfdf5ee0fe8 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit updates include paths in selftests to ensure bpf_helper_defs.h is used from the correct directory.", + "keywords": "selftests,bpf_helpers,Makefile", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit updates the include paths for selftests to use the correct bpf_helper_defs.h directory.", + "keywords": "selftests,BPF,Makefile", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 737/6895 - Commit ID: 2031af28a42f18cc65ec3aa85b4e5cfdf5ee0fe8 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 2031af28a42f18cc65ec3aa85b4e5cfdf5ee0fe8 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1578635708 + Commit Message: + libbpf,selftests/bpf: Fix clean targets Libbpf's clean target should clean out generated files in $(OUTPUT) directory and not make assumption that $(OUTPUT) directory is current working directory. Selftest's Makefile should delegate cleaning of libbpf-generated files to libbpf's Makefile. This ensures more robust clean up. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200110051716.1591485-2-andriin@fb.com + Changed Files: tools/lib/bpf/Makefile | 9 +++++----; tools/testing/selftests/bpf/Makefile | 5 +++--; 2 files changed, 8 insertions(+), 6 deletions(-) + Parent Hashes: 492ab0205f500ebd20b4f0c9e95a1ba007b0c542 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes clean targets for libbpf and selftests to ensure robust cleanup of generated files.", + "keywords": "libbpf,Makefile,clean", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes clean targets for libbpf and selftests to ensure robust cleanup of generated files.", + "keywords": "libbpf,Makefile,clean", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 738/6895 - Commit ID: 492ab0205f500ebd20b4f0c9e95a1ba007b0c542 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 492ab0205f500ebd20b4f0c9e95a1ba007b0c542 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1578633421 + Commit Message: + libbpf: Make bpf_map order and indices stable Currently, libbpf re-sorts bpf_map structs after all the maps are added and initialized, which might change their relative order and invalidate any bpf_map pointer or index taken before that. This is inconvenient and error-prone. For instance, it can cause .kconfig map index to point to a wrong map. Furthermore, libbpf itself doesn't rely on any specific ordering of bpf_maps, so it's just an unnecessary complication right now. This patch drops sorting of maps and makes their relative positions fixed. If efficient index is ever needed, it's better to have a separate array of pointers as a search index, instead of reordering bpf_map struct in-place. This will be less error-prone and will allow multiple independent orderings, if necessary (e.g., either by section index or by name). Fixes: 166750bc1dd2 ("libbpf: Support libbpf-provided extern variables") Reported-by: Martin KaFai Lau Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200110034247.1220142-1-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.c | 14 --------------; 1 file changed, 14 deletions(-) + Parent Hashes: f5bfcd953d811dbb8913de36b96b38da6bb62135 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit stabilizes the order and indices of bpf_maps in libbpf to prevent errors.", + "keywords": "libbpf,bpf_map,indices", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit stabilizes the order and indices of bpf_maps in libbpf to prevent errors.", + "keywords": "libbpf,bpf_map,indices", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 739/6895 - Commit ID: bf9765145b856fa2e238a5b8a54453795ba30ad6 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: bf9765145b856fa2e238a5b8a54453795ba30ad6 + Author Name: Mat Martineau + Author Email: mathew.j.martineau@linux.intel.com + Commit Date: 1578624101 + Commit Message: + sock: Make sk_protocol a 16-bit value Match the 16-bit width of skbuff->protocol. Fills an 8-bit hole so sizeof(struct sock) does not change. Also take care of BPF field access for sk_type/sk_protocol. Both of them are now outside the bitfield, so we can use load instructions without further shifting/masking. v5 -> v6: - update eBPF accessors, too (Intel's kbuild test robot) v2 -> v3: - keep 'sk_type' 2 bytes aligned (Eric) v1 -> v2: - preserve sk_pacing_shift as bit field (Eric) Cc: Alexei Starovoitov Cc: Daniel Borkmann Cc: bpf@vger.kernel.org Co-developed-by: Paolo Abeni Signed-off-by: Paolo Abeni Co-developed-by: Matthieu Baerts Signed-off-by: Matthieu Baerts Signed-off-by: Mat Martineau Signed-off-by: David S. Miller + Changed Files: include/net/sock.h | 25 ++++---------------; include/trace/events/sock.h | 2 +-; net/core/filter.c | 60 +++++++++++++++++----------------------------; 3 files changed, 28 insertions(+), 59 deletions(-) + Parent Hashes: e9cdced78dc20c1592c1fb98ed064943007a46c5 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit updates the sock structure to make sk_protocol a 16-bit value and adjusts related eBPF field access.", + "keywords": "sk_protocol, eBPF, sock", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "This commit changes sk_protocol to a 16-bit value and updates eBPF field access accordingly.", + "keywords": "sk_protocol,eBPF,sock", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 740/6895 - Commit ID: 36366e367ee93ced84fddb8fae6675e12985f5a4 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 36366e367ee93ced84fddb8fae6675e12985f5a4 + Author Name: Paul Burton + Author Email: paulburton@kernel.org + Commit Date: 1578610950 + Commit Message: + MIPS: BPF: Restore MIPS32 cBPF JIT Commit 716850ab104d ("MIPS: eBPF: Initial eBPF support for MIPS32 architecture.") enabled our eBPF JIT for MIPS32 kernels, whereas it has previously only been availailable for MIPS64. It was my understanding at the time that the BPF test suite was passing & JITing a comparable number of tests to our cBPF JIT [1], but it turns out that was not the case. The eBPF JIT has a number of problems on MIPS32: - Most notably various code paths still result in emission of MIPS64 instructions which will cause reserved instruction exceptions & kernel panics when run on MIPS32 CPUs. - The eBPF JIT doesn't account for differences between the O32 ABI used by MIPS32 kernels versus the N64 ABI used by MIPS64 kernels. Notably arguments beyond the first 4 are passed on the stack in O32, and this is entirely unhandled when JITing a BPF_CALL instruction. Stack space must be reserved for arguments even if they all fit in registers, and the callee is free to assume that stack space has been reserved for its use - with the eBPF JIT this is not the case, so calling any function can result in clobbering values on the stack & unpredictable behaviour. Function arguments in eBPF are always 64-bit values which is also entirely unhandled - the JIT still uses a single (32-bit) register per argument. As a result all function arguments are always passed incorrectly when JITing a BPF_CALL instruction, leading to kernel crashes or strange behavior. - The JIT attempts to bail our on use of ALU64 instructions or 64-bit memory access instructions. The code doing this at the start of build_one_insn() incorrectly checks whether BPF_OP() equals BPF_DW, when it should really be checking BPF_SIZE() & only doing so when BPF_CLASS() is one of BPF_{LD,LDX,ST,STX}. This results in false positives that cause more bailouts than intended, and that in turns hides some of the problems described above. - The kernel's cBPF->eBPF translation makes heavy use of 64-bit eBPF instructions that the MIPS32 eBPF JIT bails out on, leading to most cBPF programs not being JITed at all. Until these problems are resolved, revert the removal of the cBPF JIT performed by commit 716850ab104d ("MIPS: eBPF: Initial eBPF support for MIPS32 architecture."). Together with commit f8fffebdea75 ("MIPS: BPF: Disable MIPS32 eBPF JIT") this restores MIPS32 BPF JIT behavior back to the same state it was prior to the introduction of the broken eBPF JIT support. [1] https://lore.kernel.org/linux-mips/MWHPR2201MB13583388481F01A422CE7D66D4410@MWHPR2201MB1358.namprd22.prod.outlook.com/ Signed-off-by: Paul Burton Fixes: 716850ab104d ("MIPS: eBPF: Initial eBPF support for MIPS32 architecture.") Cc: Daniel Borkmann Cc: Hassan Naveed Cc: Tony Ambardar Cc: bpf@vger.kernel.org Cc: netdev@vger.kernel.org Cc: linux-mips@vger.kernel.org Cc: linux-kernel@vger.kernel.org + Changed Files: arch/mips/Kconfig | 1 +; arch/mips/net/Makefile | 1 +; arch/mips/net/bpf_jit.c | 1270 +++++++++++++++++++++++++++++++++++++++++++; arch/mips/net/bpf_jit_asm.S | 285 ++++++++++; 4 files changed, 1557 insertions(+) + Parent Hashes: 11d06df7b9f29ec5898901c2c94a58f4ecf60446 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit restores the MIPS32 cBPF JIT due to unresolved issues with the eBPF JIT on MIPS32.", + "keywords": "MIPS32,JIT,restore", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit restores the MIPS32 cBPF JIT due to unresolved issues with the eBPF JIT on MIPS32 architecture.", + "keywords": "MIPS32,JIT,restore", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 741/6895 - Commit ID: e7a5f1f1cd0008e5ad379270a8657e121eedb669 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: e7a5f1f1cd0008e5ad379270a8657e121eedb669 + Author Name: Lingpeng Chen + Author Email: forrest0579@gmail.com + Commit Date: 1578608028 + Commit Message: + bpf/sockmap: Read psock ingress_msg before sk_receive_queue Right now in tcp_bpf_recvmsg, sock read data first from sk_receive_queue if not empty than psock->ingress_msg otherwise. If a FIN packet arrives and there's also some data in psock->ingress_msg, the data in psock->ingress_msg will be purged. It is always happen when request to a HTTP1.0 server like python SimpleHTTPServer since the server send FIN packet after data is sent out. Fixes: 604326b41a6fb ("bpf, sockmap: convert to generic sk_msg interface") Reported-by: Arika Chen Suggested-by: Arika Chen Signed-off-by: Lingpeng Chen Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200109014833.18951-1-forrest0579@gmail.com + Changed Files: net/ipv4/tcp_bpf.c | 12 ++++++------; 1 file changed, 6 insertions(+), 6 deletions(-) + Parent Hashes: da29f2d84bd10234df570b7f07cbd0166e738230 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit fixes a bug in the sockmap interface to prevent purging of ingress_msg after FIN packet in tcp_bpf_recvmsg.", + "keywords": "sockmap ingress_msg tcp_bpf_recvmsg", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here.", + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +Rethinking... +new content: +{ + "summary": "This commit fixes a bug in tcp_bpf_recvmsg to correctly handle psock ingress_msg before sk_receive_queue after a FIN packet.", + "keywords": "sockmap ingress_msg tcp_bpf_recvmsg", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here.", + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +-------------------- +-------------------- +Processing Commit 742/6895 - Commit ID: a5f48c7878d2365f6ff7008e9317abbc16f68847 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: a5f48c7878d2365f6ff7008e9317abbc16f68847 + Author Name: Linus Torvalds + Author Email: torvalds@linux-foundation.org + Commit Date: 1578594847 + Commit Message: + Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from David Miller: 1) Missing netns pointer init in arp_tables, from Florian Westphal. 2) Fix normal tcp SACK being treated as D-SACK, from Pengcheng Yang. 3) Fix divide by zero in sch_cake, from Wen Yang. 4) Len passed to skb_put_padto() is wrong in qrtr code, from Carl Huang. 5) cmd->obj.chunk is leaked in sctp code error paths, from Xin Long. 6) cgroup bpf programs can be released out of order, fix from Roman Gushchin. 7) Make sure stmmac debugfs entry name is changed when device name changes, from Jiping Ma. 8) Fix memory leak in vlan_dev_set_egress_priority(), from Eric Dumazet. 9) SKB leak in lan78xx usb driver, also from Eric Dumazet. 10) Ridiculous TCA_FQ_QUANTUM values configured can cause loops in fq packet scheduler, reject them. From Eric Dumazet. * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (69 commits) tipc: fix wrong connect() return code tipc: fix link overflow issue at socket shutdown netfilter: ipset: avoid null deref when IPSET_ATTR_LINENO is present netfilter: conntrack: dccp, sctp: handle null timeout argument atm: eni: fix uninitialized variable warning macvlan: do not assume mac_header is set in macvlan_broadcast() net: sch_prio: When ungrafting, replace with FIFO mlxsw: spectrum_qdisc: Ignore grafting of invisible FIFO MAINTAINERS: Remove myself as co-maintainer for qcom-ethqos gtp: fix bad unlock balance in gtp_encap_enable_socket pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM tipc: remove meaningless assignment in Makefile tipc: do not add socket.o to tipc-y twice net: stmmac: dwmac-sun8i: Allow all RGMII modes net: stmmac: dwmac-sunxi: Allow all RGMII modes net: usb: lan78xx: fix possible skb leak net: stmmac: Fixed link does not need MDIO Bus vlan: vlan_changelink() should propagate errors vlan: fix memory leak in vlan_dev_set_egress_priority stmmac: debugfs entry name is not be changed when udev rename device name. ... + Changed Files: nan + Parent Hashes: b07f636fca1c8fbba124b0082487c0b3890a0e0c 9546a0b7ce0077d827470f603f2522b845ce5954 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Merge networking fixes addressing various network subsystem issues, including netns pointer, TCP SACK handling, and cgroup BPF program release order.", + "keywords": "networking,fixes,merge", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "Merge commit integrating various networking fixes addressing issues like netns pointer initialization and TCP SACK handling.", + "keywords": "networking,fixes,merge", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 743/6895 - Commit ID: f5bfcd953d811dbb8913de36b96b38da6bb62135 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: f5bfcd953d811dbb8913de36b96b38da6bb62135 + Author Name: Andrey Ignatov + Author Email: rdna@fb.com + Commit Date: 1578591606 + Commit Message: + bpf: Document BPF_F_QUERY_EFFECTIVE flag Document BPF_F_QUERY_EFFECTIVE flag, mostly to clarify how it affects attach_flags what may not be obvious and what may lead to confision. Specifically attach_flags is returned only for target_fd but if programs are inherited from an ancestor cgroup then returned attach_flags for current cgroup may be confusing. For example, two effective programs of same attach_type can be returned but w/o BPF_F_ALLOW_MULTI in attach_flags. Simple repro: # bpftool c s /sys/fs/cgroup/path/to/task ID AttachType AttachFlags Name # bpftool c s /sys/fs/cgroup/path/to/task effective ID AttachType AttachFlags Name 95043 ingress tw_ipt_ingress 95048 ingress tw_ingress Signed-off-by: Andrey Ignatov Signed-off-by: Alexei Starovoitov Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200108014006.938363-1-rdna@fb.com + Changed Files: include/uapi/linux/bpf.h | 7 ++++++-; tools/include/uapi/linux/bpf.h | 7 ++++++-; 2 files changed, 12 insertions(+), 2 deletions(-) + Parent Hashes: 417759f7d4cf44a5fb526fbafcc9372e3dbfc0ae +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit documents the BPF_F_QUERY_EFFECTIVE flag to clarify its impact on attach_flags in cgroup scenarios.", + "keywords": "BPF_F_QUERY_EFFECTIVE,attach_flags,cgroup", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The syscall interface. It changes the system calls through which user-space programs interact with eBPF.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups)." + ] +} +Rethinking... +new content: +{ + "summary": "The commit documents the BPF_F_QUERY_EFFECTIVE flag to clarify its impact on attach_flags in cgroup scenarios.", + "keywords": "BPF_F_QUERY_EFFECTIVE,attach_flags,cgroup", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The syscall interface. It changes the system calls through which user-space programs interact with eBPF.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups)." + ] +} +-------------------- +-------------------- +Processing Commit 744/6895 - Commit ID: 417759f7d4cf44a5fb526fbafcc9372e3dbfc0ae +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 417759f7d4cf44a5fb526fbafcc9372e3dbfc0ae + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1578590125 + Commit Message: + Merge branch 'tcp-bpf-cc' Martin Lau says: ==================== This series introduces BPF STRUCT_OPS. It is an infra to allow implementing some specific kernel's function pointers in BPF. The first use case included in this series is to implement TCP congestion control algorithm in BPF (i.e. implement struct tcp_congestion_ops in BPF). There has been attempt to move the TCP CC to the user space (e.g. CCP in TCP). The common arguments are faster turn around, get away from long-tail kernel versions in production...etc, which are legit points. BPF has been the continuous effort to join both kernel and userspace upsides together (e.g. XDP to gain the performance advantage without bypassing the kernel). The recent BPF advancements (in particular BTF-aware verifier, BPF trampoline, BPF CO-RE...) made implementing kernel struct ops (e.g. tcp cc) possible in BPF. The idea is to allow implementing tcp_congestion_ops in bpf. It allows a faster turnaround for testing algorithm in the production while leveraging the existing (and continue growing) BPF feature/framework instead of building one specifically for userspace TCP CC. Please see individual patch for details. The bpftool support will be posted in follow-up patches. v4: - Expose tcp_ca_find() to tcp.h in patch 7. It is used to check the same bpf-tcp-cc does not exist to guarantee the register() will succeed. - set_memory_ro() and then set_memory_x() only after all trampolines are written to the image in patch 6. (Daniel) spinlock is replaced by mutex because set_memory_* requires sleepable context. v3: - Fix kbuild error by considering CONFIG_BPF_SYSCALL (kbuild) - Support anonymous bitfield in patch 4 (Andrii, Yonghong) - Push boundary safety check to a specific arch's trampoline function (in patch 6) (Yonghong). Reuse the WANR_ON_ONCE check in arch_prepare_bpf_trampoline() in x86. - Check module field is 0 in udata in patch 6 (Yonghong) - Check zero holes in patch 6 (Andrii) - s/_btf_vmlinux/btf/ in patch 5 and 7 (Andrii) - s/check_xxx/is_xxx/ in patch 7 (Andrii) - Use "struct_ops/" convention in patch 11 (Andrii) - Use the skel instead of bpf_object in patch 11 (Andrii) - libbpf: Decide BPF_PROG_TYPE_STRUCT_OPS at open phase by using find_sec_def() - libbpf: Avoid a debug message at open phase (Andrii) - libbpf: Add bpf_program__(is|set)_struct_ops() for consistency (Andrii) - libbpf: Add "struct_ops" to section_defs (Andrii) - libbpf: Some code shuffling in init_kern_struct_ops() (Andrii) - libbpf: A few safety checks (Andrii) v2: - Dropped cubic for now. They will be reposted once there are more clarity in "jiffies" on both bpf side (about the helper) and tcp_cubic side (some of jiffies usages are being replaced by tp->tcp_mstamp) - Remove unnecssary check on bitfield support from btf_struct_access() (Yonghong) - BTF_TYPE_EMIT macro (Yonghong, Andrii) - value_name's length check to avoid an unlikely type match during truncation case (Yonghong) - BUILD_BUG_ON to ensure no trampoline-image overrun in the future (Yonghong) - Simplify get_next_key() (Yonghong) - Added comment to explain how to check mandatory func ptr in net/ipv4/bpf_tcp_ca.c (Yonghong) - Rename "__bpf_" to "bpf_struct_ops_" for value prefix (Andrii) - Add comment to highlight the bpf_dctcp.c is not necessarily the same as tcp_dctcp.c. (Alexei, Eric) - libbpf: Renmae "struct_ops" to ".struct_ops" for elf sec (Andrii) - libbpf: Expose struct_ops as a bpf_map (Andrii) - libbpf: Support multiple struct_ops in SEC(".struct_ops") (Andrii) - libbpf: Add bpf_map__attach_struct_ops() (Andrii) ==================== Signed-off-by: Alexei Starovoitov + Changed Files: nan + Parent Hashes: 65726b5b7efae718391752ae8bb85b9843fd83f4 09903869f69f37fd7a465183545b5739c6274654 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit merges changes that introduce BPF STRUCT_OPS to implement TCP congestion control algorithms in BPF.", + "keywords": "BPF, STRUCT_OPS, TCP", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "The commit merges changes that introduce BPF STRUCT_OPS for implementing TCP congestion control algorithms in BPF.", + "keywords": "BPF, STRUCT_OPS, TCP", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 745/6895 - Commit ID: 09903869f69f37fd7a465183545b5739c6274654 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 09903869f69f37fd7a465183545b5739c6274654 + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1578588378 + Commit Message: + bpf: Add bpf_dctcp example This patch adds a bpf_dctcp example. It currently does not do no-ECN fallback but the same could be done through the cgrp2-bpf. Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200109003517.3856825-1-kafai@fb.com + Changed Files: tools/testing/selftests/bpf/bpf_tcp_helpers.h | 228 +++++++++++++++++++++; .../testing/selftests/bpf/prog_tests/bpf_tcp_ca.c | 187 +++++++++++++++++; tools/testing/selftests/bpf/progs/bpf_dctcp.c | 210 +++++++++++++++++++; 3 files changed, 625 insertions(+) + Parent Hashes: 590a0088825016ca7ec53f1aef7e84e1211778d8 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds a bpf_dctcp example for self-testing in the bpf subsystem.", + "keywords": "bpf, dctcp, example", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups).", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds an example program demonstrating bpf_dctcp functionality for self-tests in the bpf subsystem.", + "keywords": "bpf, dctcp, example", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups).", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +-------------------- +-------------------- +Processing Commit 746/6895 - Commit ID: 590a0088825016ca7ec53f1aef7e84e1211778d8 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 590a0088825016ca7ec53f1aef7e84e1211778d8 + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1578588378 + Commit Message: + bpf: libbpf: Add STRUCT_OPS support This patch adds BPF STRUCT_OPS support to libbpf. The only sec_name convention is SEC(".struct_ops") to identify the struct_ops implemented in BPF, e.g. To implement a tcp_congestion_ops: SEC(".struct_ops") struct tcp_congestion_ops dctcp = { .init = (void *)dctcp_init, /* <-- a bpf_prog */ /* ... some more func prts ... */ .name = "bpf_dctcp", }; Each struct_ops is defined as a global variable under SEC(".struct_ops") as above. libbpf creates a map for each variable and the variable name is the map's name. Multiple struct_ops is supported under SEC(".struct_ops"). In the bpf_object__open phase, libbpf will look for the SEC(".struct_ops") section and find out what is the btf-type the struct_ops is implementing. Note that the btf-type here is referring to a type in the bpf_prog.o's btf. A "struct bpf_map" is added by bpf_object__add_map() as other maps do. It will then collect (through SHT_REL) where are the bpf progs that the func ptrs are referring to. No btf_vmlinux is needed in the open phase. In the bpf_object__load phase, the map-fields, which depend on the btf_vmlinux, are initialized (in bpf_map__init_kern_struct_ops()). It will also set the prog->type, prog->attach_btf_id, and prog->expected_attach_type. Thus, the prog's properties do not rely on its section name. [ Currently, the bpf_prog's btf-type ==> btf_vmlinux's btf-type matching process is as simple as: member-name match + btf-kind match + size match. If these matching conditions fail, libbpf will reject. The current targeting support is "struct tcp_congestion_ops" which most of its members are function pointers. The member ordering of the bpf_prog's btf-type can be different from the btf_vmlinux's btf-type. ] Then, all obj->maps are created as usual (in bpf_object__create_maps()). Once the maps are created and prog's properties are all set, the libbpf will proceed to load all the progs. bpf_map__attach_struct_ops() is added to register a struct_ops map to a kernel subsystem. Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200109003514.3856730-1-kafai@fb.com + Changed Files: tools/lib/bpf/bpf.c | 10 +-; tools/lib/bpf/bpf.h | 5 +-; tools/lib/bpf/libbpf.c | 649 +++++++++++++++++++++++++++++++++++++++++-; tools/lib/bpf/libbpf.h | 5 +-; tools/lib/bpf/libbpf.map | 3 +; tools/lib/bpf/libbpf_probes.c | 2 +; 6 files changed, 661 insertions(+), 13 deletions(-) + Parent Hashes: 17328d618c17e0c8deab892ac227efcd55957e4d +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit introduces STRUCT_OPS support to libbpf by adding functionality to handle struct_ops in BPF programs.", + "keywords": "STRUCT_OPS,libbpf,BPF", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems." + ] +} +Rethinking... +new content: +{ + "summary": "This commit introduces STRUCT_OPS support to libbpf by adding functionality to handle BPF program struct operations.", + "keywords": "STRUCT_OPS,libbpf,BPF", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems." + ] +} +-------------------- +-------------------- +Processing Commit 747/6895 - Commit ID: 17328d618c17e0c8deab892ac227efcd55957e4d +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 17328d618c17e0c8deab892ac227efcd55957e4d + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1578588378 + Commit Message: + bpf: Synch uapi bpf.h to tools/ This patch sync uapi bpf.h to tools/ Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200109003512.3856559-1-kafai@fb.com + Changed Files: tools/include/uapi/linux/bpf.h | 19 +++++++++++++++++--; 1 file changed, 17 insertions(+), 2 deletions(-) + Parent Hashes: 206057fe020ac5c037d5e2dd6562a9bd216ec765 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit synchronizes the uapi bpf.h file to the tools directory with 17 insertions and 2 deletions.", + "keywords": "synchronize,uapi,bpf.h", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit synchronizes the uapi bpf.h header file to the tools directory.", + "keywords": "synchronize,uapi,bpf", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 748/6895 - Commit ID: 206057fe020ac5c037d5e2dd6562a9bd216ec765 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 206057fe020ac5c037d5e2dd6562a9bd216ec765 + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1578588378 + Commit Message: + bpf: Add BPF_FUNC_tcp_send_ack helper Add a helper to send out a tcp-ack. It will be used in the later bpf_dctcp implementation that requires to send out an ack when the CE state changed. Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200109004551.3900448-1-kafai@fb.com + Changed Files: include/uapi/linux/bpf.h | 11 ++++++++++-; net/ipv4/bpf_tcp_ca.c | 24 +++++++++++++++++++++++-; 2 files changed, 33 insertions(+), 2 deletions(-) + Parent Hashes: 0baf26b0fcd74bbfcef53c5d5e8bad2b99c8d0d2 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Add a helper function BPF_FUNC_tcp_send_ack to send TCP acknowledgments, supporting future bpf_dctcp implementation.", + "keywords": "helper, tcp-ack, bpf_dctcp", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here." + ] +} +Rethinking... +new content: +{ + "summary": "Add a helper function BPF_FUNC_tcp_send_ack to send TCP acknowledgments, supporting future bpf_dctcp implementation.", + "keywords": "helper,tcp-ack,bpf_dctcp", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 749/6895 - Commit ID: 0baf26b0fcd74bbfcef53c5d5e8bad2b99c8d0d2 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 0baf26b0fcd74bbfcef53c5d5e8bad2b99c8d0d2 + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1578588378 + Commit Message: + bpf: tcp: Support tcp_congestion_ops in bpf This patch makes "struct tcp_congestion_ops" to be the first user of BPF STRUCT_OPS. It allows implementing a tcp_congestion_ops in bpf. The BPF implemented tcp_congestion_ops can be used like regular kernel tcp-cc through sysctl and setsockopt. e.g. [root@arch-fb-vm1 bpf]# sysctl -a | egrep congestion net.ipv4.tcp_allowed_congestion_control = reno cubic bpf_cubic net.ipv4.tcp_available_congestion_control = reno bic cubic bpf_cubic net.ipv4.tcp_congestion_control = bpf_cubic There has been attempt to move the TCP CC to the user space (e.g. CCP in TCP). The common arguments are faster turn around, get away from long-tail kernel versions in production...etc, which are legit points. BPF has been the continuous effort to join both kernel and userspace upsides together (e.g. XDP to gain the performance advantage without bypassing the kernel). The recent BPF advancements (in particular BTF-aware verifier, BPF trampoline, BPF CO-RE...) made implementing kernel struct ops (e.g. tcp cc) possible in BPF. It allows a faster turnaround for testing algorithm in the production while leveraging the existing (and continue growing) BPF feature/framework instead of building one specifically for userspace TCP CC. This patch allows write access to a few fields in tcp-sock (in bpf_tcp_ca_btf_struct_access()). The optional "get_info" is unsupported now. It can be added later. One possible way is to output the info with a btf-id to describe the content. Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200109003508.3856115-1-kafai@fb.com + Changed Files: include/linux/filter.h | 2 +; include/net/tcp.h | 2 +; kernel/bpf/bpf_struct_ops_types.h | 7 +-; net/core/filter.c | 2 +-; net/ipv4/Makefile | 4 +; net/ipv4/bpf_tcp_ca.c | 230 ++++++++++++++++++++++++++++++++++++++; net/ipv4/tcp_cong.c | 16 +--; net/ipv4/tcp_ipv4.c | 6 +-; net/ipv4/tcp_minisocks.c | 4 +-; net/ipv4/tcp_output.c | 4 +-; 10 files changed, 261 insertions(+), 16 deletions(-) + Parent Hashes: 85d33df357b634649ddbe0a20fd2d0fc5732c3cb +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit enables implementation of TCP congestion control operations using BPF STRUCT_OPS in the kernel, facilitating faster experimentation and integration with existing BPF infrastructure.", + "keywords": "tcp congestion bpf", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "tc related type programs. It affects programs managing traffic control (tc) for queuing or prioritizing network traffic.", + "Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit enables implementation of TCP congestion control operations using BPF in the kernel via STRUCT_OPS for faster integration and experimentation.", + "keywords": "tcp congestion bpf", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "tc related type programs. It affects programs managing traffic control (tc) for queuing or prioritizing network traffic.", + "Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 750/6895 - Commit ID: 85d33df357b634649ddbe0a20fd2d0fc5732c3cb +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 85d33df357b634649ddbe0a20fd2d0fc5732c3cb + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1578588378 + Commit Message: + bpf: Introduce BPF_MAP_TYPE_STRUCT_OPS The patch introduces BPF_MAP_TYPE_STRUCT_OPS. The map value is a kernel struct with its func ptr implemented in bpf prog. This new map is the interface to register/unregister/introspect a bpf implemented kernel struct. The kernel struct is actually embedded inside another new struct (or called the "value" struct in the code). For example, "struct tcp_congestion_ops" is embbeded in: struct bpf_struct_ops_tcp_congestion_ops { refcount_t refcnt; enum bpf_struct_ops_state state; struct tcp_congestion_ops data; /* <-- kernel subsystem struct here */ } The map value is "struct bpf_struct_ops_tcp_congestion_ops". The "bpftool map dump" will then be able to show the state ("inuse"/"tobefree") and the number of subsystem's refcnt (e.g. number of tcp_sock in the tcp_congestion_ops case). This "value" struct is created automatically by a macro. Having a separate "value" struct will also make extending "struct bpf_struct_ops_XYZ" easier (e.g. adding "void (*init)(void)" to "struct bpf_struct_ops_XYZ" to do some initialization works before registering the struct_ops to the kernel subsystem). The libbpf will take care of finding and populating the "struct bpf_struct_ops_XYZ" from "struct XYZ". Register a struct_ops to a kernel subsystem: 1. Load all needed BPF_PROG_TYPE_STRUCT_OPS prog(s) 2. Create a BPF_MAP_TYPE_STRUCT_OPS with attr->btf_vmlinux_value_type_id set to the btf id "struct bpf_struct_ops_tcp_congestion_ops" of the running kernel. Instead of reusing the attr->btf_value_type_id, btf_vmlinux_value_type_id s added such that attr->btf_fd can still be used as the "user" btf which could store other useful sysadmin/debug info that may be introduced in the furture, e.g. creation-date/compiler-details/map-creator...etc. 3. Create a "struct bpf_struct_ops_tcp_congestion_ops" object as described in the running kernel btf. Populate the value of this object. The function ptr should be populated with the prog fds. 4. Call BPF_MAP_UPDATE with the object created in (3) as the map value. The key is always "0". During BPF_MAP_UPDATE, the code that saves the kernel-func-ptr's args as an array of u64 is generated. BPF_MAP_UPDATE also allows the specific struct_ops to do some final checks in "st_ops->init_member()" (e.g. ensure all mandatory func ptrs are implemented). If everything looks good, it will register this kernel struct to the kernel subsystem. The map will not allow further update from this point. Unregister a struct_ops from the kernel subsystem: BPF_MAP_DELETE with key "0". Introspect a struct_ops: BPF_MAP_LOOKUP_ELEM with key "0". The map value returned will have the prog _id_ populated as the func ptr. The map value state (enum bpf_struct_ops_state) will transit from: INIT (map created) => INUSE (map updated, i.e. reg) => TOBEFREE (map value deleted, i.e. unreg) The kernel subsystem needs to call bpf_struct_ops_get() and bpf_struct_ops_put() to manage the "refcnt" in the "struct bpf_struct_ops_XYZ". This patch uses a separate refcnt for the purose of tracking the subsystem usage. Another approach is to reuse the map->refcnt and then "show" (i.e. during map_lookup) the subsystem's usage by doing map->refcnt - map->usercnt to filter out the map-fd/pinned-map usage. However, that will also tie down the future semantics of map->refcnt and map->usercnt. The very first subsystem's refcnt (during reg()) holds one count to map->refcnt. When the very last subsystem's refcnt is gone, it will also release the map->refcnt. All bpf_prog will be freed when the map->refcnt reaches 0 (i.e. during map_free()). Here is how the bpftool map command will look like: [root@arch-fb-vm1 bpf]# bpftool map show 6: struct_ops name dctcp flags 0x0 key 4B value 256B max_entries 1 memlock 4096B btf_id 6 [root@arch-fb-vm1 bpf]# bpftool map dump id 6 [{ "value": { "refcnt": { "refs": { "counter": 1 } }, "state": 1, "data": { "list": { "next": 0, "prev": 0 }, "key": 0, "flags": 2, "init": 24, "release": 0, "ssthresh": 25, "cong_avoid": 30, "set_state": 27, "cwnd_event": 28, "in_ack_event": 26, "undo_cwnd": 29, "pkts_acked": 0, "min_tso_segs": 0, "sndbuf_expand": 0, "cong_control": 0, "get_info": 0, "name": [98,112,102,95,100,99,116,99,112,0,0,0,0,0,0,0 ], "owner": 0 } } } ] Misc Notes: * bpf_struct_ops_map_sys_lookup_elem() is added for syscall lookup. It does an inplace update on "*value" instead returning a pointer to syscall.c. Otherwise, it needs a separate copy of "zero" value for the BPF_STRUCT_OPS_STATE_INIT to avoid races. * The bpf_struct_ops_map_delete_elem() is also called without preempt_disable() from map_delete_elem(). It is because the "->unreg()" may requires sleepable context, e.g. the "tcp_unregister_congestion_control()". * "const" is added to some of the existing "struct btf_func_model *" function arg to avoid a compiler warning caused by this patch. Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200109003505.3855919-1-kafai@fb.com + Changed Files: arch/x86/net/bpf_jit_comp.c | 18 +-; include/linux/bpf.h | 49 ++++-; include/linux/bpf_types.h | 3 +; include/linux/btf.h | 13 ++; include/uapi/linux/bpf.h | 7 +-; kernel/bpf/bpf_struct_ops.c | 511 +++++++++++++++++++++++++++++++++++++++++++-; kernel/bpf/btf.c | 20 +-; kernel/bpf/map_in_map.c | 3 +-; kernel/bpf/syscall.c | 52 +++--; kernel/bpf/trampoline.c | 8 +-; kernel/bpf/verifier.c | 5 +; 11 files changed, 642 insertions(+), 47 deletions(-) + Parent Hashes: 27ae7997a66174cb8afd6a75b3989f5e0c1b9e5a +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit introduces BPF_MAP_TYPE_STRUCT_OPS, enabling kernel struct registration and management via eBPF programs.", + "keywords": "BPF_MAP_TYPE_STRUCT_OPS, kernel struct, eBPF programs", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems." + ] +} +Rethinking... +new content: +{ + "summary": "This commit introduces BPF_MAP_TYPE_STRUCT_OPS for eBPF, facilitating struct operations integration with kernel subsystems.", + "keywords": "BPF_MAP_TYPE_STRUCT_OPS,kernel struct,eBPF", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems." + ] +} +-------------------- +-------------------- +Processing Commit 751/6895 - Commit ID: 27ae7997a66174cb8afd6a75b3989f5e0c1b9e5a +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 27ae7997a66174cb8afd6a75b3989f5e0c1b9e5a + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1578588378 + Commit Message: + bpf: Introduce BPF_PROG_TYPE_STRUCT_OPS This patch allows the kernel's struct ops (i.e. func ptr) to be implemented in BPF. The first use case in this series is the "struct tcp_congestion_ops" which will be introduced in a latter patch. This patch introduces a new prog type BPF_PROG_TYPE_STRUCT_OPS. The BPF_PROG_TYPE_STRUCT_OPS prog is verified against a particular func ptr of a kernel struct. The attr->attach_btf_id is the btf id of a kernel struct. The attr->expected_attach_type is the member "index" of that kernel struct. The first member of a struct starts with member index 0. That will avoid ambiguity when a kernel struct has multiple func ptrs with the same func signature. For example, a BPF_PROG_TYPE_STRUCT_OPS prog is written to implement the "init" func ptr of the "struct tcp_congestion_ops". The attr->attach_btf_id is the btf id of the "struct tcp_congestion_ops" of the _running_ kernel. The attr->expected_attach_type is 3. The ctx of BPF_PROG_TYPE_STRUCT_OPS is an array of u64 args saved by arch_prepare_bpf_trampoline that will be done in the next patch when introducing BPF_MAP_TYPE_STRUCT_OPS. "struct bpf_struct_ops" is introduced as a common interface for the kernel struct that supports BPF_PROG_TYPE_STRUCT_OPS prog. The supporting kernel struct will need to implement an instance of the "struct bpf_struct_ops". The supporting kernel struct also needs to implement a bpf_verifier_ops. During BPF_PROG_LOAD, bpf_struct_ops_find() will find the right bpf_verifier_ops by searching the attr->attach_btf_id. A new "btf_struct_access" is also added to the bpf_verifier_ops such that the supporting kernel struct can optionally provide its own specific check on accessing the func arg (e.g. provide limited write access). After btf_vmlinux is parsed, the new bpf_struct_ops_init() is called to initialize some values (e.g. the btf id of the supporting kernel struct) and it can only be done once the btf_vmlinux is available. The R0 checks at BPF_EXIT is excluded for the BPF_PROG_TYPE_STRUCT_OPS prog if the return type of the prog->aux->attach_func_proto is "void". Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200109003503.3855825-1-kafai@fb.com + Changed Files: include/linux/bpf.h | 30 +++++++++; include/linux/bpf_types.h | 4 ++; include/linux/btf.h | 34 ++++++++++; include/uapi/linux/bpf.h | 1 +; kernel/bpf/Makefile | 3 +; kernel/bpf/bpf_struct_ops.c | 121 ++++++++++++++++++++++++++++++++++; kernel/bpf/bpf_struct_ops_types.h | 4 ++; kernel/bpf/btf.c | 88 +++++++++++++++++--------; kernel/bpf/syscall.c | 17 +++--; kernel/bpf/verifier.c | 134 +++++++++++++++++++++++++++++---------; 10 files changed, 373 insertions(+), 63 deletions(-) + Parent Hashes: 976aba002fcb4b1baa71e4b0854f3d4ae48c1d4d +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit introduces a new eBPF program type, BPF_PROG_TYPE_STRUCT_OPS, allowing struct operation implementations in BPF.", + "keywords": "BPF,struct_ops,program", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems." + ] +} +Rethinking... +new content: +{ + "summary": "This commit introduces a new eBPF program type, BPF_PROG_TYPE_STRUCT_OPS, allowing struct operation implementations in BPF.", + "keywords": "BPF,struct_ops,program", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The helper and kfuncs. It modifies or adds helpers and kernel functions that eBPF programs can call.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "Struct_ops type related programs. It affects programs tha t allows user-defined methods to be called by subsystems." + ] +} +-------------------- +-------------------- +Processing Commit 752/6895 - Commit ID: 976aba002fcb4b1baa71e4b0854f3d4ae48c1d4d +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 976aba002fcb4b1baa71e4b0854f3d4ae48c1d4d + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1578588378 + Commit Message: + bpf: Support bitfield read access in btf_struct_access This patch allows bitfield access as a scalar. It checks "off + size > t->size" to avoid accessing bitfield end up accessing beyond the struct. This check is done outside of the loop since it is applicable to all access. It also takes this chance to break early on the "off < moff" case. Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200109003501.3855427-1-kafai@fb.com + Changed Files: kernel/bpf/btf.c | 44 +++++++++++++++++++++++++++++++++++++++-----; 1 file changed, 39 insertions(+), 5 deletions(-) + Parent Hashes: 218b3f65f9081f5e1bffe6de5f0f4b22c935410b +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds support for bitfield read access in btf_struct_access within the BPF subsystem.", + "keywords": "bitfield, access, btf", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds support for bitfield read access in btf_struct_access within the BPF subsystem.", + "keywords": "bitfield, access, btf", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 753/6895 - Commit ID: 218b3f65f9081f5e1bffe6de5f0f4b22c935410b +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 218b3f65f9081f5e1bffe6de5f0f4b22c935410b + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1578588378 + Commit Message: + bpf: Add enum support to btf_ctx_access() It allows bpf prog (e.g. tracing) to attach to a kernel function that takes enum argument. Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200109003459.3855366-1-kafai@fb.com + Changed Files: kernel/bpf/btf.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: 275517ff452a535da5eef25b1c22e53fc50b0a12 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds enum support to btf_ctx_access for bpf programs to attach to kernel functions with enum arguments.", + "keywords": "bpf, enum, btf_ctx_access", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds enum support to btf_ctx_access for bpf programs to attach to kernel functions with enum arguments.", + "keywords": "bpf, enum, btf_ctx_access", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing." + ] +} +-------------------- +-------------------- +Processing Commit 754/6895 - Commit ID: 275517ff452a535da5eef25b1c22e53fc50b0a12 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 275517ff452a535da5eef25b1c22e53fc50b0a12 + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1578588378 + Commit Message: + bpf: Avoid storing modifier to info->btf_id info->btf_id expects the btf_id of a struct, so it should store the final result after skipping modifiers (if any). It also takes this chanace to add a missing newline in one of the bpf_log() messages. Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200109003456.3855176-1-kafai@fb.com + Changed Files: kernel/bpf/btf.c | 9 ++++++---; 1 file changed, 6 insertions(+), 3 deletions(-) + Parent Hashes: 65726b5b7efae718391752ae8bb85b9843fd83f4 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit fixes the storage of struct type BTF IDs by skipping modifiers and correcting a log message format.", + "keywords": "modifier, btf_id, fix", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit corrects the storage of BTF IDs by skipping modifiers and fixes a log message formatting issue.", + "keywords": "btf_id, modifier, fix", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 755/6895 - Commit ID: 65726b5b7efae718391752ae8bb85b9843fd83f4 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 65726b5b7efae718391752ae8bb85b9843fd83f4 + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1578588332 + Commit Message: + bpf: Save PTR_TO_BTF_ID register state when spilling to stack This patch makes the verifier save the PTR_TO_BTF_ID register state when spilling to the stack. Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200109003454.3854870-1-kafai@fb.com + Changed Files: kernel/bpf/verifier.c | 1 +; 1 file changed, 1 insertion(+) + Parent Hashes: e43002242a47e8d7b2f9446f54de982f09e7dbd1 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit updates the eBPF verifier to save PTR_TO_BTF_ID register state when spilling to the stack.", + "keywords": "verifier,PTR_TO_BTF_ID,stack", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit updates the eBPF verifier to save PTR_TO_BTF_ID register state when spilling to the stack.", + "keywords": "verifier,PTR_TO_BTF_ID,stack", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 756/6895 - Commit ID: e43002242a47e8d7b2f9446f54de982f09e7dbd1 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: e43002242a47e8d7b2f9446f54de982f09e7dbd1 + Author Name: Stanislav Fomichev + Author Email: sdf@google.com + Commit Date: 1578588127 + Commit Message: + selftests/bpf: Restore original comm in test_overhead test_overhead changes task comm in order to estimate BPF trampoline overhead but never sets the comm back to the original one. We have the tests (like core_reloc.c) that have 'test_progs' as hard-coded expected comm, so let's try to preserve the original comm. Currently, everything works because the order of execution is: first core_recloc, then test_overhead; but let's make it a bit future-proof. Other related changes: use 'test_overhead' as new comm instead of 'test' to make it easy to debug and drop '\n' at the end. Signed-off-by: Stanislav Fomichev Signed-off-by: Alexei Starovoitov Acked-by: Petar Penkov Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200108192132.189221-1-sdf@google.com + Changed Files: tools/testing/selftests/bpf/prog_tests/test_overhead.c | 8 +++++++-; 1 file changed, 7 insertions(+), 1 deletion(-) + Parent Hashes: 2faef64aa6b3c94c940c3a62ed22f3af4980223a +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit restores the original task comm in test_overhead for future-proofing test cases.", + "keywords": "test,comm,overhead", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes the task comm restoration in test_overhead to ensure test consistency.", + "keywords": "comm,test,overhead", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 757/6895 - Commit ID: 2faef64aa6b3c94c940c3a62ed22f3af4980223a +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 2faef64aa6b3c94c940c3a62ed22f3af4980223a + Author Name: Michal Rostecki + Author Email: mrostecki@opensuse.org + Commit Date: 1578508485 + Commit Message: + bpftool: Add misc section and probe for large INSN limit Introduce a new probe section (misc) for probes not related to concrete map types, program types, functions or kernel configuration. Introduce a probe for large INSN limit as the first one in that section. Example outputs: # bpftool feature probe [...] Scanning miscellaneous eBPF features... Large program size limit is available # bpftool feature probe macros [...] /*** eBPF misc features ***/ #define HAVE_HAVE_LARGE_INSN_LIMIT # bpftool feature probe -j | jq '.["misc"]' { "have_large_insn_limit": true } Signed-off-by: Michal Rostecki Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200108162428.25014-3-mrostecki@opensuse.org + Changed Files: tools/bpf/bpftool/feature.c | 18 ++++++++++++++++++; 1 file changed, 18 insertions(+) + Parent Hashes: 5ff051200308ab6f4c64c0fe52187bf4a1234dac +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds a new probe for large instruction limits in the bpftool's miscellaneous section.", + "keywords": "bpftool,probe,insn", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds a new probe for large instruction limits in the bpftool's miscellaneous section.", + "keywords": "bpftool,probe,insn", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 758/6895 - Commit ID: 5ff051200308ab6f4c64c0fe52187bf4a1234dac +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 5ff051200308ab6f4c64c0fe52187bf4a1234dac + Author Name: Michal Rostecki + Author Email: mrostecki@opensuse.org + Commit Date: 1578508295 + Commit Message: + libbpf: Add probe for large INSN limit Introduce a new probe which checks whether kernel has large maximum program size which was increased in the following commit: c04c0d2b968a ("bpf: increase complexity limit and maximum program size") Based on the similar check in Cilium[0], authored by Daniel Borkmann. [0] https://github.com/cilium/cilium/commit/657d0f585afd26232cfa5d4e70b6f64d2ea91596 Co-authored-by: Daniel Borkmann Signed-off-by: Michal Rostecki Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20200108162428.25014-2-mrostecki@opensuse.org + Changed Files: tools/lib/bpf/libbpf.h | 1 +; tools/lib/bpf/libbpf.map | 1 +; tools/lib/bpf/libbpf_probes.c | 21 +++++++++++++++++++++; 3 files changed, 23 insertions(+) + Parent Hashes: 1ece2fbe9b427d379455f18a874bcd3ab86a2419 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds a probe in libbpf to check for large maximum program size support in the kernel.", + "keywords": "libbpf,probe,INSN", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds a probe in libbpf to check for large maximum program size support in the kernel.", + "keywords": "libbpf,probe,INSN", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 759/6895 - Commit ID: 96b11e9358080e8b705babd078cefa753109204b +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 96b11e9358080e8b705babd078cefa753109204b + Author Name: David S. Miller + Author Email: davem@davemloft.net + Commit Date: 1578432683 + Commit Message: + Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf Daniel Borkmann says: ==================== pull-request: bpf 2020-01-07 The following pull-request contains BPF updates for your *net* tree. We've added 2 non-merge commits during the last 1 day(s) which contain a total of 2 files changed, 16 insertions(+), 4 deletions(-). The main changes are: 1) Fix a use-after-free in cgroup BPF due to auto-detachment, from Roman Gushchin. 2) Fix skb out-of-bounds access in ld_abs/ind instruction, from Daniel Borkmann. ==================== Signed-off-by: David S. Miller + Changed Files: nan + Parent Hashes: 481a7d154cbbd5ca355cc01cc8969876b240eded 6d4f151acf9a4f6fab09b615f246c717ddedcf0c +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit merges BPF updates into the net tree, fixing a use-after-free and an skb out-of-bounds access.", + "keywords": "use-after-free,merge,fix", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups).", + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here.", + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "The commit merges BPF updates into the net tree, fixing a use-after-free and an skb out-of-bounds access.", + "keywords": "use-after-free,merge,fix", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups).", + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here.", + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 760/6895 - Commit ID: 6d4f151acf9a4f6fab09b615f246c717ddedcf0c +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 6d4f151acf9a4f6fab09b615f246c717ddedcf0c + Author Name: Daniel Borkmann + Author Email: daniel@iogearbox.net + Commit Date: 1578349187 + Commit Message: + bpf: Fix passing modified ctx to ld/abs/ind instruction Anatoly has been fuzzing with kBdysch harness and reported a KASAN slab oob in one of the outcomes: [...] [ 77.359642] BUG: KASAN: slab-out-of-bounds in bpf_skb_load_helper_8_no_cache+0x71/0x130 [ 77.360463] Read of size 4 at addr ffff8880679bac68 by task bpf/406 [ 77.361119] [ 77.361289] CPU: 2 PID: 406 Comm: bpf Not tainted 5.5.0-rc2-xfstests-00157-g2187f215eba #1 [ 77.362134] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 [ 77.362984] Call Trace: [ 77.363249] dump_stack+0x97/0xe0 [ 77.363603] print_address_description.constprop.0+0x1d/0x220 [ 77.364251] ? bpf_skb_load_helper_8_no_cache+0x71/0x130 [ 77.365030] ? bpf_skb_load_helper_8_no_cache+0x71/0x130 [ 77.365860] __kasan_report.cold+0x37/0x7b [ 77.366365] ? bpf_skb_load_helper_8_no_cache+0x71/0x130 [ 77.366940] kasan_report+0xe/0x20 [ 77.367295] bpf_skb_load_helper_8_no_cache+0x71/0x130 [ 77.367821] ? bpf_skb_load_helper_8+0xf0/0xf0 [ 77.368278] ? mark_lock+0xa3/0x9b0 [ 77.368641] ? kvm_sched_clock_read+0x14/0x30 [ 77.369096] ? sched_clock+0x5/0x10 [ 77.369460] ? sched_clock_cpu+0x18/0x110 [ 77.369876] ? bpf_skb_load_helper_8+0xf0/0xf0 [ 77.370330] ___bpf_prog_run+0x16c0/0x28f0 [ 77.370755] __bpf_prog_run32+0x83/0xc0 [ 77.371153] ? __bpf_prog_run64+0xc0/0xc0 [ 77.371568] ? match_held_lock+0x1b/0x230 [ 77.371984] ? rcu_read_lock_held+0xa1/0xb0 [ 77.372416] ? rcu_is_watching+0x34/0x50 [ 77.372826] sk_filter_trim_cap+0x17c/0x4d0 [ 77.373259] ? sock_kzfree_s+0x40/0x40 [ 77.373648] ? __get_filter+0x150/0x150 [ 77.374059] ? skb_copy_datagram_from_iter+0x80/0x280 [ 77.374581] ? do_raw_spin_unlock+0xa5/0x140 [ 77.375025] unix_dgram_sendmsg+0x33a/0xa70 [ 77.375459] ? do_raw_spin_lock+0x1d0/0x1d0 [ 77.375893] ? unix_peer_get+0xa0/0xa0 [ 77.376287] ? __fget_light+0xa4/0xf0 [ 77.376670] __sys_sendto+0x265/0x280 [ 77.377056] ? __ia32_sys_getpeername+0x50/0x50 [ 77.377523] ? lock_downgrade+0x350/0x350 [ 77.377940] ? __sys_setsockopt+0x2a6/0x2c0 [ 77.378374] ? sock_read_iter+0x240/0x240 [ 77.378789] ? __sys_socketpair+0x22a/0x300 [ 77.379221] ? __ia32_sys_socket+0x50/0x50 [ 77.379649] ? mark_held_locks+0x1d/0x90 [ 77.380059] ? trace_hardirqs_on_thunk+0x1a/0x1c [ 77.380536] __x64_sys_sendto+0x74/0x90 [ 77.380938] do_syscall_64+0x68/0x2a0 [ 77.381324] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 77.381878] RIP: 0033:0x44c070 [...] After further debugging, turns out while in case of other helper functions we disallow passing modified ctx, the special case of ld/abs/ind instruction which has similar semantics (except r6 being the ctx argument) is missing such check. Modified ctx is impossible here as bpf_skb_load_helper_8_no_cache() and others are expecting skb fields in original position, hence, add check_ctx_reg() to reject any modified ctx. Issue was first introduced back in f1174f77b50c ("bpf/verifier: rework value tracking"). Fixes: f1174f77b50c ("bpf/verifier: rework value tracking") Reported-by: Anatoly Trosinenko Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200106215157.3553-1-daniel@iogearbox.net + Changed Files: kernel/bpf/verifier.c | 9 +++++++--; 1 file changed, 7 insertions(+), 2 deletions(-) + Parent Hashes: e10360f815ca6367357b2c2cfef17fc663e50f7b +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes a bug where modified ctx was incorrectly allowed for ld/abs/ind instructions in eBPF verifier, causing KASAN slab out-of-bounds error.", + "keywords": "bugfix,verifier,KASAN", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes a bug where modified ctx was incorrectly allowed for ld/abs/ind instructions in eBPF verifier, causing KASAN slab out-of-bounds error.", + "keywords": "bugfix,verifier,KASAN", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 761/6895 - Commit ID: e10360f815ca6367357b2c2cfef17fc663e50f7b +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: e10360f815ca6367357b2c2cfef17fc663e50f7b + Author Name: Roman Gushchin + Author Email: guro@fb.com + Commit Date: 1578348030 + Commit Message: + bpf: cgroup: prevent out-of-order release of cgroup bpf Before commit 4bfc0bb2c60e ("bpf: decouple the lifetime of cgroup_bpf from cgroup itself") cgroup bpf structures were released with corresponding cgroup structures. It guaranteed the hierarchical order of destruction: children were always first. It preserved attached programs from being released before their propagated copies. But with cgroup auto-detachment there are no such guarantees anymore: cgroup bpf is released as soon as the cgroup is offline and there are no live associated sockets. It means that an attached program can be detached and released, while its propagated copy is still living in the cgroup subtree. This will obviously lead to an use-after-free bug. To reproduce the issue the following script can be used: #!/bin/bash CGROOT=/sys/fs/cgroup mkdir -p ${CGROOT}/A ${CGROOT}/B ${CGROOT}/A/C sleep 1 ./test_cgrp2_attach ${CGROOT}/A egress & A_PID=$! ./test_cgrp2_attach ${CGROOT}/B egress & B_PID=$! echo $$ > ${CGROOT}/A/C/cgroup.procs iperf -s & S_PID=$! iperf -c localhost -t 100 & C_PID=$! sleep 1 echo $$ > ${CGROOT}/B/cgroup.procs echo ${S_PID} > ${CGROOT}/B/cgroup.procs echo ${C_PID} > ${CGROOT}/B/cgroup.procs sleep 1 rmdir ${CGROOT}/A/C rmdir ${CGROOT}/A sleep 1 kill -9 ${S_PID} ${C_PID} ${A_PID} ${B_PID} On the unpatched kernel the following stacktrace can be obtained: [ 33.619799] BUG: unable to handle page fault for address: ffffbdb4801ab002 [ 33.620677] #PF: supervisor read access in kernel mode [ 33.621293] #PF: error_code(0x0000) - not-present page [ 33.622754] Oops: 0000 [#1] SMP NOPTI [ 33.623202] CPU: 0 PID: 601 Comm: iperf Not tainted 5.5.0-rc2+ #23 [ 33.625545] RIP: 0010:__cgroup_bpf_run_filter_skb+0x29f/0x3d0 [ 33.635809] Call Trace: [ 33.636118] ? __cgroup_bpf_run_filter_skb+0x2bf/0x3d0 [ 33.636728] ? __switch_to_asm+0x40/0x70 [ 33.637196] ip_finish_output+0x68/0xa0 [ 33.637654] ip_output+0x76/0xf0 [ 33.638046] ? __ip_finish_output+0x1c0/0x1c0 [ 33.638576] __ip_queue_xmit+0x157/0x410 [ 33.639049] __tcp_transmit_skb+0x535/0xaf0 [ 33.639557] tcp_write_xmit+0x378/0x1190 [ 33.640049] ? _copy_from_iter_full+0x8d/0x260 [ 33.640592] tcp_sendmsg_locked+0x2a2/0xdc0 [ 33.641098] ? sock_has_perm+0x10/0xa0 [ 33.641574] tcp_sendmsg+0x28/0x40 [ 33.641985] sock_sendmsg+0x57/0x60 [ 33.642411] sock_write_iter+0x97/0x100 [ 33.642876] new_sync_write+0x1b6/0x1d0 [ 33.643339] vfs_write+0xb6/0x1a0 [ 33.643752] ksys_write+0xa7/0xe0 [ 33.644156] do_syscall_64+0x5b/0x1b0 [ 33.644605] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fix this by grabbing a reference to the bpf structure of each ancestor on the initialization of the cgroup bpf structure, and dropping the reference at the end of releasing the cgroup bpf structure. This will restore the hierarchical order of cgroup bpf releasing, without adding any operations on hot paths. Thanks to Josef Bacik for the debugging and the initial analysis of the problem. Fixes: 4bfc0bb2c60e ("bpf: decouple the lifetime of cgroup_bpf from cgroup itself") Reported-by: Josef Bacik Signed-off-by: Roman Gushchin Acked-by: Song Liu Signed-off-by: Alexei Starovoitov + Changed Files: kernel/bpf/cgroup.c | 11 +++++++++--; 1 file changed, 9 insertions(+), 2 deletions(-) + Parent Hashes: 4012a6f2fa562b4b2884ea96db263caa4c6057a8 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit prevents out-of-order release of cgroup bpf structures to fix a use-after-free bug by restoring destruction hierarchy.", + "keywords": "cgroup,bpf,bug", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups)." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes an issue causing out-of-order release of cgroup bpf structures that led to a use-after-free bug.", + "keywords": "cgroup,bpf,bug", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups)." + ] +} +-------------------- +-------------------- +Processing Commit 762/6895 - Commit ID: 6794200fa3c9c3e6759dae099145f23e4310f4f7 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 6794200fa3c9c3e6759dae099145f23e4310f4f7 + Author Name: Andrey Zhizhikin + Author Email: andrey.z@gmail.com + Commit Date: 1578321969 + Commit Message: + tools lib api fs: Fix gcc9 stringop-truncation compilation error GCC9 introduced string hardening mechanisms, which exhibits the error during fs api compilation: error: '__builtin_strncpy' specified bound 4096 equals destination size [-Werror=stringop-truncation] This comes when the length of copy passed to strncpy is is equal to destination size, which could potentially lead to buffer overflow. There is a need to mitigate this potential issue by limiting the size of destination by 1 and explicitly terminate the destination with NULL. Signed-off-by: Andrey Zhizhikin Reviewed-by: Petr Mladek Acked-by: Jiri Olsa Cc: Alexei Starovoitov Cc: Andrii Nakryiko Cc: Daniel Borkmann Cc: Kefeng Wang Cc: Martin KaFai Lau Cc: Petr Mladek Cc: Sergey Senozhatsky Cc: Song Liu Cc: Yonghong Song Cc: bpf@vger.kernel.org Cc: netdev@vger.kernel.org Link: http://lore.kernel.org/lkml/20191211080109.18765-1-andrey.zhizhikin@leica-geosystems.com Signed-off-by: Arnaldo Carvalho de Melo + Changed Files: tools/lib/api/fs/fs.c | 4 +++-; 1 file changed, 3 insertions(+), 1 deletion(-) + Parent Hashes: 81de3bf37a8bf58ecdbef608d16ddb0f4bbb71ca +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fix gcc9 stringop-truncation error by adjusting string copy operations to prevent buffer overflow in lib api fs.", + "keywords": "gcc9,stringop-truncation,buffer overflow", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +Rethinking... +new content: +{ + "summary": "Fix gcc9 stringop-truncation error in tools lib api fs by modifying string copy to prevent buffer overflow.", + "keywords": "gcc9,stringop-truncation,fs", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +-------------------- +-------------------- +Processing Commit 763/6895 - Commit ID: 31d518f35e1a80268a24a855be9477eb458540ad +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 31d518f35e1a80268a24a855be9477eb458540ad + Author Name: David S. Miller + Author Email: davem@davemloft.net + Commit Date: 1577828233 + Commit Message: + Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Simple overlapping changes in bpf land wrt. bpf_helper_defs.h handling. Signed-off-by: David S. Miller + Changed Files: nan + Parent Hashes: 9e860947d8d7a1504476ac49abfce90a4ce600f3 738d2902773e30939a982c8df7a7f94293659810 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "A merge commit addressing overlapping changes related to the handling of bpf_helper_defs.h.", + "keywords": "merge, bpf, changes", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "A merge commit addressing overlapping changes related to bpf_helper_defs.h handling.", + "keywords": "merge, bpf, changes", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 764/6895 - Commit ID: 738d2902773e30939a982c8df7a7f94293659810 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 738d2902773e30939a982c8df7a7f94293659810 + Author Name: Linus Torvalds + Author Email: torvalds@linux-foundation.org + Commit Date: 1577819698 + Commit Message: + Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from David Miller: 1) Fix big endian overflow in nf_flow_table, from Arnd Bergmann. 2) Fix port selection on big endian in nft_tproxy, from Phil Sutter. 3) Fix precision tracking for unbound scalars in bpf verifier, from Daniel Borkmann. 4) Fix integer overflow in socket rcvbuf check in UDP, from Antonio Messina. 5) Do not perform a neigh confirmation during a pmtu update over a tunnel, from Hangbin Liu. 6) Fix DMA mapping leak in dpaa_eth driver, from Madalin Bucur. 7) Various PTP fixes for sja1105 dsa driver, from Vladimir Oltean. 8) Add missing to dummy definition of of_mdiobus_child_is_phy(), from Geert Uytterhoeven * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (54 commits) hsr: fix slab-out-of-bounds Read in hsr_debugfs_rename() net/sched: add delete_empty() to filters and use it in cls_flower tcp: Fix highest_sack and highest_sack_seq ptp: fix the race between the release of ptp_clock and cdev net: dsa: sja1105: Reconcile the meaning of TPID and TPID2 for E/T and P/Q/R/S Documentation: net: dsa: sja1105: Remove text about taprio base-time limitation net: dsa: sja1105: Remove restriction of zero base-time for taprio offload net: dsa: sja1105: Really make the PTP command read-write net: dsa: sja1105: Take PTP egress timestamp by port, not mgmt slot cxgb4/cxgb4vf: fix flow control display for auto negotiation mlxsw: spectrum: Use dedicated policer for VRRP packets mlxsw: spectrum_router: Skip loopback RIFs during MAC validation net: stmmac: dwmac-meson8b: Fix the RGMII TX delay on Meson8b/8m2 SoCs net/sched: act_mirred: Pull mac prior redir to non mac_header_xmit device net_sched: sch_fq: properly set sk->sk_pacing_status bnx2x: Fix accounting of vlan resources among the PFs bnx2x: Use appropriate define for vlan credit of: mdio: Add missing inline to of_mdiobus_child_is_phy() dummy net: phy: aquantia: add suspend / resume ops for AQR105 dpaa_eth: fix DMA mapping leak ... + Changed Files: nan + Parent Hashes: c5c928c667cd1e34cbcac6af5b7c2f9f4512d612 04b69426d846cd04ca9acefff1ea39e1c64d2714 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This is a merge commit pulling networking fixes from David Miller's repository into Linus Torvalds' branch.", + "keywords": "merge,networking,fixes", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges various networking fixes from David Miller's repository into the mainline kernel.", + "keywords": "merge,networking,fixes", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 765/6895 - Commit ID: 04b69426d846cd04ca9acefff1ea39e1c64d2714 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 04b69426d846cd04ca9acefff1ea39e1c64d2714 + Author Name: Taehee Yoo + Author Email: ap420073@gmail.com + Commit Date: 1577766987 + Commit Message: + hsr: fix slab-out-of-bounds Read in hsr_debugfs_rename() hsr slave interfaces don't have debugfs directory. So, hsr_debugfs_rename() shouldn't be called when hsr slave interface name is changed. Test commands: ip link add dummy0 type dummy ip link add dummy1 type dummy ip link add hsr0 type hsr slave1 dummy0 slave2 dummy1 ip link set dummy0 name ap Splat looks like: [21071.899367][T22666] ap: renamed from dummy0 [21071.914005][T22666] ================================================================== [21071.919008][T22666] BUG: KASAN: slab-out-of-bounds in hsr_debugfs_rename+0xaa/0xb0 [hsr] [21071.923640][T22666] Read of size 8 at addr ffff88805febcd98 by task ip/22666 [21071.926941][T22666] [21071.927750][T22666] CPU: 0 PID: 22666 Comm: ip Not tainted 5.5.0-rc2+ #240 [21071.929919][T22666] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [21071.935094][T22666] Call Trace: [21071.935867][T22666] dump_stack+0x96/0xdb [21071.936687][T22666] ? hsr_debugfs_rename+0xaa/0xb0 [hsr] [21071.937774][T22666] print_address_description.constprop.5+0x1be/0x360 [21071.939019][T22666] ? hsr_debugfs_rename+0xaa/0xb0 [hsr] [21071.940081][T22666] ? hsr_debugfs_rename+0xaa/0xb0 [hsr] [21071.940949][T22666] __kasan_report+0x12a/0x16f [21071.941758][T22666] ? hsr_debugfs_rename+0xaa/0xb0 [hsr] [21071.942674][T22666] kasan_report+0xe/0x20 [21071.943325][T22666] hsr_debugfs_rename+0xaa/0xb0 [hsr] [21071.944187][T22666] hsr_netdev_notify+0x1fe/0x9b0 [hsr] [21071.945052][T22666] ? __module_text_address+0x13/0x140 [21071.945897][T22666] notifier_call_chain+0x90/0x160 [21071.946743][T22666] dev_change_name+0x419/0x840 [21071.947496][T22666] ? __read_once_size_nocheck.constprop.6+0x10/0x10 [21071.948600][T22666] ? netdev_adjacent_rename_links+0x280/0x280 [21071.949577][T22666] ? __read_once_size_nocheck.constprop.6+0x10/0x10 [21071.950672][T22666] ? lock_downgrade+0x6e0/0x6e0 [21071.951345][T22666] ? do_setlink+0x811/0x2ef0 [21071.951991][T22666] do_setlink+0x811/0x2ef0 [21071.952613][T22666] ? is_bpf_text_address+0x81/0xe0 [ ... ] Reported-by: syzbot+9328206518f08318a5fd@syzkaller.appspotmail.com Fixes: 4c2d5e33dcd3 ("hsr: rename debugfs file when interface name is changed") Signed-off-by: Taehee Yoo Signed-off-by: David S. Miller + Changed Files: net/hsr/hsr_main.c | 3 ++-; 1 file changed, 2 insertions(+), 1 deletion(-) + Parent Hashes: a5b72a083da197b493c7ed1e5730d62d3199f7d6 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes a slab-out-of-bounds read issue in hsr_debugfs_rename function by avoiding its call for hsr slave interfaces.", + "keywords": "fix, slab-out-of-bounds, hsr_debugfs_rename", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes a slab-out-of-bounds read issue in hsr_debugfs_rename function by avoiding its call for hsr slave interfaces.", + "keywords": "fix, slab-out-of-bounds, hsr", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +-------------------- +-------------------- +Processing Commit 766/6895 - Commit ID: 2bbc078f812d45b8decb55935dab21199bd21489 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 2bbc078f812d45b8decb55935dab21199bd21489 + Author Name: David S. Miller + Author Email: davem@davemloft.net + Commit Date: 1577485210 + Commit Message: + Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next Daniel Borkmann says: ==================== pull-request: bpf-next 2019-12-27 The following pull-request contains BPF updates for your *net-next* tree. We've added 127 non-merge commits during the last 17 day(s) which contain a total of 110 files changed, 6901 insertions(+), 2721 deletions(-). There are three merge conflicts. Conflicts and resolution looks as follows: 1) Merge conflict in net/bpf/test_run.c: There was a tree-wide cleanup c593642c8be0 ("treewide: Use sizeof_field() macro") which gets in the way with b590cb5f802d ("bpf: Switch to offsetofend in BPF_PROG_TEST_RUN"): <<<<<<< HEAD if (!range_is_zero(__skb, offsetof(struct __sk_buff, priority) + sizeof_field(struct __sk_buff, priority), ======= if (!range_is_zero(__skb, offsetofend(struct __sk_buff, priority), >>>>>>> 7c8dce4b166113743adad131b5a24c4acc12f92c There are a few occasions that look similar to this. Always take the chunk with offsetofend(). Note that there is one where the fields differ in here: <<<<<<< HEAD if (!range_is_zero(__skb, offsetof(struct __sk_buff, tstamp) + sizeof_field(struct __sk_buff, tstamp), ======= if (!range_is_zero(__skb, offsetofend(struct __sk_buff, gso_segs), >>>>>>> 7c8dce4b166113743adad131b5a24c4acc12f92c Just take the one with offsetofend() /and/ gso_segs. Latter is correct due to 850a88cc4096 ("bpf: Expose __sk_buff wire_len/gso_segs to BPF_PROG_TEST_RUN"). 2) Merge conflict in arch/riscv/net/bpf_jit_comp.c: (I'm keeping Bjorn in Cc here for a double-check in case I got it wrong.) <<<<<<< HEAD if (is_13b_check(off, insn)) return -1; emit(rv_blt(tcc, RV_REG_ZERO, off >> 1), ctx); ======= emit_branch(BPF_JSLT, RV_REG_T1, RV_REG_ZERO, off, ctx); >>>>>>> 7c8dce4b166113743adad131b5a24c4acc12f92c Result should look like: emit_branch(BPF_JSLT, tcc, RV_REG_ZERO, off, ctx); 3) Merge conflict in arch/riscv/include/asm/pgtable.h: <<<<<<< HEAD ======= #define VMALLOC_SIZE (KERN_VIRT_SIZE >> 1) #define VMALLOC_END (PAGE_OFFSET - 1) #define VMALLOC_START (PAGE_OFFSET - VMALLOC_SIZE) #define BPF_JIT_REGION_SIZE (SZ_128M) #define BPF_JIT_REGION_START (PAGE_OFFSET - BPF_JIT_REGION_SIZE) #define BPF_JIT_REGION_END (VMALLOC_END) /* * Roughly size the vmemmap space to be large enough to fit enough * struct pages to map half the virtual address space. Then * position vmemmap directly below the VMALLOC region. */ #define VMEMMAP_SHIFT \ (CONFIG_VA_BITS - PAGE_SHIFT - 1 + STRUCT_PAGE_MAX_SHIFT) #define VMEMMAP_SIZE BIT(VMEMMAP_SHIFT) #define VMEMMAP_END (VMALLOC_START - 1) #define VMEMMAP_START (VMALLOC_START - VMEMMAP_SIZE) #define vmemmap ((struct page *)VMEMMAP_START) >>>>>>> 7c8dce4b166113743adad131b5a24c4acc12f92c Only take the BPF_* defines from there and move them higher up in the same file. Remove the rest from the chunk. The VMALLOC_* etc defines got moved via 01f52e16b868 ("riscv: define vmemmap before pfn_to_page calls"). Result: [...] #define __S101 PAGE_READ_EXEC #define __S110 PAGE_SHARED_EXEC #define __S111 PAGE_SHARED_EXEC #define VMALLOC_SIZE (KERN_VIRT_SIZE >> 1) #define VMALLOC_END (PAGE_OFFSET - 1) #define VMALLOC_START (PAGE_OFFSET - VMALLOC_SIZE) #define BPF_JIT_REGION_SIZE (SZ_128M) #define BPF_JIT_REGION_START (PAGE_OFFSET - BPF_JIT_REGION_SIZE) #define BPF_JIT_REGION_END (VMALLOC_END) /* * Roughly size the vmemmap space to be large enough to fit enough * struct pages to map half the virtual address space. Then * position vmemmap directly below the VMALLOC region. */ #define VMEMMAP_SHIFT \ (CONFIG_VA_BITS - PAGE_SHIFT - 1 + STRUCT_PAGE_MAX_SHIFT) #define VMEMMAP_SIZE BIT(VMEMMAP_SHIFT) #define VMEMMAP_END (VMALLOC_START - 1) #define VMEMMAP_START (VMALLOC_START - VMEMMAP_SIZE) [...] Let me know if there are any other issues. Anyway, the main changes are: 1) Extend bpftool to produce a struct (aka "skeleton") tailored and specific to a provided BPF object file. This provides an alternative, simplified API compared to standard libbpf interaction. Also, add libbpf extern variable resolution for .kconfig section to import Kconfig data, from Andrii Nakryiko. 2) Add BPF dispatcher for XDP which is a mechanism to avoid indirect calls by generating a branch funnel as discussed back in bpfconf'19 at LSF/MM. Also, add various BPF riscv JIT improvements, from Björn Töpel. 3) Extend bpftool to allow matching BPF programs and maps by name, from Paul Chaignon. 4) Support for replacing cgroup BPF programs attached with BPF_F_ALLOW_MULTI flag for allowing updates without service interruption, from Andrey Ignatov. 5) Cleanup and simplification of ring access functions for AF_XDP with a bonus of 0-5% performance improvement, from Magnus Karlsson. 6) Enable BPF JITs for x86-64 and arm64 by default. Also, final version of audit support for BPF, from Daniel Borkmann and latter with Jiri Olsa. 7) Move and extend test_select_reuseport into BPF program tests under BPF selftests, from Jakub Sitnicki. 8) Various BPF sample improvements for xdpsock for customizing parameters to set up and benchmark AF_XDP, from Jay Jayatheerthan. 9) Improve libbpf to provide a ulimit hint on permission denied errors. Also change XDP sample programs to attach in driver mode by default, from Toke Høiland-Jørgensen. 10) Extend BPF test infrastructure to allow changing skb mark from tc BPF programs, from Nikita V. Shirokov. 11) Optimize prologue code sequence in BPF arm32 JIT, from Russell King. 12) Fix xdp_redirect_cpu BPF sample to manually attach to tracepoints after libbpf conversion, from Jesper Dangaard Brouer. 13) Minor misc improvements from various others. ==================== Signed-off-by: David S. Miller + Changed Files: nan + Parent Hashes: 9e41fbf3dd38327d440a8f3ba0c234519dbb5280 7c8dce4b166113743adad131b5a24c4acc12f92c +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges BPF updates from the bpf-next branch into the net-next tree, resolving conflicts and introducing features like bpftool skeleton and BPF dispatcher for XDP.", + "keywords": "BPF, merge, updates", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges BPF updates from the bpf-next branch into the net-next tree, resolving conflicts and introducing features like bpftool skeleton and BPF dispatcher for XDP.", + "keywords": "BPF, merge, updates", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 767/6895 - Commit ID: 7c8dce4b166113743adad131b5a24c4acc12f92c +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 7c8dce4b166113743adad131b5a24c4acc12f92c + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1577437865 + Commit Message: + bpftool: Make skeleton C code compilable with C++ compiler When auto-generated BPF skeleton C code is included from C++ application, it triggers compilation error due to void * being implicitly casted to whatever target pointer type. This is supported by C, but not C++. To solve this problem, add explicit casts, where necessary. To ensure issues like this are captured going forward, add skeleton usage in test_cpp test. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191226210253.3132060-1-andriin@fb.com + Changed Files: tools/bpf/bpftool/gen.c | 10 +++++-----; tools/testing/selftests/bpf/Makefile | 2 +-; tools/testing/selftests/bpf/test_cpp.cpp | 10 ++++++++++; 3 files changed, 16 insertions(+), 6 deletions(-) + Parent Hashes: 1162f844030ac1ac7321b5e8f6c9badc7a11428f +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit makes bpftool skeleton code compatible with C++ compilers by adding explicit type casts and includes a test for C++ compilation.", + "keywords": "bpftool, C++, compatibility", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit makes bpftool skeleton code compatible with C++ compilers by adding explicit type casts and includes a test for C++ compilation.", + "keywords": "bpftool, C++, compatibility", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 768/6895 - Commit ID: 3c2f450e553ce47fcb0d6141807a8858e3213c9c +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 3c2f450e553ce47fcb0d6141807a8858e3213c9c + Author Name: David S. Miller + Author Email: davem@davemloft.net + Commit Date: 1577402704 + Commit Message: + Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf Daniel Borkmann says: ==================== pull-request: bpf 2019-12-23 The following pull-request contains BPF updates for your *net* tree. We've added 2 non-merge commits during the last 1 day(s) which contain a total of 4 files changed, 34 insertions(+), 31 deletions(-). The main changes are: 1) Fix libbpf build when building on a read-only filesystem with O=dir option, from Namhyung Kim. 2) Fix a precision tracking bug for unknown scalars, from Daniel Borkmann. ==================== Signed-off-by: David S. Miller + Changed Files: nan + Parent Hashes: 7df2281a174bd0fdbb2211a26914e5440740fcde fa633a0f89192379828103957874682d389eae83 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges bpf updates into the net tree, including build and precision tracking fixes.", + "keywords": "bpf, merge, fixes", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges BPF updates related to build and precision tracking fixes into the net tree.", + "keywords": "bpf, merge, fixes", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 769/6895 - Commit ID: 1162f844030ac1ac7321b5e8f6c9badc7a11428f +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 1162f844030ac1ac7321b5e8f6c9badc7a11428f + Author Name: Hechao Li + Author Email: hechaol@fb.com + Commit Date: 1577352954 + Commit Message: + bpf: Print error message for bpftool cgroup show Currently, when bpftool cgroup show has an error, no error message is printed. This is confusing because the user may think the result is empty. Before the change: $ bpftool cgroup show /sys/fs/cgroup ID AttachType AttachFlags Name $ echo $? 255 After the change: $ ./bpftool cgroup show /sys/fs/cgroup Error: can't query bpf programs attached to /sys/fs/cgroup: Operation not permitted v2: Rename check_query_cgroup_progs to cgroup_has_attached_progs Signed-off-by: Hechao Li Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191224011742.3714301-1-hechaol@fb.com + Changed Files: tools/bpf/bpftool/cgroup.c | 56 ++++++++++++++++++++++++++++++++--------------; 1 file changed, 39 insertions(+), 17 deletions(-) + Parent Hashes: 8ab9da573dad95536d8a92f19d7967e8142cd827 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds error message handling for bpftool cgroup show to clarify user confusion during errors.", + "keywords": "error,message,bpftool", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups)." + ] +} +Rethinking... +new content: +{ + "summary": "The commit improves user feedback by adding error messages for failures in the bpftool cgroup show command.", + "keywords": "error,bpftool,cgroup", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups)." + ] +} +-------------------- +-------------------- +Processing Commit 770/6895 - Commit ID: 8ab9da573dad95536d8a92f19d7967e8142cd827 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 8ab9da573dad95536d8a92f19d7967e8142cd827 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1577352704 + Commit Message: + libbpf: Support CO-RE relocations for LDX/ST/STX instructions Clang patch [0] enables emitting relocatable generic ALU/ALU64 instructions (i.e, shifts and arithmetic operations), as well as generic load/store instructions. The former ones are already supported by libbpf as is. This patch adds further support for load/store instructions. Relocatable field offset is encoded in BPF instruction's 16-bit offset section and are adjusted by libbpf based on target kernel BTF. These Clang changes and corresponding libbpf changes allow for more succinct generated BPF code by encoding relocatable field reads as a single ST/LDX/STX instruction. It also enables relocatable access to BPF context. Previously, if context struct (e.g., __sk_buff) was accessed with CO-RE relocations (e.g., due to preserve_access_index attribute), it would be rejected by BPF verifier due to modified context pointer dereference. With Clang patch, such context accesses are both relocatable and have a fixed offset from the point of view of BPF verifier. [0] https://reviews.llvm.org/D71790 Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20191223180305.86417-1-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.c | 31 ++++++++++++++++++++++++++++---; 1 file changed, 28 insertions(+), 3 deletions(-) + Parent Hashes: f9e6bfdbaf0cf304d72c70a05d81acac01a04f48 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds support for Core-Relocations for load/store instructions in libbpf using Clang optimizations.", + "keywords": "libbpf,CO-RE,Clang", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds support for CO-RE relocations for load/store instructions in libbpf using Clang enhancements.", + "keywords": "libbpf,Clang,CO-RE", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 771/6895 - Commit ID: fa633a0f89192379828103957874682d389eae83 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: fa633a0f89192379828103957874682d389eae83 + Author Name: Namhyung Kim + Author Email: namhyung@kernel.org + Commit Date: 1577111646 + Commit Message: + libbpf: Fix build on read-only filesystems I got the following error when I tried to build perf on a read-only filesystem with O=dir option. $ cd /some/where/ro/linux/tools/perf $ make O=$HOME/build/perf ... CC /home/namhyung/build/perf/lib.o /bin/sh: bpf_helper_defs.h: Read-only file system make[3]: *** [Makefile:184: bpf_helper_defs.h] Error 1 make[2]: *** [Makefile.perf:778: /home/namhyung/build/perf/libbpf.a] Error 2 make[2]: *** Waiting for unfinished jobs.... LD /home/namhyung/build/perf/libperf-in.o AR /home/namhyung/build/perf/libperf.a PERF_VERSION = 5.4.0 make[1]: *** [Makefile.perf:225: sub-make] Error 2 make: *** [Makefile:70: all] Error 2 It was becaused bpf_helper_defs.h was generated in current directory. Move it to OUTPUT directory. Signed-off-by: Namhyung Kim Signed-off-by: Daniel Borkmann Tested-by: Andrii Nakryiko Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20191223061326.843366-1-namhyung@kernel.org + Changed Files: tools/lib/bpf/Makefile | 15 ++++++++-------; tools/testing/selftests/bpf/.gitignore | 1 +; tools/testing/selftests/bpf/Makefile | 6 +++---; 3 files changed, 12 insertions(+), 10 deletions(-) + Parent Hashes: f54c7898ed1c3c9331376c0337a5049c38f66497 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes a build issue on read-only filesystems by changing the generation path for bpf_helper_defs.h.", + "keywords": "build, read-only, filesystem", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes a build issue on read-only filesystems by changing the generation path for bpf_helper_defs.h.", + "keywords": "build, read-only, filesystem", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 772/6895 - Commit ID: f54c7898ed1c3c9331376c0337a5049c38f66497 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: f54c7898ed1c3c9331376c0337a5049c38f66497 + Author Name: Daniel Borkmann + Author Email: daniel@iogearbox.net + Commit Date: 1577064070 + Commit Message: + bpf: Fix precision tracking for unbounded scalars Anatoly has been fuzzing with kBdysch harness and reported a hang in one of the outcomes. Upon closer analysis, it turns out that precise scalar value tracking is missing a few precision markings for unknown scalars: 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 0: (b7) r0 = 0 1: R0_w=invP0 R1=ctx(id=0,off=0,imm=0) R10=fp0 1: (35) if r0 >= 0xf72e goto pc+0 --> only follow fallthrough 2: R0_w=invP0 R1=ctx(id=0,off=0,imm=0) R10=fp0 2: (35) if r0 >= 0x80fe0000 goto pc+0 --> only follow fallthrough 3: R0_w=invP0 R1=ctx(id=0,off=0,imm=0) R10=fp0 3: (14) w0 -= -536870912 4: R0_w=invP536870912 R1=ctx(id=0,off=0,imm=0) R10=fp0 4: (0f) r1 += r0 5: R0_w=invP536870912 R1_w=inv(id=0) R10=fp0 5: (55) if r1 != 0x104c1500 goto pc+0 --> push other branch for later analysis R0_w=invP536870912 R1_w=inv273421568 R10=fp0 6: R0_w=invP536870912 R1_w=inv273421568 R10=fp0 6: (b7) r0 = 0 7: R0=invP0 R1=inv273421568 R10=fp0 7: (76) if w1 s>= 0xffffff00 goto pc+3 --> only follow goto 11: R0=invP0 R1=inv273421568 R10=fp0 11: (95) exit 6: R0_w=invP536870912 R1_w=inv(id=0) R10=fp0 6: (b7) r0 = 0 propagating r0 7: safe processed 11 insns [...] In the analysis of the second path coming after the successful exit above, the path is being pruned at line 7. Pruning analysis found that both r0 are precise P0 and both R1 are non-precise scalars and given prior path with R1 as non-precise scalar succeeded, this one is therefore safe as well. However, problem is that given condition at insn 7 in the first run, we only followed goto and didn't push the other branch for later analysis, we've never walked the few insns in there and therefore dead-code sanitation rewrites it as goto pc-1, causing the hang depending on the skb address hitting these conditions. The issue is that R1 should have been marked as precise as well such that pruning enforces range check and conluded that new R1 is not in range of old R1. In insn 4, we mark R1 (skb) as unknown scalar via __mark_reg_unbounded() but not mark_reg_unbounded() and therefore regs->precise remains as false. Back in b5dc0163d8fd ("bpf: precise scalar_value tracking"), this was not the case since marking out of __mark_reg_unbounded() had this covered as well. Once in both are set as precise in 4 as they should have been, we conclude that given R1 was in prior fall-through path 0x104c1500 and now is completely unknown, the check at insn 7 concludes that we need to continue walking. Analysis after the fix: 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 0: (b7) r0 = 0 1: R0_w=invP0 R1=ctx(id=0,off=0,imm=0) R10=fp0 1: (35) if r0 >= 0xf72e goto pc+0 2: R0_w=invP0 R1=ctx(id=0,off=0,imm=0) R10=fp0 2: (35) if r0 >= 0x80fe0000 goto pc+0 3: R0_w=invP0 R1=ctx(id=0,off=0,imm=0) R10=fp0 3: (14) w0 -= -536870912 4: R0_w=invP536870912 R1=ctx(id=0,off=0,imm=0) R10=fp0 4: (0f) r1 += r0 5: R0_w=invP536870912 R1_w=invP(id=0) R10=fp0 5: (55) if r1 != 0x104c1500 goto pc+0 R0_w=invP536870912 R1_w=invP273421568 R10=fp0 6: R0_w=invP536870912 R1_w=invP273421568 R10=fp0 6: (b7) r0 = 0 7: R0=invP0 R1=invP273421568 R10=fp0 7: (76) if w1 s>= 0xffffff00 goto pc+3 11: R0=invP0 R1=invP273421568 R10=fp0 11: (95) exit 6: R0_w=invP536870912 R1_w=invP(id=0) R10=fp0 6: (b7) r0 = 0 7: R0_w=invP0 R1_w=invP(id=0) R10=fp0 7: (76) if w1 s>= 0xffffff00 goto pc+3 R0_w=invP0 R1_w=invP(id=0) R10=fp0 8: R0_w=invP0 R1_w=invP(id=0) R10=fp0 8: (a5) if r0 < 0x2007002a goto pc+0 9: R0_w=invP0 R1_w=invP(id=0) R10=fp0 9: (57) r0 &= -16316416 10: R0_w=invP0 R1_w=invP(id=0) R10=fp0 10: (a6) if w0 < 0x1201 goto pc+0 11: R0_w=invP0 R1_w=invP(id=0) R10=fp0 11: (95) exit 11: R0=invP0 R1=invP(id=0) R10=fp0 11: (95) exit processed 16 insns [...] Fixes: 6754172c208d ("bpf: fix precision tracking in presence of bpf2bpf calls") Reported-by: Anatoly Trosinenko Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191222223740.25297-1-daniel@iogearbox.net + Changed Files: kernel/bpf/verifier.c | 43 ++++++++++++++++++++++---------------------; 1 file changed, 22 insertions(+), 21 deletions(-) + Parent Hashes: c60174717544aa8959683d7e19d568309c3a0c65 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes precision tracking for unbounded scalars in the eBPF verifier to avoid hangs caused by dead-code sanitation issues.", + "keywords": "precision,tracking,scalars", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes precision tracking for unbounded scalars in the eBPF verifier to prevent hangs from dead-code sanitation errors.", + "keywords": "precision,tracking,scalars", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 773/6895 - Commit ID: f9e6bfdbaf0cf304d72c70a05d81acac01a04f48 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: f9e6bfdbaf0cf304d72c70a05d81acac01a04f48 + Author Name: Jesper Dangaard Brouer + Author Email: brouer@redhat.com + Commit Date: 1576887223 + Commit Message: + samples/bpf: Xdp_redirect_cpu fix missing tracepoint attach When sample xdp_redirect_cpu was converted to use libbpf, the tracepoints used by this sample were not getting attached automatically like with bpf_load.c. The BPF-maps was still getting loaded, thus nobody notice that the tracepoints were not updating these maps. This fix doesn't use the new skeleton code, as this bug was introduced in v5.1 and stable might want to backport this. E.g. Red Hat QA uses this sample as part of their testing. Fixes: bbaf6029c49c ("samples/bpf: Convert XDP samples to libbpf usage") Signed-off-by: Jesper Dangaard Brouer Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/157685877642.26195.2798780195186786841.stgit@firesoul + Changed Files: samples/bpf/xdp_redirect_cpu_user.c | 59 ++++++++++++++++++++++++++++++++++---; 1 file changed, 55 insertions(+), 4 deletions(-) + Parent Hashes: 6cd6e64e3603bd5d1677365cf935c2d8e9f496e0 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit fixes a bug in the xdp_redirect_cpu sample regarding missing tracepoints' attachment when using libbpf.", + "keywords": "tracepoint, libbpf, fix", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing." + ] +} +Rethinking... +new content: +{ + "summary": "This commit fixes a missing tracepoint attachment issue in the xdp_redirect_cpu sample when using libbpf.", + "keywords": "tracepoint, libbpf, fix", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing." + ] +} +-------------------- +-------------------- +Processing Commit 774/6895 - Commit ID: 46e3268eaaca9f8a0f145872b96fe6d54a232890 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 46e3268eaaca9f8a0f145872b96fe6d54a232890 + Author Name: Jay Jayatheerthan + Author Email: jay.jayatheerthan@intel.com + Commit Date: 1576887039 + Commit Message: + samples/bpf: xdpsock: Add option to specify transmit fill pattern The UDP payload fill pattern can be specified using '-P' or '--tx-pkt-pattern' option. It is an unsigned 32 bit field and defaulted to 0x12345678. The IP and UDP checksum is calculated by the code as per the content of the packet before transmission. Signed-off-by: Jay Jayatheerthan Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191220085530.4980-7-jay.jayatheerthan@intel.com + Changed Files: samples/bpf/xdpsock_user.c | 13 +++++++++----; 1 file changed, 9 insertions(+), 4 deletions(-) + Parent Hashes: 4a3c23ae3acc6185a9d418830f22672a52ff986a +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds a command-line option in xdpsock to specify a transmit fill pattern for UDP payloads with checksum verification.", + "keywords": "xdpsock,transmit pattern,UDP", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "I'm not sure about the implementation component of the commit. The component affected by It is unclear.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +Rethinking... +new content: +{ + "summary": "The commit introduces an option to specify a UDP payload transmit fill pattern in the xdpsock sample program.", + "keywords": "xdpsock,pattern,UDP", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +-------------------- +-------------------- +Processing Commit 775/6895 - Commit ID: 4a3c23ae3acc6185a9d418830f22672a52ff986a +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 4a3c23ae3acc6185a9d418830f22672a52ff986a + Author Name: Jay Jayatheerthan + Author Email: jay.jayatheerthan@intel.com + Commit Date: 1576887039 + Commit Message: + samples/bpf: xdpsock: Add option to specify tx packet size New option '-s' or '--tx-pkt-size' has been added to specify the transmit packet size. The packet size ranges from 47 to 4096 bytes. When this option is not provided, it defaults to 64 byte packet. The code uses struct ethhdr, struct iphdr and struct udphdr to form the transmit packet. The MAC address, IP address and UDP ports are set to default values. The code calculates IP and UDP checksums before sending the packet. Checksum calculation code in Linux kernel is used for this purpose. The Ethernet FCS is not filled by the code. Signed-off-by: Jay Jayatheerthan Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191220085530.4980-6-jay.jayatheerthan@intel.com + Changed Files: samples/bpf/xdpsock_user.c | 276 +++++++++++++++++++++++++++++++++++++++++++--; 1 file changed, 265 insertions(+), 11 deletions(-) + Parent Hashes: ece6e9694751a4f0b99372724a0705a0217132b3 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds a new option to specify the transmit packet size in xdpsock, ranging from 47 to 4096 bytes.", + "keywords": "xdpsock, packet, size", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +Rethinking... +new content: +{ + "summary": "This commit introduces a new option to set the transmit packet size in the xdpsock example program.", + "keywords": "xdpsock, transmit, packet", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +-------------------- +-------------------- +Processing Commit 776/6895 - Commit ID: ece6e9694751a4f0b99372724a0705a0217132b3 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: ece6e9694751a4f0b99372724a0705a0217132b3 + Author Name: Jay Jayatheerthan + Author Email: jay.jayatheerthan@intel.com + Commit Date: 1576887039 + Commit Message: + samples/bpf: xdpsock: Add option to specify number of packets to send Use '-C' or '--tx-pkt-count' to specify number of packets to send. If it is not specified, the application sends packets forever. If packet count is not a multiple of batch size, last batch sent is less than the batch size. Signed-off-by: Jay Jayatheerthan Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191220085530.4980-5-jay.jayatheerthan@intel.com + Changed Files: samples/bpf/xdpsock_user.c | 73 +++++++++++++++++++++++++++++++++++++---------; 1 file changed, 59 insertions(+), 14 deletions(-) + Parent Hashes: cd9e72b6f21044b36a096833003811c2b2038455 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds an option to the xdpsock sample to specify the number of packets to send.", + "keywords": "xdpsock,packets,option", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds an option to the xdpsock sample to specify the number of packets to send.", + "keywords": "xdpsock,packets,option", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here." + ] +} +-------------------- +-------------------- +Processing Commit 777/6895 - Commit ID: cd9e72b6f21044b36a096833003811c2b2038455 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: cd9e72b6f21044b36a096833003811c2b2038455 + Author Name: Jay Jayatheerthan + Author Email: jay.jayatheerthan@intel.com + Commit Date: 1576887039 + Commit Message: + samples/bpf: xdpsock: Add option to specify batch size New option to specify batch size for tx, rx and l2fwd has been added. This allows fine tuning to maximize performance. It is specified using '-b' or '--batch_size' options. When not specified default is 64. Signed-off-by: Jay Jayatheerthan Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191220085530.4980-4-jay.jayatheerthan@intel.com + Changed Files: samples/bpf/xdpsock_user.c | 52 ++++++++++++++++++++++++++--------------------; 1 file changed, 29 insertions(+), 23 deletions(-) + Parent Hashes: 695255882bdf63da240db33d0f2aa9ccca1cbe67 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds a new option for specifying batch size in the xdpsock sample application to optimize performance.", + "keywords": "batch,performance,xdpsock", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds a new option for specifying batch size in the xdpsock sample application to optimize performance.", + "keywords": "batch,performance,xdpsock", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +-------------------- +-------------------- +Processing Commit 778/6895 - Commit ID: 695255882bdf63da240db33d0f2aa9ccca1cbe67 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 695255882bdf63da240db33d0f2aa9ccca1cbe67 + Author Name: Jay Jayatheerthan + Author Email: jay.jayatheerthan@intel.com + Commit Date: 1576887039 + Commit Message: + samples/bpf: xdpsock: Use common code to handle signal and main exit Add code to do cleanup for signals and application completion in a unified fashion. The signal handler sets benckmark_done flag terminating the threads. The cleanup is called before returning from main() function. Signed-off-by: Jay Jayatheerthan Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191220085530.4980-3-jay.jayatheerthan@intel.com + Changed Files: samples/bpf/xdpsock_user.c | 9 +++++++--; 1 file changed, 7 insertions(+), 2 deletions(-) + Parent Hashes: d3f11b018f6ce278e683008e9c225fe87afc532d +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Unified signal handler and cleanup code in xdpsock sample for better resource management on exit.", + "keywords": "xdpsock,signal handler,cleanup", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "I'm not sure about the implementation component of the commit. The component affected by It is unclear.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +Rethinking... +new content: +{ + "summary": "Unified signal handling and cleanup in the xdpsock sample for better resource management upon application exit.", + "keywords": "xdpsock,signal,cleanup", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +-------------------- +-------------------- +Processing Commit 779/6895 - Commit ID: d3f11b018f6ce278e683008e9c225fe87afc532d +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: d3f11b018f6ce278e683008e9c225fe87afc532d + Author Name: Jay Jayatheerthan + Author Email: jay.jayatheerthan@intel.com + Commit Date: 1576887039 + Commit Message: + samples/bpf: xdpsock: Add duration option to specify how long to run The application now supports '-d' or '--duration' option to specify number of seconds to run. This is used in tx, rx and l2fwd features. If this option is not provided, the application runs forever. Signed-off-by: Jay Jayatheerthan Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191220085530.4980-2-jay.jayatheerthan@intel.com + Changed Files: samples/bpf/xdpsock_user.c | 37 +++++++++++++++++++++++++++++++++++--; 1 file changed, 35 insertions(+), 2 deletions(-) + Parent Hashes: 478bee0df0ec9067c12e7d058d78721a7e7a1b29 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds a duration option to the xdpsock sample that specifies how long it should run.", + "keywords": "xdpsock,duration,option", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The xdpsock sample now supports a duration option to specify run time in seconds.", + "keywords": "xdpsock,duration,option", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +-------------------- +-------------------- +Processing Commit 780/6895 - Commit ID: 478bee0df0ec9067c12e7d058d78721a7e7a1b29 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 478bee0df0ec9067c12e7d058d78721a7e7a1b29 + Author Name: Andrey Ignatov + Author Email: rdna@fb.com + Commit Date: 1576886762 + Commit Message: + selftests/bpf: Preserve errno in test_progs CHECK macros It's follow-up for discussion [1] CHECK and CHECK_FAIL macros in test_progs.h can affect errno in some circumstances, e.g. if some code accidentally closes stdout. It makes checking errno in patterns like this unreliable: if (CHECK(!bpf_prog_attach_xattr(...), "tag", "msg")) goto err; CHECK_FAIL(errno != ENOENT); , since by CHECK_FAIL time errno could be affected not only by bpf_prog_attach_xattr but by CHECK as well. Fix it by saving and restoring errno in the macros. There is no "Fixes" tag since no problems were discovered yet and it's rather precaution. test_progs was run with this change and no difference was identified. [1] https://lore.kernel.org/bpf/20191219210907.GD16266@rdna-mbp.dhcp.thefacebook.com/ Signed-off-by: Andrey Ignatov Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20191220000511.1684853-1-rdna@fb.com + Changed Files: tools/testing/selftests/bpf/test_progs.h | 4 ++++; 1 file changed, 4 insertions(+) + Parent Hashes: ce3cec27933c069d2015a81e59b93eb656fe7ee4 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit updates test macros to preserve errno during selftests in bpf to ensure reliable error checking.", + "keywords": "errno,macros,test", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit updates test macros in selftests for bpf to preserve errno value for reliable error checking.", + "keywords": "errno,macros,selftests", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 781/6895 - Commit ID: ce3cec27933c069d2015a81e59b93eb656fe7ee4 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: ce3cec27933c069d2015a81e59b93eb656fe7ee4 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1576886420 + Commit Message: + Merge branch 'xsk-cleanup' Magnus Karlsson says: ==================== This patch set cleans up the ring access functions of AF_XDP in hope that it will now be easier to understand and maintain. I used to get a headache every time I looked at this code in order to really understand it, but now I do think it is a lot less painful. The code has been simplified a lot and as a bonus we get better performance in nearly all cases. On my new 2.1 GHz Cascade Lake machine with a standard default config plus AF_XDP support and CONFIG_PREEMPT on I get the following results in percent performance increases with this patch set compared to without it: Zero-copy (-N): rxdrop txpush l2fwd 1 core: -2% 0% 3% 2 cores: 4% 0% 3% Zero-copy with poll() (-N -p): rxdrop txpush l2fwd 1 core: 3% 0% 1% 2 cores: 21% 0% 9% Skb mode (-S): Shows a 0% to 5% performance improvement over the same benchmarks as above. Here 1 core means that we are running the driver processing and the application on the same core, while 2 cores means that they execute on separate cores. The applications are from the xdpsock sample app. On my older 2.0 Ghz Broadwell machine that I used for the v1, I get the following results: Zero-copy (-N): rxdrop txpush l2fwd 1 core: 4% 5% 4% 2 cores: 1% 0% 2% Zero-copy with poll() (-N -p): rxdrop txpush l2fwd 1 core: 1% 3% 3% 2 cores: 22% 0% 5% Skb mode (-S): Shows a 0% to 1% performance improvement over the same benchmarks as above. When a results says 21 or 22% better, as in the case of poll mode with 2 cores and rxdrop, my first reaction is that it must be a bug. Everything else shows between 0% and 5% performance improvement. What is giving rise to 22%? A quick bisect indicates that it is patches 2, 3, 4, 5, and 6 that are giving rise to most of this improvement. So not one patch in particular, but something around 4% improvement from each one of them. Note that exactly this benchmark has previously had an extraordinary slow down compared to when running without poll syscalls. For all the other poll tests above, the slowdown has always been around 4% for using poll syscalls. But with the bad performing test in question, it was above 25%. Interestingly, after this clean up, the slow down is 4%, just like all the other poll tests. Please take an extra peek at this so I have not messed up something. The 0% for several txpush results are due to the test bottlenecking on a non-CPU HW resource. If I eliminated that bottleneck on my system, I would expect to see an increase there too. Changes v1 -> v2: * Corrected textual errors in the commit logs (Sergei and Martin) * Fixed the functions that detect empty and full rings so that they now operate on the global ring state (Maxim) This patch has been applied against commit a352a82496d1 ("Merge branch 'libbpf-extern-followups'") Structure of the patch set: Patch 1: Eliminate the lazy update threshold used when preallocating entries in the completion ring Patch 2: Simplify the detection of empty and full rings Patch 3: Consolidate the two local producer pointers into one Patch 4: Standardize the naming of the producer ring access functions Patch 5: Eliminate the Rx batch size used for the fill ring Patch 6: Simplify the functions xskq_nb_avail and xskq_nb_free Patch 7: Simplify and standardize the naming of the consumer ring access functions Patch 8: Change the names of the validation functions to improve readability and also the return value of these functions Patch 9: Change the name of xsk_umem_discard_addr() to xsk_umem_release_addr() to better reflect the new names. Requires a name change in the drivers that support AF_XDP zero-copy. Patch 10: Remove unnecessary READ_ONCE of data in the ring Patch 11: Add overall function naming comment and reorder the functions for easier reference Patch 12: Use the struct_size helper function when allocating rings ==================== Reviewed-by: Björn Töpel Tested-by: Björn Töpel Acked-by: Björn Töpel Signed-off-by: Alexei Starovoitov + Changed Files: nan + Parent Hashes: 99cacdc6f661f50f44a0ef006a1a3db20c0577f6 1d9cb1f381860b529edec57cf7a08133f40366eb +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges a patch set aimed at simplifying AF_XDP ring access functions for better readability and performance.", + "keywords": "AF_XDP,rings,cleanup", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges a patch set aimed at simplifying AF_XDP ring access functions for better readability and performance.", + "keywords": "AF_XDP,rings,cleanup", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 782/6895 - Commit ID: 1d9cb1f381860b529edec57cf7a08133f40366eb +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 1d9cb1f381860b529edec57cf7a08133f40366eb + Author Name: Magnus Karlsson + Author Email: magnus.karlsson@intel.com + Commit Date: 1576886409 + Commit Message: + xsk: Use struct_size() helper Improve readability and maintainability by using the struct_size() helper when allocating the AF_XDP rings. Signed-off-by: Magnus Karlsson Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/1576759171-28550-13-git-send-email-magnus.karlsson@intel.com + Changed Files: net/xdp/xsk_queue.c | 15 +++++++--------; 1 file changed, 7 insertions(+), 8 deletions(-) + Parent Hashes: 15d8c9162ced1789d25261859a7b37db8426e409 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit improves readability by utilizing the struct_size() helper for AF_XDP rings allocation.", + "keywords": "xsk struct_size helper", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "This commit enhances code readability by using struct_size() for AF_XDP ring allocations.", + "keywords": "xsk struct_size readability", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 783/6895 - Commit ID: 15d8c9162ced1789d25261859a7b37db8426e409 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 15d8c9162ced1789d25261859a7b37db8426e409 + Author Name: Magnus Karlsson + Author Email: magnus.karlsson@intel.com + Commit Date: 1576886409 + Commit Message: + xsk: Add function naming comments and reorder functions Add comments on how the ring access functions are named and how they are supposed to be used for producers and consumers. The functions are also reordered so that the consumer functions are in the beginning and the producer functions in the end, for easier reference. Put this in a separate patch as the diff might look a little odd, but no functionality has changed in this patch. Signed-off-by: Magnus Karlsson Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/1576759171-28550-12-git-send-email-magnus.karlsson@intel.com + Changed Files: net/xdp/xsk.c | 10 ++; net/xdp/xsk_queue.h | 293 ++++++++++++++++++++++++++++------------------------; 2 files changed, 167 insertions(+), 136 deletions(-) + Parent Hashes: c34787fcc90f0732ff00754057f11780007002e4 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds comments for function naming and reorders functions in xsk for clarity without changing functionality.", + "keywords": "function,reorder,comments", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds comments and reorders xsk functions to enhance clarity without altering functionality.", + "keywords": "function,naming,reorder", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 784/6895 - Commit ID: c34787fcc90f0732ff00754057f11780007002e4 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: c34787fcc90f0732ff00754057f11780007002e4 + Author Name: Magnus Karlsson + Author Email: magnus.karlsson@intel.com + Commit Date: 1576886409 + Commit Message: + xsk: Remove unnecessary READ_ONCE of data There are two unnecessary READ_ONCE of descriptor data. These are not needed since the data is written by the producer before it signals that the data is available by incrementing the producer pointer. As the access to this producer pointer is serialized and the consumer always reads the descriptor after it has read and synchronized with the producer counter, the write of the descriptor will have fully completed and it does not matter if the consumer has any read tearing. Signed-off-by: Magnus Karlsson Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/1576759171-28550-11-git-send-email-magnus.karlsson@intel.com + Changed Files: net/xdp/xsk_queue.h | 4 ++--; 1 file changed, 2 insertions(+), 2 deletions(-) + Parent Hashes: f8509aa078de0842ec1817e8026e58620cd05d3b +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit removes unnecessary READ_ONCE operations on descriptor data in the xsk subsystem.", + "keywords": "xsk,READ_ONCE,descriptor", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "The commit removes unnecessary READ_ONCE operations on descriptor data in the xsk code.", + "keywords": "xsk,READ_ONCE,descriptor", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 785/6895 - Commit ID: f8509aa078de0842ec1817e8026e58620cd05d3b +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: f8509aa078de0842ec1817e8026e58620cd05d3b + Author Name: Magnus Karlsson + Author Email: magnus.karlsson@intel.com + Commit Date: 1576886409 + Commit Message: + xsk: ixgbe: i40e: ice: mlx5: Xsk_umem_discard_addr to xsk_umem_release_addr Change the name of xsk_umem_discard_addr to xsk_umem_release_addr to better reflect the new naming of the AF_XDP queue manipulation functions. As this functions is used by drivers implementing support for AF_XDP zero-copy, it requires a name change to these drivers. The function xsk_umem_release_addr_rq has also changed name in the same fashion. Signed-off-by: Magnus Karlsson Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/1576759171-28550-10-git-send-email-magnus.karlsson@intel.com + Changed Files: drivers/net/ethernet/intel/i40e/i40e_xsk.c | 4 ++--; drivers/net/ethernet/intel/ice/ice_xsk.c | 4 ++--; drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c | 4 ++--; drivers/net/ethernet/mellanox/mlx5/core/en/xsk/rx.c | 2 +-; include/net/xdp_sock.h | 10 +++++-----; net/xdp/xsk.c | 4 ++--; 6 files changed, 14 insertions(+), 14 deletions(-) + Parent Hashes: 03896ef1f0cb23d2742ddf486c531c700a2da7d6 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Rename functions used by AF_XDP zero-copy drivers to align with new naming conventions.", + "keywords": "AF_XDP,rename,drivers", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +Rethinking... +new content: +{ + "summary": "Rename AF_XDP zero-copy driver functions to better reflect new queue manipulation naming conventions.", + "keywords": "AF_XDP,drivers,rename", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here." + ] +} +-------------------- +-------------------- +Processing Commit 786/6895 - Commit ID: 03896ef1f0cb23d2742ddf486c531c700a2da7d6 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 03896ef1f0cb23d2742ddf486c531c700a2da7d6 + Author Name: Magnus Karlsson + Author Email: magnus.karlsson@intel.com + Commit Date: 1576886409 + Commit Message: + xsk: Change names of validation functions Change the names of the validation functions to better reflect what they are doing. The uppermost ones are reading entries from the rings and only the bottom ones validate entries. So xskq_cons_read_ is a better prefix name. Also change the xskq_cons_read_ functions to return a bool as the the descriptor or address is already returned by reference in the parameters. Everyone is using the return value as a bool anyway. Signed-off-by: Magnus Karlsson Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/1576759171-28550-9-git-send-email-magnus.karlsson@intel.com + Changed Files: include/net/xdp_sock.h | 4 ++--; net/xdp/xsk.c | 4 ++--; net/xdp/xsk_queue.h | 59 ++++++++++++++++++++++++++------------------------; 3 files changed, 35 insertions(+), 32 deletions(-) + Parent Hashes: c5ed924b54c892ee637d2e6889ef83341835a560 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Renamed validation functions in xsk to clarify purpose and modified their return type to enhance boolean usage.", + "keywords": "validation,xsk,function", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +Rethinking... +new content: +{ + "summary": "Refactored xsk validation function names and return types to improve clarity and efficient boolean usage.", + "keywords": "xsk,validation,function", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +-------------------- +-------------------- +Processing Commit 787/6895 - Commit ID: c5ed924b54c892ee637d2e6889ef83341835a560 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: c5ed924b54c892ee637d2e6889ef83341835a560 + Author Name: Magnus Karlsson + Author Email: magnus.karlsson@intel.com + Commit Date: 1576886409 + Commit Message: + xsk: Simplify the consumer ring access functions Simplify and refactor consumer ring functions. The consumer first "peeks" to find descriptors or addresses that are available to read from the ring, then reads them and finally "releases" these descriptors once it is done. The two local variables cons_tail and cons_head are turned into one single variable called cached_cons. cached_tail referred to the cached value of the global consumer pointer and will be stored in cached_cons. For cached_head, we just use cached_prod instead as it was not used for a consumer queue before. It also better reflects what it really is now: a cached copy of the producer pointer. The names of the functions are also renamed in the same manner as the producer functions. The new functions are called xskq_cons_ followed by what it does. Signed-off-by: Magnus Karlsson Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/1576759171-28550-8-git-send-email-magnus.karlsson@intel.com + Changed Files: net/xdp/xsk.c | 24 ++++++-------; net/xdp/xsk_queue.h | 102 ++++++++++++++++++++++++----------------------------; 2 files changed, 58 insertions(+), 68 deletions(-) + Parent Hashes: df0ae6f78a45e5696427779fc3379c5d75f5d4a5 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Refactor and simplify consumer ring functions in the xsk component by merging variables and renaming functions.", + "keywords": "simplify, refactor, consumer", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here." + ] +} +Rethinking... +new content: +{ + "summary": "Refactor consumer ring functions in xsk to merge variables and align function naming with producer functions.", + "keywords": "xsk, refactor, consumer", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 788/6895 - Commit ID: df0ae6f78a45e5696427779fc3379c5d75f5d4a5 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: df0ae6f78a45e5696427779fc3379c5d75f5d4a5 + Author Name: Magnus Karlsson + Author Email: magnus.karlsson@intel.com + Commit Date: 1576886409 + Commit Message: + xsk: Simplify xskq_nb_avail and xskq_nb_free At this point, there are no users of the functions xskq_nb_avail and xskq_nb_free that take any other number of entries argument than 1, so let us get rid of the second argument that takes the number of entries. Signed-off-by: Magnus Karlsson Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/1576759171-28550-7-git-send-email-magnus.karlsson@intel.com + Changed Files: net/xdp/xsk_queue.h | 24 +++++++++++++-----------; 1 file changed, 13 insertions(+), 11 deletions(-) + Parent Hashes: 4b638f13bab4dbfe8569c84e374e8201a427115c +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Simplify xsk functions by removing unnecessary arguments used in the XDP socket context.", + "keywords": "xsk,simplify,functions", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Simplify XDP socket functions by removing redundant arguments.", + "keywords": "xsk,simplify,XDP", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 789/6895 - Commit ID: 4b638f13bab4dbfe8569c84e374e8201a427115c +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 4b638f13bab4dbfe8569c84e374e8201a427115c + Author Name: Magnus Karlsson + Author Email: magnus.karlsson@intel.com + Commit Date: 1576886409 + Commit Message: + xsk: Eliminate the RX batch size In the xsk consumer ring code there is a variable called RX_BATCH_SIZE that dictates the minimum number of entries that we try to grab from the fill and Tx rings. In fact, the code always try to grab the maximum amount of entries from these rings. The only thing this variable does is to throw an error if there is less than 16 (as it is defined) entries on the ring. There is no reason to do this and it will just lead to weird behavior from user space's point of view. So eliminate this variable. With this change, we will be able to simplify the xskq_nb_free and xskq_nb_avail code in the next commit. Signed-off-by: Magnus Karlsson Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/1576759171-28550-6-git-send-email-magnus.karlsson@intel.com + Changed Files: net/xdp/xsk_queue.h | 6 ++----; 1 file changed, 2 insertions(+), 4 deletions(-) + Parent Hashes: 59e35e552529b858f35b30bc5a803ea532ca17f1 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit removes the RX_BATCH_SIZE variable in xsk consumer ring code to avoid unnecessary errors and simplify future code changes.", + "keywords": "RX, batch, xsk", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here." + ] +} +Rethinking... +new content: +{ + "summary": "This commit eliminates the RX_BATCH_SIZE variable from xsk consumer ring to avoid errors and simplify future code.", + "keywords": "RX, xsk, batch", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 790/6895 - Commit ID: 59e35e552529b858f35b30bc5a803ea532ca17f1 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 59e35e552529b858f35b30bc5a803ea532ca17f1 + Author Name: Magnus Karlsson + Author Email: magnus.karlsson@intel.com + Commit Date: 1576886409 + Commit Message: + xsk: Standardize naming of producer ring access functions Adopt the naming of the producer ring access functions to have a similar naming convention as the functions in libbpf, but adapted to the kernel. You first reserve a number of entries that you later submit to the global state of the ring. This is much clearer, IMO, than the one that was in the kernel part. Once renamed, we also discover that two functions are actually the same, so remove one of them. Some of the primitive ring submission operations are also the same so break these out into __xskq_prod_submit that the upper level ring access functions can use. Signed-off-by: Magnus Karlsson Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/1576759171-28550-5-git-send-email-magnus.karlsson@intel.com + Changed Files: net/xdp/xsk.c | 20 +++++++++---------; net/xdp/xsk_queue.h | 58 +++++++++++++++++++++++++----------------------------; 2 files changed, 37 insertions(+), 41 deletions(-) + Parent Hashes: d7012f05e3ca5aba92770c370895092d4882e8c2 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit standardizes the naming of producer ring access functions in xsk to align with libbpf and removes redundant functions.", + "keywords": "xsk,naming,standardize", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +Rethinking... +new content: +{ + "summary": "This commit refactors xsk producer ring access functions to standardize naming and improve clarity by removing redundancies.", + "keywords": "xsk,naming,refactor", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +-------------------- +-------------------- +Processing Commit 791/6895 - Commit ID: d7012f05e3ca5aba92770c370895092d4882e8c2 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: d7012f05e3ca5aba92770c370895092d4882e8c2 + Author Name: Magnus Karlsson + Author Email: magnus.karlsson@intel.com + Commit Date: 1576886409 + Commit Message: + xsk: Consolidate to one single cached producer pointer Currently, the xsk ring code has two cached producer pointers: prod_head and prod_tail. This patch consolidates these two into a single one called cached_prod to make the code simpler and easier to maintain. This will be in line with the user space part of the the code found in libbpf, that only uses a single cached pointer. The Rx path only uses the two top level functions xskq_produce_batch_desc and xskq_produce_flush_desc and they both use prod_head and never prod_tail. So just move them over to cached_prod. The Tx XDP_DRV path uses xskq_produce_addr_lazy and xskq_produce_flush_addr_n and unnecessarily operates on both prod_tail and prod_head, so move them over to just use cached_prod by skipping the intermediate step of updating prod_tail. The Tx path in XDP_SKB mode uses xskq_reserve_addr and xskq_produce_addr. They currently use both cached pointers, but we can operate on the global producer pointer in xskq_produce_addr since it has to be updated anyway, thus eliminating the use of both cached pointers. We can also remove the xskq_nb_free in xskq_produce_addr since it is already called in xskq_reserve_addr. No need to do it twice. When there is only one cached producer pointer, we can also simplify xskq_nb_free by removing one argument. Signed-off-by: Magnus Karlsson Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/1576759171-28550-4-git-send-email-magnus.karlsson@intel.com + Changed Files: net/xdp/xsk_queue.h | 47 +++++++++++++++++++++--------------------------; 1 file changed, 21 insertions(+), 26 deletions(-) + Parent Hashes: 11cc2d21499cabe7e7964389634ed1de3ee91d33 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Simplifies the xsk ring code by consolidating producer pointers into a single cached_prod for improved maintainability.", + "keywords": "xsk, cached_prod, ring", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Simplifies the xsk ring code by consolidating producer pointers into a single cached_prod for improved maintainability.", + "keywords": "xsk,cached_prod,ring", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 792/6895 - Commit ID: 11cc2d21499cabe7e7964389634ed1de3ee91d33 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 11cc2d21499cabe7e7964389634ed1de3ee91d33 + Author Name: Magnus Karlsson + Author Email: magnus.karlsson@intel.com + Commit Date: 1576886408 + Commit Message: + xsk: Simplify detection of empty and full rings In order to set the correct return flags for poll, the xsk code has to check if the Rx queue is empty and if the Tx queue is full. This code was unnecessarily large and complex as it used the functions that are used to update the local state from the global state (xskq_nb_free and xskq_nb_avail). Since we are not doing this nor updating any data dependent on this state, we can simplify the functions. Another benefit from this is that we can also simplify the xskq_nb_free and xskq_nb_avail functions in a later commit. Signed-off-by: Magnus Karlsson Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/1576759171-28550-3-git-send-email-magnus.karlsson@intel.com + Changed Files: net/xdp/xsk_queue.h | 7 +++++--; 1 file changed, 5 insertions(+), 2 deletions(-) + Parent Hashes: 484b165306e18fd9a0d960e6ed2d6eff31665522 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit simplifies detection of empty and full rings by reducing complex code in the xsk module.", + "keywords": "simplify,rings,xsk", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "This commit refactors xsk code to simplify the detection of empty and full rings in the XDP socket implementation.", + "keywords": "simplify,empty,full", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 793/6895 - Commit ID: 484b165306e18fd9a0d960e6ed2d6eff31665522 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 484b165306e18fd9a0d960e6ed2d6eff31665522 + Author Name: Magnus Karlsson + Author Email: magnus.karlsson@intel.com + Commit Date: 1576886408 + Commit Message: + xsk: Eliminate the lazy update threshold The lazy update threshold was introduced to keep the producer and consumer some distance apart in the completion ring. This was important in the beginning of the development of AF_XDP as the ring format as that point in time was very sensitive to the producer and consumer being on the same cache line. This is not the case anymore as the current ring format does not degrade in any noticeable way when this happens. Moreover, this threshold makes it impossible to run the system with rings that have less than 128 entries. So let us remove this threshold and just get one entry from the ring as in all other functions. This will enable us to remove this function in a later commit. Note that xskq_produce_addr_lazy followed by xskq_produce_flush_addr_n are still not the same function as xskq_produce_addr() as it operates on another cached pointer. Signed-off-by: Magnus Karlsson Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/1576759171-28550-2-git-send-email-magnus.karlsson@intel.com + Changed Files: net/xdp/xsk_queue.h | 3 +--; 1 file changed, 1 insertion(+), 2 deletions(-) + Parent Hashes: 99cacdc6f661f50f44a0ef006a1a3db20c0577f6 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Remove the lazy update threshold to enable AF_XDP to operate with smaller ring sizes.", + "keywords": "xsk threshold removal", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "Remove the lazy update threshold from AF_XDP to support smaller ring sizes.", + "keywords": "xsk lazy update", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 794/6895 - Commit ID: a75af86b6f344f99825cc894596804a91a2ee9cf +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: a75af86b6f344f99825cc894596804a91a2ee9cf + Author Name: Arnaldo Carvalho de Melo + Author Email: acme@redhat.com + Commit Date: 1576878940 + Commit Message: + perf map: Set kmap->kmaps backpointer for main kernel map chunks When a map is create to represent the main kernel area (vmlinux) with map__new2() we allocate an extra area to store a pointer to the 'struct maps' for the kernel maps, so that we can access that struct when loading ELF files or kallsyms, as we will need to split it in multiple maps, one per kernel module or ELF section (such as ".init.text"). So when map->dso->kernel is non-zero, it is expected that map__kmap(map)->kmaps to be set to the tree of kernel maps (modules, chunks of the main kernel, bpf progs put in place via PERF_RECORD_KSYMBOL, the main kernel). This was not the case when we were splitting the main kernel into chunks for its ELF sections, which ended up making 'perf report --children' processing a perf.data file with callchains to trip on __map__is_kernel(), when we press ENTER to see the popup menu for main histogram entries that starts at a symbol in the ".init.text" ELF section, e.g.: - 8.83% 0.00% swapper [kernel.vmlinux].init.text [k] start_kernel start_kernel cpu_startup_entry do_idle cpuidle_enter cpuidle_enter_state intel_idle Fix it. Reviewed-by: Jiri Olsa Cc: Adrian Hunter Cc: Namhyung Kim Link: https://lore.kernel.org/lkml/20191218190120.GB13282@kernel.org/ Signed-off-by: Arnaldo Carvalho de Melo + Changed Files: tools/perf/util/symbol-elf.c | 3 +++; 1 file changed, 3 insertions(+) + Parent Hashes: 0feba17bd7ee3b7e03d141f119049dcc23efa94e +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes the backpointer setup in perf maps for kernel map chunks to properly handle ELF sections in 'perf report'.", + "keywords": "perf, kernel, ELF", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes the backpointer setup in perf maps for kernel map chunks to properly handle ELF sections in 'perf report'.", + "keywords": "perf,kernel,ELF", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +-------------------- +-------------------- +Processing Commit 795/6895 - Commit ID: 99cacdc6f661f50f44a0ef006a1a3db20c0577f6 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 99cacdc6f661f50f44a0ef006a1a3db20c0577f6 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1576819420 + Commit Message: + Merge branch 'replace-cg_bpf-prog' Andrey Ignatov says: ==================== v3->v4: - use OPTS_VALID and OPTS_GET to handle bpf_prog_attach_opts. v2->v3: - rely on DECLARE_LIBBPF_OPTS from libbpf_common.h; - separate "required" and "optional" arguments in bpf_prog_attach_xattr; - convert test_cgroup_attach to prog_tests; - move the new selftest to prog_tests/cgroup_attach_multi. v1->v2: - move DECLARE_LIBBPF_OPTS from libbpf.h to bpf.h (patch 4); - switch new libbpf API to OPTS framework; - switch selftest to libbpf OPTS framework. This patch set adds support for replacing cgroup-bpf programs attached with BPF_F_ALLOW_MULTI flag so that any program in a list can be updated to a new version without service interruption and order of programs can be preserved. Please see patch 3 for details on the use-case and API changes. Other patches: Patch 1 is preliminary refactoring of __cgroup_bpf_attach to simplify it. Patch 2 is minor cleanup of hierarchy_allows_attach. Patch 4 extends libbpf API to support new set of attach attributes. Patch 5 converts test_cgroup_attach to prog_tests. Patch 6 adds selftest coverage for the new API. ==================== Signed-off-by: Alexei Starovoitov + Changed Files: nan + Parent Hashes: c92bbaa0fda587c6f2397dc7d31f7f3b7b49fa77 06ac0186bd242d44f5703ce64ee0077b317c86bb +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit merges updates for replacing cgroup-bpf programs with new libbpf API and selftests support.", + "keywords": "merge,cgroup-bpf,libbpf", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups)." + ] +} +Rethinking... +new content: +{ + "summary": "The commit integrates updates for replacing cgroup-bpf programs with new libbpf API support and selftests.", + "keywords": "cgroup-bpf,libbpf,merge", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups)." + ] +} +-------------------- +-------------------- +Processing Commit 796/6895 - Commit ID: 06ac0186bd242d44f5703ce64ee0077b317c86bb +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 06ac0186bd242d44f5703ce64ee0077b317c86bb + Author Name: Andrey Ignatov + Author Email: rdna@fb.com + Commit Date: 1576819346 + Commit Message: + selftests/bpf: Test BPF_F_REPLACE in cgroup_attach_multi Test replacing a cgroup-bpf program attached with BPF_F_ALLOW_MULTI and possible failure modes: invalid combination of flags, invalid replace_bpf_fd, replacing a non-attachd to specified cgroup program. Example of program replacing: # gdb -q --args ./test_progs --name=cgroup_attach_multi ... Breakpoint 1, test_cgroup_attach_multi () at cgroup_attach_multi.c:227 (gdb) [1]+ Stopped gdb -q --args ./test_progs --name=cgroup_attach_multi # bpftool c s /mnt/cgroup2/cgroup-test-work-dir/cg1 ID AttachType AttachFlags Name 2133 egress multi 2134 egress multi # fg gdb -q --args ./test_progs --name=cgroup_attach_multi (gdb) c Continuing. Breakpoint 2, test_cgroup_attach_multi () at cgroup_attach_multi.c:233 (gdb) [1]+ Stopped gdb -q --args ./test_progs --name=cgroup_attach_multi # bpftool c s /mnt/cgroup2/cgroup-test-work-dir/cg1 ID AttachType AttachFlags Name 2139 egress multi 2134 egress multi Signed-off-by: Andrey Ignatov Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/7b9b83e8d5fb82e15b034341bd40b6fb2431eeba.1576741281.git.rdna@fb.com + Changed Files: .../selftests/bpf/prog_tests/cgroup_attach_multi.c | 53 ++++++++++++++++++++--; 1 file changed, 50 insertions(+), 3 deletions(-) + Parent Hashes: 257c88559f360ef40d251942f1f9f0c55f5f91ca +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds tests for replacing cgroup-bpf programs with the BPF_F_REPLACE flag and handling various failure scenarios.", + "keywords": "BPF_F_REPLACE,cgroup-bpf,test", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups)." + ] +} +Rethinking... +new content: +{ + "summary": "The commit enhances testing for replacing cgroup-bpf programs using BPF_F_REPLACE and handles specific failure modes.", + "keywords": "BPF_F_REPLACE,test,cgroup-bpf", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups)." + ] +} +-------------------- +-------------------- +Processing Commit 797/6895 - Commit ID: 257c88559f360ef40d251942f1f9f0c55f5f91ca +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 257c88559f360ef40d251942f1f9f0c55f5f91ca + Author Name: Andrey Ignatov + Author Email: rdna@fb.com + Commit Date: 1576819346 + Commit Message: + selftests/bpf: Convert test_cgroup_attach to prog_tests Convert test_cgroup_attach to prog_tests. This change does a lot of things but in many cases it's pretty expensive to separate them, so they go in one commit. Nevertheless the logic is ketp as is and changes made are just moving things around, simplifying them (w/o changing the meaning of the tests) and making prog_tests compatible: * split the 3 tests in the file into 3 separate files in prog_tests/; * rename the test functions to test_; * remove unused includes, constants, variables and functions from every test; * replace `if`-s with or `if (CHECK())` where additional context should be logged and with `if (CHECK_FAIL())` where line number is enough; * switch from `log_err()` to logging via `CHECK()`; * replace `assert`-s with `CHECK_FAIL()` to avoid crashing the whole test_progs if one assertion fails; * replace cgroup_helpers with test__join_cgroup() in cgroup_attach_override only, other tests need more fine-grained control for cgroup creation/deletion so cgroup_helpers are still used there; * simplify cgroup_attach_autodetach by switching to easiest possible program since this test doesn't really need such a complicated program as cgroup_attach_multi does; * remove test_cgroup_attach.c itself. Signed-off-by: Andrey Ignatov Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/0ff19cc64d2dc5cf404349f07131119480e10e32.1576741281.git.rdna@fb.com + Changed Files: tools/testing/selftests/bpf/.gitignore | 1 -; tools/testing/selftests/bpf/Makefile | 3 +-; .../bpf/prog_tests/cgroup_attach_autodetach.c | 111 ++++; .../selftests/bpf/prog_tests/cgroup_attach_multi.c | 238 +++++++++; .../bpf/prog_tests/cgroup_attach_override.c | 148 ++++++; tools/testing/selftests/bpf/test_cgroup_attach.c | 571 ---------------------; 6 files changed, 498 insertions(+), 574 deletions(-) + Parent Hashes: cdbee3839cd91a4577425c43cf064b9523926159 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit refactors selftests by converting test_cgroup_attach into prog_tests, enhancing structure without altering logic.", + "keywords": "refactor,selftests,prog_tests", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups)." + ] +} +Rethinking... +new content: +{ + "summary": "The commit refactors selftests by converting test_cgroup_attach into prog_tests and reorganizing related test files for better maintainability.", + "keywords": "refactor,selftests,prog_tests", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups)." + ] +} +-------------------- +-------------------- +Processing Commit 798/6895 - Commit ID: cdbee3839cd91a4577425c43cf064b9523926159 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: cdbee3839cd91a4577425c43cf064b9523926159 + Author Name: Andrey Ignatov + Author Email: rdna@fb.com + Commit Date: 1576819345 + Commit Message: + libbpf: Introduce bpf_prog_attach_xattr Introduce a new bpf_prog_attach_xattr function that, in addition to program fd, target fd and attach type, accepts an extendable struct bpf_prog_attach_opts. bpf_prog_attach_opts relies on DECLARE_LIBBPF_OPTS macro to maintain backward and forward compatibility and has the following "optional" attach attributes: * existing attach_flags, since it's not required when attaching in NONE mode. Even though it's quite often used in MULTI and OVERRIDE mode it seems to be a good idea to reduce number of arguments to bpf_prog_attach_xattr; * newly introduced attribute of BPF_PROG_ATTACH command: replace_prog_fd that is fd of previously attached cgroup-bpf program to replace if BPF_F_REPLACE flag is used. The new function is named to be consistent with other xattr-functions (bpf_prog_test_run_xattr, bpf_create_map_xattr, bpf_load_program_xattr). The struct bpf_prog_attach_opts is supposed to be used with DECLARE_LIBBPF_OPTS macro. Signed-off-by: Andrey Ignatov Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/bd6e0732303eb14e4b79cb128268d9e9ad6db208.1576741281.git.rdna@fb.com + Changed Files: tools/lib/bpf/bpf.c | 17 ++++++++++++++++-; tools/lib/bpf/bpf.h | 11 +++++++++++; tools/lib/bpf/libbpf.map | 1 +; 3 files changed, 28 insertions(+), 1 deletion(-) + Parent Hashes: 7dd68b3279f1792103d12e69933db3128c6d416e +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit introduces a new bpf_prog_attach_xattr function to handle program attachment with extendable options in the libbpf library.", + "keywords": "bpf_prog_attach_xattr,libbpf,attach", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups)." + ] +} +Rethinking... +new content: +{ + "summary": "This commit introduces a new bpf_prog_attach_xattr function to the libbpf library for program attachment with extended options.", + "keywords": "bpf_prog_attach_xattr,libbpf,attach", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups)." + ] +} +-------------------- +-------------------- +Processing Commit 799/6895 - Commit ID: 7dd68b3279f1792103d12e69933db3128c6d416e +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 7dd68b3279f1792103d12e69933db3128c6d416e + Author Name: Andrey Ignatov + Author Email: rdna@fb.com + Commit Date: 1576819345 + Commit Message: + bpf: Support replacing cgroup-bpf program in MULTI mode The common use-case in production is to have multiple cgroup-bpf programs per attach type that cover multiple use-cases. Such programs are attached with BPF_F_ALLOW_MULTI and can be maintained by different people. Order of programs usually matters, for example imagine two egress programs: the first one drops packets and the second one counts packets. If they're swapped the result of counting program will be different. It brings operational challenges with updating cgroup-bpf program(s) attached with BPF_F_ALLOW_MULTI since there is no way to replace a program: * One way to update is to detach all programs first and then attach the new version(s) again in the right order. This introduces an interruption in the work a program is doing and may not be acceptable (e.g. if it's egress firewall); * Another way is attach the new version of a program first and only then detach the old version. This introduces the time interval when two versions of same program are working, what may not be acceptable if a program is not idempotent. It also imposes additional burden on program developers to make sure that two versions of their program can co-exist. Solve the problem by introducing a "replace" mode in BPF_PROG_ATTACH command for cgroup-bpf programs being attached with BPF_F_ALLOW_MULTI flag. This mode is enabled by newly introduced BPF_F_REPLACE attach flag and bpf_attr.replace_bpf_fd attribute to pass fd of the old program to replace That way user can replace any program among those attached with BPF_F_ALLOW_MULTI flag without the problems described above. Details of the new API: * If BPF_F_REPLACE is set but replace_bpf_fd doesn't have valid descriptor of BPF program, BPF_PROG_ATTACH will return corresponding error (EINVAL or EBADF). * If replace_bpf_fd has valid descriptor of BPF program but such a program is not attached to specified cgroup, BPF_PROG_ATTACH will return ENOENT. BPF_F_REPLACE is introduced to make the user intent clear, since replace_bpf_fd alone can't be used for this (its default value, 0, is a valid fd). BPF_F_REPLACE also makes it possible to extend the API in the future (e.g. add BPF_F_BEFORE and BPF_F_AFTER if needed). Signed-off-by: Andrey Ignatov Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Acked-by: Andrii Narkyiko Link: https://lore.kernel.org/bpf/30cd850044a0057bdfcaaf154b7d2f39850ba813.1576741281.git.rdna@fb.com + Changed Files: include/linux/bpf-cgroup.h | 4 +++-; include/uapi/linux/bpf.h | 10 ++++++++++; kernel/bpf/cgroup.c | 30 ++++++++++++++++++++++++++----; kernel/bpf/syscall.c | 4 ++--; kernel/cgroup/cgroup.c | 5 +++--; tools/include/uapi/linux/bpf.h | 10 ++++++++++; 6 files changed, 54 insertions(+), 9 deletions(-) + Parent Hashes: 9fab329d6a04c0a52a84d207b5e0d83aeb660aa0 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Adds a replace mode for updating cgroup-bpf programs in MULTI mode to avoid program coexistence issues.", + "keywords": "replace,cgroup,bpf", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The syscall interface. It changes the system calls through which user-space programs interact with eBPF.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups)." + ] +} +Rethinking... +new content: +{ + "summary": "Adds a replace mode for updating cgroup-bpf programs in MULTI mode to avoid program coexistence issues.", + "keywords": "replace,cgroup,bpf", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The syscall interface. It changes the system calls through which user-space programs interact with eBPF.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups)." + ] +} +-------------------- +-------------------- +Processing Commit 800/6895 - Commit ID: 9fab329d6a04c0a52a84d207b5e0d83aeb660aa0 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 9fab329d6a04c0a52a84d207b5e0d83aeb660aa0 + Author Name: Andrey Ignatov + Author Email: rdna@fb.com + Commit Date: 1576819345 + Commit Message: + bpf: Remove unused new_flags in hierarchy_allows_attach() new_flags is unused, remove it. Signed-off-by: Andrey Ignatov Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/2c49b30ab750f93cfef04a1e40b097d70c3a39a1.1576741281.git.rdna@fb.com + Changed Files: kernel/bpf/cgroup.c | 5 ++---; 1 file changed, 2 insertions(+), 3 deletions(-) + Parent Hashes: 1020c1f24a946e7d5d8a67db741b20efcd2cefc5 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Removed the unused variable 'new_flags' from hierarchy_allows_attach function.", + "keywords": "bpf, new_flags, unused", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups)." + ] +} +Rethinking... +new content: +{ + "summary": "Removed the unused variable 'new_flags' from hierarchy_allows_attach function in cgroup.c.", + "keywords": "bpf, unused, new_flags", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups)." + ] +} +-------------------- +-------------------- +Processing Commit 801/6895 - Commit ID: 1020c1f24a946e7d5d8a67db741b20efcd2cefc5 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 1020c1f24a946e7d5d8a67db741b20efcd2cefc5 + Author Name: Andrey Ignatov + Author Email: rdna@fb.com + Commit Date: 1576819345 + Commit Message: + bpf: Simplify __cgroup_bpf_attach __cgroup_bpf_attach has a lot of identical code to handle two scenarios: BPF_F_ALLOW_MULTI is set and unset. Simplify it by splitting the two main steps: * First, the decision is made whether a new bpf_prog_list entry should be allocated or existing entry should be reused for the new program. This decision is saved in replace_pl pointer; * Next, replace_pl pointer is used to handle both possible states of BPF_F_ALLOW_MULTI flag (set / unset) instead of doing similar work for them separately. This splitting, in turn, allows to make further simplifications: * The check for attaching same program twice in BPF_F_ALLOW_MULTI mode can be done before allocating cgroup storage, so that if user tries to attach same program twice no alloc/free happens as it was before; * pl_was_allocated becomes redundant so it's removed. Signed-off-by: Andrey Ignatov Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/c6193db6fe630797110b0d3ff06c125d093b834c.1576741281.git.rdna@fb.com + Changed Files: kernel/bpf/cgroup.c | 62 ++++++++++++++++++++---------------------------------; 1 file changed, 23 insertions(+), 39 deletions(-) + Parent Hashes: c92bbaa0fda587c6f2397dc7d31f7f3b7b49fa77 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit simplifies the __cgroup_bpf_attach function by splitting decision-making and cleanup for the BPF_F_ALLOW_MULTI flag handling.", + "keywords": "simplify,cgroup,bpf", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups)." + ] +} +Rethinking... +new content: +{ + "summary": "The commit refactors the __cgroup_bpf_attach function by consolidating logic for handling BPF_F_ALLOW_MULTI flag scenarios.", + "keywords": "refactor,cgroup,attach", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The syscall interface. It changes the system calls through which user-space programs interact with eBPF.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups)." + ] +} +-------------------- +-------------------- +Processing Commit 802/6895 - Commit ID: c92bbaa0fda587c6f2397dc7d31f7f3b7b49fa77 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: c92bbaa0fda587c6f2397dc7d31f7f3b7b49fa77 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1576818627 + Commit Message: + Merge branch 'simplify-do_redirect' Björn Töpel says: ==================== This series aims to simplify the XDP maps and xdp_do_redirect_map()/xdp_do_flush_map(), and to crank out some more performance from XDP_REDIRECT scenarios. The first part of the series simplifies all XDP_REDIRECT capable maps, so that __XXX_flush_map() does not require the map parameter, by moving the flush list from the map to global scope. This results in that the map_to_flush member can be removed from struct bpf_redirect_info, and its corresponding logic. Simpler code, and more performance due to that checks/code per-packet is moved to flush. Pre-series performance: $ sudo taskset -c 22 ./xdpsock -i enp134s0f0 -q 20 -n 1 -r -z sock0@enp134s0f0:20 rxdrop xdp-drv pps pkts 1.00 rx 20,797,350 230,942,399 tx 0 0 $ sudo ./xdp_redirect_cpu --dev enp134s0f0 --cpu 22 xdp_cpu_map0 Running XDP/eBPF prog_name:xdp_cpu_map5_lb_hash_ip_pairs XDP-cpumap CPU:to pps drop-pps extra-info XDP-RX 20 7723038 0 0 XDP-RX total 7723038 0 cpumap_kthread total 0 0 0 redirect_err total 0 0 xdp_exception total 0 0 Post-series performance: $ sudo taskset -c 22 ./xdpsock -i enp134s0f0 -q 20 -n 1 -r -z sock0@enp134s0f0:20 rxdrop xdp-drv pps pkts 1.00 rx 21,524,979 86,835,327 tx 0 0 $ sudo ./xdp_redirect_cpu --dev enp134s0f0 --cpu 22 xdp_cpu_map0 Running XDP/eBPF prog_name:xdp_cpu_map5_lb_hash_ip_pairs XDP-cpumap CPU:to pps drop-pps extra-info XDP-RX 20 7840124 0 0 XDP-RX total 7840124 0 cpumap_kthread total 0 0 0 redirect_err total 0 0 xdp_exception total 0 0 Results: +3.5% and +1.5% for the ubenchmarks. v1->v2 [1]: * Removed 'unused-variable' compiler warning (Jakub) [1] https://lore.kernel.org/bpf/20191218105400.2895-1-bjorn.topel@gmail.com/ ==================== Signed-off-by: Alexei Starovoitov + Changed Files: nan + Parent Hashes: 5bf2fc1f9c88397b125d5ec5f65b1ed9300ba59d 1170beaa3fa3c3381fd820e9d05b84d168fe1dab +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges a branch that simplifies XDP maps, improving performance and code simplicity in XDP_REDIRECT scenarios.", + "keywords": "XDP maps performance", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges a branch that simplifies and optimizes XDP_REDIRECT scenarios for better performance.", + "keywords": "XDP merge performance", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +-------------------- +-------------------- +Processing Commit 803/6895 - Commit ID: 1170beaa3fa3c3381fd820e9d05b84d168fe1dab +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 1170beaa3fa3c3381fd820e9d05b84d168fe1dab + Author Name: Björn Töpel + Author Email: bjorn.topel@intel.com + Commit Date: 1576818583 + Commit Message: + xdp: Simplify __bpf_tx_xdp_map() The explicit error checking is not needed. Simply return the error instead. Signed-off-by: Björn Töpel Signed-off-by: Alexei Starovoitov Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/20191219061006.21980-9-bjorn.topel@gmail.com + Changed Files: net/core/filter.c | 33 +++++++--------------------------; 1 file changed, 7 insertions(+), 26 deletions(-) + Parent Hashes: 332f22a60e4c3492d4953cd6f7aaa4e8bd0bba97 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit simplifies the __bpf_tx_xdp_map function by removing explicit error checking and directly returning the error.", + "keywords": "simplify,error checking,__bpf_tx_xdp_map", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +Rethinking... +new content: +{ + "summary": "The commit simplifies the __bpf_tx_xdp_map function by removing explicit error checking and directly returning the error.", + "keywords": "simplify,error checking,__bpf_tx_xdp_map", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +-------------------- +-------------------- +Processing Commit 804/6895 - Commit ID: 332f22a60e4c3492d4953cd6f7aaa4e8bd0bba97 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 332f22a60e4c3492d4953cd6f7aaa4e8bd0bba97 + Author Name: Björn Töpel + Author Email: bjorn.topel@intel.com + Commit Date: 1576818583 + Commit Message: + xdp: Remove map_to_flush and map swap detection Now that all XDP maps that can be used with bpf_redirect_map() tracks entries to be flushed in a global fashion, there is not need to track that the map has changed and flush from xdp_do_generic_map() anymore. All entries will be flushed in xdp_do_flush_map(). This means that the map_to_flush can be removed, and the corresponding checks. Moving the flush logic to one place, xdp_do_flush_map(), give a bulking behavior and performance boost. Signed-off-by: Björn Töpel Signed-off-by: Alexei Starovoitov Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/20191219061006.21980-8-bjorn.topel@gmail.com + Changed Files: include/linux/filter.h | 1 -; net/core/filter.c | 27 +++------------------------; 2 files changed, 3 insertions(+), 25 deletions(-) + Parent Hashes: cdfafe98cabefeedbbc65af5c191c59745c03298 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit improves performance by removing map_to_flush and consolidating flush logic in xdp_do_flush_map for XDP maps used with bpf_redirect_map.", + "keywords": "xdp,flush,performance", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit improves the XDP flush logic by centralizing it in xdp_do_flush_map and removing obsolete code for better performance.", + "keywords": "xdp,flush,performance", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 805/6895 - Commit ID: cdfafe98cabefeedbbc65af5c191c59745c03298 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: cdfafe98cabefeedbbc65af5c191c59745c03298 + Author Name: Björn Töpel + Author Email: bjorn.topel@intel.com + Commit Date: 1576818583 + Commit Message: + xdp: Make cpumap flush_list common for all map instances The cpumap flush list is used to track entries that need to flushed from via the xdp_do_flush_map() function. This list used to be per-map, but there is really no reason for that. Instead make the flush list global for all devmaps, which simplifies __cpu_map_flush() and cpu_map_alloc(). Signed-off-by: Björn Töpel Signed-off-by: Alexei Starovoitov Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/20191219061006.21980-7-bjorn.topel@gmail.com + Changed Files: include/linux/bpf.h | 4 ++--; kernel/bpf/cpumap.c | 36 ++++++++++++++++++------------------; net/core/filter.c | 2 +-; 3 files changed, 21 insertions(+), 21 deletions(-) + Parent Hashes: 96360004b8628541f5d05a845ea213267db0b1a2 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit makes the cpumap flush list global for all map instances to simplify related functions.", + "keywords": "cpumap, flush, global", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +Rethinking... +new content: +{ + "summary": "The commit makes the cpumap flush list global for all map instances to simplify related functions.", + "keywords": "cpumap, flush, global", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +-------------------- +-------------------- +Processing Commit 806/6895 - Commit ID: 96360004b8628541f5d05a845ea213267db0b1a2 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 96360004b8628541f5d05a845ea213267db0b1a2 + Author Name: Björn Töpel + Author Email: bjorn.topel@intel.com + Commit Date: 1576818583 + Commit Message: + xdp: Make devmap flush_list common for all map instances The devmap flush list is used to track entries that need to flushed from via the xdp_do_flush_map() function. This list used to be per-map, but there is really no reason for that. Instead make the flush list global for all devmaps, which simplifies __dev_map_flush() and dev_map_init_map(). Signed-off-by: Björn Töpel Signed-off-by: Alexei Starovoitov Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/20191219061006.21980-6-bjorn.topel@gmail.com + Changed Files: include/linux/bpf.h | 4 ++--; kernel/bpf/devmap.c | 35 +++++++++++++----------------------; net/core/filter.c | 2 +-; 3 files changed, 16 insertions(+), 25 deletions(-) + Parent Hashes: e312b9e706ed6d94f6cc9088fcd9fbd81de4525c +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit makes the devmap flush list global across all map instances for simplified flushing logic in xdp.", + "keywords": "devmap, xdp, flush", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +Rethinking... +new content: +{ + "summary": "The commit refactors the devmap flush list to be global across all map instances for XDP programs.", + "keywords": "devmap, XDP, flushlist", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 807/6895 - Commit ID: e312b9e706ed6d94f6cc9088fcd9fbd81de4525c +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: e312b9e706ed6d94f6cc9088fcd9fbd81de4525c + Author Name: Björn Töpel + Author Email: bjorn.topel@intel.com + Commit Date: 1576818583 + Commit Message: + xsk: Make xskmap flush_list common for all map instances The xskmap flush list is used to track entries that need to flushed from via the xdp_do_flush_map() function. This list used to be per-map, but there is really no reason for that. Instead make the flush list global for all xskmaps, which simplifies __xsk_map_flush() and xsk_map_alloc(). Signed-off-by: Björn Töpel Signed-off-by: Alexei Starovoitov Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/20191219061006.21980-5-bjorn.topel@gmail.com + Changed Files: include/net/xdp_sock.h | 11 ++++-------; kernel/bpf/xskmap.c | 18 +++---------------; net/core/filter.c | 9 ++++-----; net/xdp/xsk.c | 17 +++++++++--------; 4 files changed, 20 insertions(+), 35 deletions(-) + Parent Hashes: fb5aacdf3603ccbafe1da74eecd132eb4a31e53f +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit makes the xskmap flush list global for all map instances to simplify xsk_map_flush and allocation processes.", + "keywords": "xskmap, flush, global", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit makes the xskmap flush list global for all map instances to simplify xsk_map_flush and allocation processes.", + "keywords": "xskmap, flush, global", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 808/6895 - Commit ID: fb5aacdf3603ccbafe1da74eecd132eb4a31e53f +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: fb5aacdf3603ccbafe1da74eecd132eb4a31e53f + Author Name: Björn Töpel + Author Email: bjorn.topel@intel.com + Commit Date: 1576818583 + Commit Message: + xdp: Fix graze->grace type-o in cpumap comments Simple spelling fix. Signed-off-by: Björn Töpel Signed-off-by: Alexei Starovoitov Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/20191219061006.21980-4-bjorn.topel@gmail.com + Changed Files: kernel/bpf/cpumap.c | 6 +++---; 1 file changed, 3 insertions(+), 3 deletions(-) + Parent Hashes: 4bc188c7f23a5a308d7f15dda1b6a286d74e8954 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes a typographical error in the cpumap comments in the xdp code.", + "keywords": "xdp,cpumap,spelling", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "I'm not sure about the logic component of the commit. The affected logic component is unclear.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes a typographical error in xdp cpumap comments.", + "keywords": "xdp,cpumap,typo", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 809/6895 - Commit ID: 4bc188c7f23a5a308d7f15dda1b6a286d74e8954 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 4bc188c7f23a5a308d7f15dda1b6a286d74e8954 + Author Name: Björn Töpel + Author Email: bjorn.topel@intel.com + Commit Date: 1576818583 + Commit Message: + xdp: Simplify cpumap cleanup After the RCU flavor consolidation [1], call_rcu() and synchronize_rcu() waits for preempt-disable regions (NAPI) in addition to the read-side critical sections. As a result of this, the cleanup code in cpumap can be simplified * There is no longer a need to flush in __cpu_map_entry_free, since we know that this has been done when the call_rcu() callback is triggered. * When freeing the map, there is no need to explicitly wait for a flush. It's guaranteed to be done after the synchronize_rcu() call in cpu_map_free(). [1] https://lwn.net/Articles/777036/ Signed-off-by: Björn Töpel Signed-off-by: Alexei Starovoitov Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/20191219061006.21980-3-bjorn.topel@gmail.com + Changed Files: kernel/bpf/cpumap.c | 34 +++++-----------------------------; 1 file changed, 5 insertions(+), 29 deletions(-) + Parent Hashes: 0536b85239b8440735cdd910aae0eb076ebbb439 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit simplifies the cleanup code in the cpumap by leveraging RCU consolidation changes, removing unnecessary flushes during map entry freeing.", + "keywords": "cpumap,cleanup,RCU", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +Rethinking... +new content: +{ + "summary": "The commit simplifies cpumap cleanup by removing unnecessary flushes due to recent RCU consolidation changes.", + "keywords": "cpumap,cleanup,RCU", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +-------------------- +-------------------- +Processing Commit 810/6895 - Commit ID: 0536b85239b8440735cdd910aae0eb076ebbb439 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 0536b85239b8440735cdd910aae0eb076ebbb439 + Author Name: Björn Töpel + Author Email: bjorn.topel@intel.com + Commit Date: 1576818583 + Commit Message: + xdp: Simplify devmap cleanup After the RCU flavor consolidation [1], call_rcu() and synchronize_rcu() waits for preempt-disable regions (NAPI) in addition to the read-side critical sections. As a result of this, the cleanup code in devmap can be simplified * There is no longer a need to flush in __dev_map_entry_free, since we know that this has been done when the call_rcu() callback is triggered. * When freeing the map, there is no need to explicitly wait for a flush. It's guaranteed to be done after the synchronize_rcu() call in dev_map_free(). The rcu_barrier() is still needed, so that the map is not freed prior the elements. [1] https://lwn.net/Articles/777036/ Signed-off-by: Björn Töpel Signed-off-by: Alexei Starovoitov Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/20191219061006.21980-2-bjorn.topel@gmail.com + Changed Files: kernel/bpf/devmap.c | 43 +++++--------------------------------------; 1 file changed, 5 insertions(+), 38 deletions(-) + Parent Hashes: 5bf2fc1f9c88397b125d5ec5f65b1ed9300ba59d +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit simplifies the devmap cleanup code by removing the need for flushing in __dev_map_entry_free due to RCU improvements.", + "keywords": "devmap, RCU, cleanup", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +Rethinking... +new content: +{ + "summary": "This commit simplifies the devmap cleanup code by removing the need for flushing in __dev_map_entry_free due to RCU improvements.", + "keywords": "devmap, RCU, cleanup", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +-------------------- +-------------------- +Processing Commit 811/6895 - Commit ID: 0fd260056ef84ede8f444c66a3820811691fe884 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 0fd260056ef84ede8f444c66a3820811691fe884 + Author Name: David S. Miller + Author Email: davem@davemloft.net + Commit Date: 1576794047 + Commit Message: + Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf Daniel Borkmann says: ==================== pull-request: bpf 2019-12-19 The following pull-request contains BPF updates for your *net* tree. We've added 10 non-merge commits during the last 8 day(s) which contain a total of 21 files changed, 269 insertions(+), 108 deletions(-). The main changes are: 1) Fix lack of synchronization between xsk wakeup and destroying resources used by xsk wakeup, from Maxim Mikityanskiy. 2) Fix pruning with tail call patching, untrack programs in case of verifier error and fix a cgroup local storage tracking bug, from Daniel Borkmann. 3) Fix clearing skb->tstamp in bpf_redirect() when going from ingress to egress which otherwise cause issues e.g. on fq qdisc, from Lorenz Bauer. 4) Fix compile warning of unused proc_dointvec_minmax_bpf_restricted() when only cBPF is present, from Alexander Lobakin. ==================== Signed-off-by: David S. Miller + Changed Files: nan + Parent Hashes: 6fa9a115fe7ca507ef5618eb753706425741b285 3123d8018d4686cf193806c4e27a9853550ed895 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit merges various BPF updates into the main net tree, including synchronization fixes and warning resolutions.", + "keywords": "BPF,merge,updates", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "The commit merges a series of BPF updates into the net tree, including synchronization fixes and warning resolutions.", + "keywords": "BPF, merge, updates", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 812/6895 - Commit ID: 3123d8018d4686cf193806c4e27a9853550ed895 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 3123d8018d4686cf193806c4e27a9853550ed895 + Author Name: Daniel Borkmann + Author Email: daniel@iogearbox.net + Commit Date: 1576791562 + Commit Message: + bpf: Add further test_verifier cases for record_func_key Expand dummy prog generation such that we can easily check on return codes and add few more test cases to make sure we keep on tracking pruning behavior. # ./test_verifier [...] #1066/p XDP pkt read, pkt_data <= pkt_meta', bad access 1 OK #1067/p XDP pkt read, pkt_data <= pkt_meta', bad access 2 OK Summary: 1580 PASSED, 0 SKIPPED, 0 FAILED Also verified that JIT dump of added test cases looks good. Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/df7200b6021444fd369376d227de917357285b65.1576789878.git.daniel@iogearbox.net + Changed Files: tools/testing/selftests/bpf/test_verifier.c | 43 +++---; .../testing/selftests/bpf/verifier/ref_tracking.c | 6 +-; tools/testing/selftests/bpf/verifier/runtime_jit.c | 151 +++++++++++++++++++++; 3 files changed, 176 insertions(+), 24 deletions(-) + Parent Hashes: cc52d9140aa920d8d61c7f6de3fff5fea6692ea9 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Adds new test cases to verify pruning behavior and return codes in the BPF verifier.", + "keywords": "test,verifier,pruning", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Adds new test cases to verify pruning behavior and return codes in the BPF verifier.", + "keywords": "test,verifier,pruning", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 813/6895 - Commit ID: cc52d9140aa920d8d61c7f6de3fff5fea6692ea9 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: cc52d9140aa920d8d61c7f6de3fff5fea6692ea9 + Author Name: Daniel Borkmann + Author Email: daniel@iogearbox.net + Commit Date: 1576791562 + Commit Message: + bpf: Fix record_func_key to perform backtracking on r3 While testing Cilium with /unreleased/ Linus' tree under BPF-based NodePort implementation, I noticed a strange BPF SNAT engine behavior from time to time. In some cases it would do the correct SNAT/DNAT service translation, but at a random point in time it would just stop and perform an unexpected translation after SYN, SYN/ACK and stack would send a RST back. While initially assuming that there is some sort of a race condition in BPF code, adding trace_printk()s for debugging purposes at some point seemed to have resolved the issue auto-magically. Digging deeper on this Heisenbug and reducing the trace_printk() calls to an absolute minimum, it turns out that a single call would suffice to trigger / not trigger the seen RST issue, even though the logic of the program itself remains unchanged. Turns out the single call changed verifier pruning behavior to get everything to work. Reconstructing a minimal test case, the incorrect JIT dump looked as follows: # bpftool p d j i 11346 0xffffffffc0cba96c: [...] 21: movzbq 0x30(%rdi),%rax 26: cmp $0xd,%rax 2a: je 0x000000000000003a 2c: xor %edx,%edx 2e: movabs $0xffff89cc74e85800,%rsi 38: jmp 0x0000000000000049 3a: mov $0x2,%edx 3f: movabs $0xffff89cc74e85800,%rsi 49: mov -0x224(%rbp),%eax 4f: cmp $0x20,%eax 52: ja 0x0000000000000062 54: add $0x1,%eax 57: mov %eax,-0x224(%rbp) 5d: jmpq 0xffffffffffff6911 62: mov $0x1,%eax [...] Hence, unexpectedly, JIT emitted a direct jump even though retpoline based one would have been needed since in line 2c and 3a we have different slot keys in BPF reg r3. Verifier log of the test case reveals what happened: 0: (b7) r0 = 14 1: (73) *(u8 *)(r1 +48) = r0 2: (71) r0 = *(u8 *)(r1 +48) 3: (15) if r0 == 0xd goto pc+4 R0_w=inv(id=0,umax_value=255,var_off=(0x0; 0xff)) R1=ctx(id=0,off=0,imm=0) R10=fp0 4: (b7) r3 = 0 5: (18) r2 = 0xffff89cc74d54a00 7: (05) goto pc+3 11: (85) call bpf_tail_call#12 12: (b7) r0 = 1 13: (95) exit from 3 to 8: R0_w=inv13 R1=ctx(id=0,off=0,imm=0) R10=fp0 8: (b7) r3 = 2 9: (18) r2 = 0xffff89cc74d54a00 11: safe processed 13 insns (limit 1000000) [...] Second branch is pruned by verifier since considered safe, but issue is that record_func_key() couldn't have seen the index in line 3a and therefore decided that emitting a direct jump at this location was okay. Fix this by reusing our backtracking logic for precise scalar verification in order to prevent pruning on the slot key. This means verifier will track content of r3 all the way backwards and only prune if both scalars were unknown in state equivalence check and therefore poisoned in the first place in record_func_key(). The range is [x,x] in record_func_key() case since the slot always would have to be constant immediate. Correct verification after fix: 0: (b7) r0 = 14 1: (73) *(u8 *)(r1 +48) = r0 2: (71) r0 = *(u8 *)(r1 +48) 3: (15) if r0 == 0xd goto pc+4 R0_w=invP(id=0,umax_value=255,var_off=(0x0; 0xff)) R1=ctx(id=0,off=0,imm=0) R10=fp0 4: (b7) r3 = 0 5: (18) r2 = 0x0 7: (05) goto pc+3 11: (85) call bpf_tail_call#12 12: (b7) r0 = 1 13: (95) exit from 3 to 8: R0_w=invP13 R1=ctx(id=0,off=0,imm=0) R10=fp0 8: (b7) r3 = 2 9: (18) r2 = 0x0 11: (85) call bpf_tail_call#12 12: (b7) r0 = 1 13: (95) exit processed 15 insns (limit 1000000) [...] And correct corresponding JIT dump: # bpftool p d j i 11 0xffffffffc0dc34c4: [...] 21: movzbq 0x30(%rdi),%rax 26: cmp $0xd,%rax 2a: je 0x000000000000003a 2c: xor %edx,%edx 2e: movabs $0xffff9928b4c02200,%rsi 38: jmp 0x0000000000000049 3a: mov $0x2,%edx 3f: movabs $0xffff9928b4c02200,%rsi 49: cmp $0x4,%rdx 4d: jae 0x0000000000000093 4f: and $0x3,%edx 52: mov %edx,%edx 54: cmp %edx,0x24(%rsi) 57: jbe 0x0000000000000093 59: mov -0x224(%rbp),%eax 5f: cmp $0x20,%eax 62: ja 0x0000000000000093 64: add $0x1,%eax 67: mov %eax,-0x224(%rbp) 6d: mov 0x110(%rsi,%rdx,8),%rax 75: test %rax,%rax 78: je 0x0000000000000093 7a: mov 0x30(%rax),%rax 7e: add $0x19,%rax 82: callq 0x000000000000008e 87: pause 89: lfence 8c: jmp 0x0000000000000087 8e: mov %rax,(%rsp) 92: retq 93: mov $0x1,%eax [...] Also explicitly adding explicit env->allow_ptr_leaks to fixup_bpf_calls() since backtracking is enabled under former (direct jumps as well, but use different test). In case of only tracking different map pointers as in c93552c443eb ("bpf: properly enforce index mask to prevent out-of-bounds speculation"), pruning cannot make such short-cuts, neither if there are paths with scalar and non-scalar types as r3. mark_chain_precision() is only needed after we know that register_is_const(). If it was not the case, we already poison the key on first path and non-const key in later paths are not matching the scalar range in regsafe() either. Cilium NodePort testing passes fine as well now. Note, released kernels not affected. Fixes: d2e4c1e6c294 ("bpf: Constant map key tracking for prog array pokes") Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/ac43ffdeb7386c5bd688761ed266f3722bb39823.1576789878.git.daniel@iogearbox.net + Changed Files: kernel/bpf/verifier.c | 8 +++++++-; 1 file changed, 7 insertions(+), 1 deletion(-) + Parent Hashes: 1148f9adbe71415836a18a36c1b4ece999ab0973 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes a bug in the eBPF verifier to enhance the correctness of SNAT/DNAT service translation in Cilium NodePort.", + "keywords": "bpf, verifier, fix", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit addresses a bug in the eBPF verifier to correct translation issues related to SNAT/DNAT in NodePort implementations.", + "keywords": "bpf, verifier, JIT", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 814/6895 - Commit ID: 5bf2fc1f9c88397b125d5ec5f65b1ed9300ba59d +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 5bf2fc1f9c88397b125d5ec5f65b1ed9300ba59d + Author Name: Aditya Pakki + Author Email: pakki001@umn.edu + Commit Date: 1576790655 + Commit Message: + bpf: Remove unnecessary assertion on fp_old The two callers of bpf_prog_realloc - bpf_patch_insn_single and bpf_migrate_filter dereference the struct fp_old, before passing it to the function. Thus assertion to check fp_old is unnecessary and can be removed. Signed-off-by: Aditya Pakki Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191219175735.19231-1-pakki001@umn.edu + Changed Files: kernel/bpf/core.c | 2 --; 1 file changed, 2 deletions(-) + Parent Hashes: 7745ff9842617323adbe24e71c495d5ebd9aa352 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit removes an unnecessary assertion in the bpf_prog_realloc function.", + "keywords": "assertion, bpf_prog_realloc, fp_old", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "I'm not sure about the implementation component of the commit. The component affected by It is unclear.", + "major_related_logic_component": "I'm not sure about the logic component of the commit. The affected logic component is unclear.", + "usecases_or_submodule_events": [ + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +Rethinking... +new content: +{ + "summary": "The commit removes an unnecessary assertion in the bpf_prog_realloc function.", + "keywords": "assertion, bpf_prog_realloc, fp_old", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 815/6895 - Commit ID: 1148f9adbe71415836a18a36c1b4ece999ab0973 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 1148f9adbe71415836a18a36c1b4ece999ab0973 + Author Name: Alexander Lobakin + Author Email: alobakin@dlink.ru + Commit Date: 1576772271 + Commit Message: + net, sysctl: Fix compiler warning when only cBPF is present proc_dointvec_minmax_bpf_restricted() has been firstly introduced in commit 2e4a30983b0f ("bpf: restrict access to core bpf sysctls") under CONFIG_HAVE_EBPF_JIT. Then, this ifdef has been removed in ede95a63b5e8 ("bpf: add bpf_jit_limit knob to restrict unpriv allocations"), because a new sysctl, bpf_jit_limit, made use of it. Finally, this parameter has become long instead of integer with fdadd04931c2 ("bpf: fix bpf_jit_limit knob for PAGE_SIZE >= 64K") and thus, a new proc_dolongvec_minmax_bpf_restricted() has been added. With this last change, we got back to that proc_dointvec_minmax_bpf_restricted() is used only under CONFIG_HAVE_EBPF_JIT, but the corresponding ifdef has not been brought back. So, in configurations like CONFIG_BPF_JIT=y && CONFIG_HAVE_EBPF_JIT=n since v4.20 we have: CC net/core/sysctl_net_core.o net/core/sysctl_net_core.c:292:1: warning: ‘proc_dointvec_minmax_bpf_restricted’ defined but not used [-Wunused-function] 292 | proc_dointvec_minmax_bpf_restricted(struct ctl_table *table, int write, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Suppress this by guarding it with CONFIG_HAVE_EBPF_JIT again. Fixes: fdadd04931c2 ("bpf: fix bpf_jit_limit knob for PAGE_SIZE >= 64K") Signed-off-by: Alexander Lobakin Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191218091821.7080-1-alobakin@dlink.ru + Changed Files: net/core/sysctl_net_core.c | 2 ++; 1 file changed, 2 insertions(+) + Parent Hashes: ca8d0fa7cfb8abc4f623d49df210e0b81b32f626 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes a compiler warning by reintroducing CONFIG_HAVE_EBPF_JIT conditional for proc_dointvec_minmax_bpf_restricted.", + "keywords": "compiler,warning,CONFIG_HAVE_EBPF_JIT", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes a compiler warning by reintroducing CONFIG_HAVE_EBPF_JIT conditional for proc_dointvec_minmax_bpf_restricted.", + "keywords": "compiler,warning,CONFIG_HAVE_EBPF_JIT", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 816/6895 - Commit ID: 7745ff9842617323adbe24e71c495d5ebd9aa352 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 7745ff9842617323adbe24e71c495d5ebd9aa352 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576770476 + Commit Message: + libbpf: Fix another __u64 printf warning Fix yet another printf warning for %llu specifier on ppc64le. This time size_t casting won't work, so cast to verbose `unsigned long long`. Fixes: 166750bc1dd2 ("libbpf: Support libbpf-provided extern variables") Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191219052103.3515-1-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.c | 4 ++--; 1 file changed, 2 insertions(+), 2 deletions(-) + Parent Hashes: b5c7d0d0f7d4a30ae96c1350df677cb849060b7c +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit fixes a printf warning related to the %llu specifier on ppc64le in the libbpf.c file.", + "keywords": "libbpf printf warning", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit fixes a printf warning related to the %llu specifier on ppc64le in the libbpf.c file.", + "keywords": "libbpf printf warning", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 817/6895 - Commit ID: b5c7d0d0f7d4a30ae96c1350df677cb849060b7c +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: b5c7d0d0f7d4a30ae96c1350df677cb849060b7c + Author Name: Toke Høiland-Jørgensen + Author Email: toke@redhat.com + Commit Date: 1576769152 + Commit Message: + libbpf: Fix printing of ulimit value Naresh pointed out that libbpf builds fail on 32-bit architectures because rlimit.rlim_cur is defined as 'unsigned long long' on those architectures. Fix this by using %zu in printf and casting to size_t. Fixes: dc3a2d254782 ("libbpf: Print hint about ulimit when getting permission denied error") Reported-by: Naresh Kamboju Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191219090236.905059-1-toke@redhat.com + Changed Files: tools/lib/bpf/libbpf.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: 580205dd4fe800b1e95be8b6df9e2991f975a8ad +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit fixes a build issue on 32-bit architectures in libbpf by adjusting the printf format for rlimit values.", + "keywords": "libbpf,printf,ulimit", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit fixes a build issue on 32-bit architectures in libbpf by adjusting the printf format for rlimit values.", + "keywords": "libbpf,printf,ulimit", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 818/6895 - Commit ID: ca8d0fa7cfb8abc4f623d49df210e0b81b32f626 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: ca8d0fa7cfb8abc4f623d49df210e0b81b32f626 + Author Name: Daniel Borkmann + Author Email: daniel@iogearbox.net + Commit Date: 1576768853 + Commit Message: + Merge branch 'bpf-fix-xsk-wakeup' Maxim Mikityanskiy says: ==================== This series addresses the issue described in the commit message of the first patch: lack of synchronization between XSK wakeup and destroying the resources used by XSK wakeup. The idea is similar to napi_synchronize. The series contains fixes for the drivers that implement XSK. v2 incorporates changes suggested by Björn: 1. Call synchronize_rcu in Intel drivers only if the XDP program is being unloaded. 2. Don't forget rcu_read_lock when wakeup is called from xsk_poll. 3. Use xs->zc as the condition to call ndo_xsk_wakeup. ==================== Signed-off-by: Daniel Borkmann + Changed Files: nan + Parent Hashes: e47304232b373362228bf233f17bd12b11c9aafc c0fdccfd226a1424683d3000d9e08384391210a2 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit merges changes addressing synchronization issues between XSK wakeup and resource destruction in eBPF programs.", + "keywords": "XSK,wakeup,synchronization", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "The commit merges a branch fixing XSK wakeup and synchronization issues with eBPF programs.", + "keywords": "XSK,wakeup,synchronization", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 819/6895 - Commit ID: c0fdccfd226a1424683d3000d9e08384391210a2 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: c0fdccfd226a1424683d3000d9e08384391210a2 + Author Name: Maxim Mikityanskiy + Author Email: maximmi@mellanox.com + Commit Date: 1576768849 + Commit Message: + net/ixgbe: Fix concurrency issues between config flow and XSK Use synchronize_rcu to wait until the XSK wakeup function finishes before destroying the resources it uses: 1. ixgbe_down already calls synchronize_rcu after setting __IXGBE_DOWN. 2. After switching the XDP program, call synchronize_rcu to let ixgbe_xsk_wakeup exit before the XDP program is freed. 3. Changing the number of channels brings the interface down. 4. Disabling UMEM sets __IXGBE_TX_DISABLED before closing hardware resources and resetting xsk_umem. Check that bit in ixgbe_xsk_wakeup to avoid using the XDP ring when it's already destroyed. synchronize_rcu is called from ixgbe_txrx_ring_disable. Signed-off-by: Maxim Mikityanskiy Signed-off-by: Björn Töpel Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191217162023.16011-5-maximmi@mellanox.com + Changed Files: drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 7 ++++++-; drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c | 8 ++++++--; 2 files changed, 12 insertions(+), 3 deletions(-) + Parent Hashes: b3873a5be757b44d51af542a50a6f2a3b6f95284 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes concurrency issues between configuration flow and XSK in ixgbe by using synchronize_rcu.", + "keywords": "concurrency,XSK,ixgbe", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes concurrency issues between configuration flow and XSK in ixgbe by using synchronize_rcu to manage resources properly.", + "keywords": "concurrency,XSK,synchronize_rcu", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +-------------------- +-------------------- +Processing Commit 820/6895 - Commit ID: b3873a5be757b44d51af542a50a6f2a3b6f95284 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: b3873a5be757b44d51af542a50a6f2a3b6f95284 + Author Name: Maxim Mikityanskiy + Author Email: maximmi@mellanox.com + Commit Date: 1576768849 + Commit Message: + net/i40e: Fix concurrency issues between config flow and XSK Use synchronize_rcu to wait until the XSK wakeup function finishes before destroying the resources it uses: 1. i40e_down already calls synchronize_rcu. On i40e_down either __I40E_VSI_DOWN or __I40E_CONFIG_BUSY is set. Check the latter in i40e_xsk_wakeup (the former is already checked there). 2. After switching the XDP program, call synchronize_rcu to let i40e_xsk_wakeup exit before the XDP program is freed. 3. Changing the number of channels brings the interface down (see i40e_prep_for_reset and i40e_pf_quiesce_all_vsi). 4. Disabling UMEM sets __I40E_CONFIG_BUSY, too. Signed-off-by: Maxim Mikityanskiy Signed-off-by: Björn Töpel Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191217162023.16011-4-maximmi@mellanox.com + Changed Files: drivers/net/ethernet/intel/i40e/i40e.h | 2 +-; drivers/net/ethernet/intel/i40e/i40e_main.c | 10 +++++++---; drivers/net/ethernet/intel/i40e/i40e_xsk.c | 4 ++++; 3 files changed, 12 insertions(+), 4 deletions(-) + Parent Hashes: 9cf88808ad6a0f1e958e00abd9a081295fe6da0c +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit fixes concurrency issues between configuration flow and XSK in the i40e driver by using synchronize_rcu.", + "keywords": "concurrency, XSK, i40e", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +Rethinking... +new content: +{ + "summary": "This commit addresses concurrency issues between configuration flow and XSK in the i40e driver using synchronize_rcu.", + "keywords": "concurrency,XSK,i40e", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +-------------------- +-------------------- +Processing Commit 821/6895 - Commit ID: 9cf88808ad6a0f1e958e00abd9a081295fe6da0c +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 9cf88808ad6a0f1e958e00abd9a081295fe6da0c + Author Name: Maxim Mikityanskiy + Author Email: maximmi@mellanox.com + Commit Date: 1576768849 + Commit Message: + net/mlx5e: Fix concurrency issues between config flow and XSK After disabling resources necessary for XSK (the XDP program, channels, XSK queues), use synchronize_rcu to wait until the XSK wakeup function finishes, before freeing the resources. Suspend XSK wakeups during switching channels. If the XDP program is being removed, synchronize_rcu before closing the old channels to allow XSK wakeup to complete. Signed-off-by: Maxim Mikityanskiy Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191217162023.16011-3-maximmi@mellanox.com + Changed Files: drivers/net/ethernet/mellanox/mlx5/core/en.h | 2 +-; drivers/net/ethernet/mellanox/mlx5/core/en/xdp.h | 22 +++++++++-------------; .../net/ethernet/mellanox/mlx5/core/en/xsk/setup.c | 1 +; .../net/ethernet/mellanox/mlx5/core/en/xsk/tx.c | 2 +-; drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 19 +------------------; 5 files changed, 13 insertions(+), 33 deletions(-) + Parent Hashes: 06870682087b58398671e8cdc896cd62314c4399 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes concurrency issues between config flow and XSK by using synchronize_rcu in the Mellanox network driver.", + "keywords": "concurrency,XSK,synchronize_rcu", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +Rethinking... +new content: +{ + "summary": "The commit resolves concurrency issues in the Mellanox driver between config flow and XSK using synchronize_rcu.", + "keywords": "concurrency,XSK,synchronize_rcu", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +-------------------- +-------------------- +Processing Commit 822/6895 - Commit ID: 06870682087b58398671e8cdc896cd62314c4399 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 06870682087b58398671e8cdc896cd62314c4399 + Author Name: Maxim Mikityanskiy + Author Email: maximmi@mellanox.com + Commit Date: 1576768848 + Commit Message: + xsk: Add rcu_read_lock around the XSK wakeup The XSK wakeup callback in drivers makes some sanity checks before triggering NAPI. However, some configuration changes may occur during this function that affect the result of those checks. For example, the interface can go down, and all the resources will be destroyed after the checks in the wakeup function, but before it attempts to use these resources. Wrap this callback in rcu_read_lock to allow driver to synchronize_rcu before actually destroying the resources. xsk_wakeup is a new function that encapsulates calling ndo_xsk_wakeup wrapped into the RCU lock. After this commit, xsk_poll starts using xsk_wakeup and checks xs->zc instead of ndo_xsk_wakeup != NULL to decide ndo_xsk_wakeup should be called. It also fixes a bug introduced with the need_wakeup feature: a non-zero-copy socket may be used with a driver supporting zero-copy, and in this case ndo_xsk_wakeup should not be called, so the xs->zc check is the correct one. Fixes: 77cd0d7b3f25 ("xsk: add support for need_wakeup flag in AF_XDP rings") Signed-off-by: Maxim Mikityanskiy Signed-off-by: Björn Töpel Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191217162023.16011-2-maximmi@mellanox.com + Changed Files: net/xdp/xsk.c | 22 ++++++++++++++--------; 1 file changed, 14 insertions(+), 8 deletions(-) + Parent Hashes: e47304232b373362228bf233f17bd12b11c9aafc +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds RCU read lock around XSK wakeup function to ensure safe synchronization during configuration changes.", + "keywords": "RCU, XSK, wakeup", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds rcu_read_lock to encapsulate xsk_wakeup ensuring safe resource handling during configuration changes in XDP sockets.", + "keywords": "RCU,XSK,wakeup", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 823/6895 - Commit ID: 580205dd4fe800b1e95be8b6df9e2991f975a8ad +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 580205dd4fe800b1e95be8b6df9e2991f975a8ad + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1576768448 + Commit Message: + selftests/bpf: Fix test_attach_probe Fix two issues in test_attach_probe: 1. it was not able to parse /proc/self/maps beyond the first line, since %s means parse string until white space. 2. offset has to be accounted for otherwise uprobed address is incorrect. Fixes: 1e8611bbdfc9 ("selftests/bpf: add kprobe/uprobe selftests") Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20191219020442.1922617-1-ast@kernel.org + Changed Files: tools/testing/selftests/bpf/prog_tests/attach_probe.c | 7 ++++---; 1 file changed, 4 insertions(+), 3 deletions(-) + Parent Hashes: 12dd14b230b3c742b80272ecb8a83cdf824625ca +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit fixes parsing and offset issues in test_attach_probe for eBPF selftests.", + "keywords": "selftests,bpf,fix", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.", + "uprobe/usdt like type user-space dynamic probe programs. It impacts user-space probes for tracing user-space applications. It can be other user-space probes in perf-events.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit fixes parsing and offset issues in test_attach_probe for eBPF selftests.", + "keywords": "selftests,bpf,fix", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.", + "uprobe/usdt like type user-space dynamic probe programs. It impacts user-space probes for tracing user-space applications. It can be other user-space probes in perf-events.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 824/6895 - Commit ID: 12dd14b230b3c742b80272ecb8a83cdf824625ca +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 12dd14b230b3c742b80272ecb8a83cdf824625ca + Author Name: Toke Høiland-Jørgensen + Author Email: toke@redhat.com + Commit Date: 1576768126 + Commit Message: + libbpf: Add missing newline in opts validation macro The error log output in the opts validation macro was missing a newline. Fixes: 2ce8450ef5a3 ("libbpf: add bpf_object__open_{file, mem} w/ extensible opts") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191219120714.928380-1-toke@redhat.com + Changed Files: tools/lib/bpf/libbpf_internal.h | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: 7800a3d54a7112e783453e24f5d96a8f230331fa +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds a missing newline to a log output in the libbpf internal file.", + "keywords": "libbpf,newline,opts", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes a missing newline in the libbpf error log output for option validation.", + "keywords": "libbpf,newline,validation", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 825/6895 - Commit ID: 7800a3d54a7112e783453e24f5d96a8f230331fa +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 7800a3d54a7112e783453e24f5d96a8f230331fa + Author Name: Daniel Borkmann + Author Email: daniel@iogearbox.net + Commit Date: 1576767858 + Commit Message: + Merge branch 'bpf-riscv-jit-improvements' Björn Töpel says: ==================== This series contain one non-critical fix, support for far jumps, and some optimizations for the BPF JIT. Previously, the JIT only supported 12b branch targets for conditional branches, and 21b for unconditional branches. Starting with this series, 32b branching is supported. As part of supporting far jumps, branch relaxation was introduced. The idea is to start with a pessimistic jump (e.g. auipc/jalr) and for each pass the JIT will have an opportunity to pick a better instruction (e.g. jal) and shrink the image. Instead of two passes, the JIT requires more passes. It typically converges after 3 passes. The optimizations mentioned in the subject are for calls and tail calls. In the tail call generation we can save one instruction by using the offset in jalr. Calls are optimized by doing (auipc)/jal(r) relative jumps instead of loading the entire absolute address and doing jalr. This required that the JIT image allocator was made RISC-V specific, so we can ensure that the JIT image and the kernel text are in range (32b). The last two patches of the series is not critical to the series, but are two UAPI build issues for BPF events. A closer look from the RV-folks would be much appreciated. The test_bpf.ko module, selftests/bpf/test_verifier and selftests/seccomp/seccomp_bpf pass all tests. RISC-V is still missing proper kprobe and tracepoint support, so a lot of BPF selftests cannot be run. v1->v2: [1] * Removed unused function parameter from emit_branch() * Added patch to support far branch in tail call emit [1] https://lore.kernel.org/bpf/20191209173136.29615-1-bjorn.topel@gmail.com/ ==================== Signed-off-by: Daniel Borkmann + Changed Files: nan + Parent Hashes: a352a82496d17f210a88b4fe2de7904afdb92003 34bfc10a6e7e573563a700239d302ab5944b3397 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges improvements in the BPF JIT for RISC-V including far jump support and optimizations.", + "keywords": "BPF,JIT,RISC-V", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges RISC-V BPF JIT improvements, adding far jumps and optimizations for call instructions.", + "keywords": "RISC-V,BPF,optimizations", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 826/6895 - Commit ID: 34bfc10a6e7e573563a700239d302ab5944b3397 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 34bfc10a6e7e573563a700239d302ab5944b3397 + Author Name: Björn Töpel + Author Email: bjorn.topel@gmail.com + Commit Date: 1576767811 + Commit Message: + riscv, perf: Add arch specific perf_arch_bpf_user_pt_regs RISC-V was missing a proper perf_arch_bpf_user_pt_regs macro for CONFIG_PERF_EVENT builds. Signed-off-by: Björn Töpel Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191216091343.23260-10-bjorn.topel@gmail.com + Changed Files: arch/riscv/include/asm/perf_event.h | 4 ++++; 1 file changed, 4 insertions(+) + Parent Hashes: eb9928bed003dd61a443d0ba51ae066429fbe735 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Added architecture-specific perf_arch_bpf_user_pt_regs macro support for RISC-V in perf_event.", + "keywords": "RISC-V, perf_event, macro", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Profile related type programs. It affects programs used for profiling system or application performance.", + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +Rethinking... +new content: +{ + "summary": "Added architecture-specific perf_arch_bpf_user_pt_regs macro support for RISC-V in perf_event.", + "keywords": "RISC-V, perf_event, macro", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Profile related type programs. It affects programs used for profiling system or application performance.", + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +-------------------- +-------------------- +Processing Commit 827/6895 - Commit ID: eb9928bed003dd61a443d0ba51ae066429fbe735 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: eb9928bed003dd61a443d0ba51ae066429fbe735 + Author Name: Björn Töpel + Author Email: bjorn.topel@gmail.com + Commit Date: 1576767811 + Commit Message: + riscv, bpf: Add missing uapi header for BPF_PROG_TYPE_PERF_EVENT programs Add missing uapi header the BPF_PROG_TYPE_PERF_EVENT programs by exporting struct user_regs_struct instead of struct pt_regs which is in-kernel only. Signed-off-by: Björn Töpel Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191216091343.23260-9-bjorn.topel@gmail.com + Changed Files: arch/riscv/include/uapi/asm/bpf_perf_event.h | 9 +++++++++; tools/include/uapi/asm/bpf_perf_event.h | 2 ++; 2 files changed, 11 insertions(+) + Parent Hashes: e368b64f8b0c8066115ad1da71f83f20f7bb43af +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds the missing uapi header required for BPF_PROG_TYPE_PERF_EVENT programs on RISC-V architecture by exporting struct user_regs_struct.", + "keywords": "uapi, BPF_PROG_TYPE_PERF_EVENT, RISC-V", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Profile related type programs. It affects programs used for profiling system or application performance." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds a missing uapi header for BPF_PROG_TYPE_PERF_EVENT programs on RISC-V by exporting struct user_regs_struct.", + "keywords": "uapi,RISC-V,BPF_PROG_TYPE_PERF_EVENT", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Profile related type programs. It affects programs used for profiling system or application performance." + ] +} +-------------------- +-------------------- +Processing Commit 828/6895 - Commit ID: e368b64f8b0c8066115ad1da71f83f20f7bb43af +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: e368b64f8b0c8066115ad1da71f83f20f7bb43af + Author Name: Björn Töpel + Author Email: bjorn.topel@gmail.com + Commit Date: 1576767811 + Commit Message: + riscv, bpf: Optimize calls Instead of using emit_imm() and emit_jalr() which can expand to six instructions, start using jal or auipc+jalr. Signed-off-by: Björn Töpel Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191216091343.23260-8-bjorn.topel@gmail.com + Changed Files: arch/riscv/net/bpf_jit_comp.c | 101 ++++++++++++++++++++++++++----------------; 1 file changed, 64 insertions(+), 37 deletions(-) + Parent Hashes: 7f3631e88ee6fb13beac333a0e9e605d2414d17f +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Optimize RISC-V eBPF JIT calls by replacing emit_imm() and emit_jalr() with jal or auipc+jalr.", + "keywords": "RISC-V, BPF, JIT", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Optimize RISC-V eBPF JIT by using jal or auipc+jalr for better performance.", + "keywords": "RISC-V,JIT,optimization", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 829/6895 - Commit ID: 7f3631e88ee6fb13beac333a0e9e605d2414d17f +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 7f3631e88ee6fb13beac333a0e9e605d2414d17f + Author Name: Björn Töpel + Author Email: bjorn.topel@gmail.com + Commit Date: 1576767811 + Commit Message: + riscv, bpf: Provide RISC-V specific JIT image alloc/free This commit makes sure that the JIT images is kept close to the kernel text, so BPF calls can use relative calling with auipc/jalr or jal instead of loading the full 64-bit address and jalr. The BPF JIT image region is 128 MB before the kernel text. Signed-off-by: Björn Töpel Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191216091343.23260-7-bjorn.topel@gmail.com + Changed Files: arch/riscv/include/asm/pgtable.h | 4 ++++; arch/riscv/net/bpf_jit_comp.c | 13 +++++++++++++; 2 files changed, 17 insertions(+) + Parent Hashes: fe8322b866d560a3b3535ed9aa49df59809decbe +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit optimizes RISC-V BPF JIT compiler to use relative calls by placing JIT images near kernel text.", + "keywords": "RISC-V,JIT,BPF", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit optimizes RISC-V BPF JIT compiler to use relative calls by placing JIT images near kernel text.", + "keywords": "RISC-V,JIT,BPF", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 830/6895 - Commit ID: fe8322b866d560a3b3535ed9aa49df59809decbe +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: fe8322b866d560a3b3535ed9aa49df59809decbe + Author Name: Björn Töpel + Author Email: bjorn.topel@gmail.com + Commit Date: 1576767811 + Commit Message: + riscv, bpf: Optimize BPF tail calls Remove one addi, and instead use the offset part of jalr. Signed-off-by: Björn Töpel Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191216091343.23260-6-bjorn.topel@gmail.com + Changed Files: arch/riscv/net/bpf_jit_comp.c | 13 +++++++------; 1 file changed, 7 insertions(+), 6 deletions(-) + Parent Hashes: 33203c02f2f8ae8e19d7dbbabf55cfd0025efede +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Optimize BPF tail calls on RISC-V architecture by adjusting offset calculation for JIT compilation.", + "keywords": "RISC-V, BPF, optimization", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Optimize BPF tail calls on RISC-V by using offset part of jalr to improve JIT compilation.", + "keywords": "RISC-V, BPF, optimization", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 831/6895 - Commit ID: 33203c02f2f8ae8e19d7dbbabf55cfd0025efede +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 33203c02f2f8ae8e19d7dbbabf55cfd0025efede + Author Name: Björn Töpel + Author Email: bjorn.topel@gmail.com + Commit Date: 1576767810 + Commit Message: + riscv, bpf: Add support for far jumps and exits This commit add support for far (offset > 21b) jumps and exits. Signed-off-by: Björn Töpel Signed-off-by: Daniel Borkmann Reviewed-by: Luke Nelson Link: https://lore.kernel.org/bpf/20191216091343.23260-5-bjorn.topel@gmail.com + Changed Files: arch/riscv/net/bpf_jit_comp.c | 37 +++++++++++++++++--------------------; 1 file changed, 17 insertions(+), 20 deletions(-) + Parent Hashes: 29d92edd9ee8b37bd8e9a0ba7fd549f874e0d069 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds RISC-V architecture support for far jumps and exits in the eBPF JIT compiler.", + "keywords": "RISC-V,eBPF,jumps", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit enhances the RISC-V eBPF JIT compiler to support far jumps and exits.", + "keywords": "RISC-V,far jumps,exits", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 832/6895 - Commit ID: 29d92edd9ee8b37bd8e9a0ba7fd549f874e0d069 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 29d92edd9ee8b37bd8e9a0ba7fd549f874e0d069 + Author Name: Björn Töpel + Author Email: bjorn.topel@gmail.com + Commit Date: 1576767810 + Commit Message: + riscv, bpf: Add support for far branching when emitting tail call Start use the emit_branch() function in the tail call emitter in order to support far branching. Signed-off-by: Björn Töpel Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191216091343.23260-4-bjorn.topel@gmail.com + Changed Files: arch/riscv/net/bpf_jit_comp.c | 22 +++-------------------; 1 file changed, 3 insertions(+), 19 deletions(-) + Parent Hashes: 7d1ef13fea2b66bb466592a7855b33181c85ec5f +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds support for far branching in RISC-V eBPF JIT through the emit_branch function.", + "keywords": "far branching,RISC-V,emit_branch", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds support for far branching in RISC-V eBPF JIT using the emit_branch function.", + "keywords": "far branching,RISC-V,emit_branch", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 833/6895 - Commit ID: 7d1ef13fea2b66bb466592a7855b33181c85ec5f +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 7d1ef13fea2b66bb466592a7855b33181c85ec5f + Author Name: Björn Töpel + Author Email: bjorn.topel@gmail.com + Commit Date: 1576767810 + Commit Message: + riscv, bpf: Add support for far branching This commit adds branch relaxation to the BPF JIT, and with that support for far (offset greater than 12b) branching. The branch relaxation requires more than two passes to converge. For most programs it is three passes, but for larger programs it can be more. Signed-off-by: Björn Töpel Signed-off-by: Daniel Borkmann Reviewed-by: Luke Nelson Link: https://lore.kernel.org/bpf/20191216091343.23260-3-bjorn.topel@gmail.com + Changed Files: arch/riscv/net/bpf_jit_comp.c | 352 ++++++++++++++++++++++--------------------; 1 file changed, 188 insertions(+), 164 deletions(-) + Parent Hashes: f1003b787c00fbaa4b11619c6b23a885bfce8f07 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds support for far branching by implementing branch relaxation in the BPF JIT for RISC-V architecture.", + "keywords": "far branching,RISC-V,JIT", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds support for far branching by implementing branch relaxation in the BPF JIT for RISC-V architecture.", + "keywords": "far branching,RISC-V,JIT", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 834/6895 - Commit ID: f1003b787c00fbaa4b11619c6b23a885bfce8f07 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: f1003b787c00fbaa4b11619c6b23a885bfce8f07 + Author Name: Björn Töpel + Author Email: bjorn.topel@gmail.com + Commit Date: 1576767810 + Commit Message: + riscv, bpf: Fix broken BPF tail calls The BPF JIT incorrectly clobbered the a0 register, and did not flag usage of s5 register when BPF stack was being used. Fixes: 2353ecc6f91f ("bpf, riscv: add BPF JIT for RV64G") Signed-off-by: Björn Töpel Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191216091343.23260-2-bjorn.topel@gmail.com + Changed Files: arch/riscv/net/bpf_jit_comp.c | 13 +++++++++++--; 1 file changed, 11 insertions(+), 2 deletions(-) + Parent Hashes: a352a82496d17f210a88b4fe2de7904afdb92003 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes a BPF JIT issue on RISC-V by correcting register handling for tail calls.", + "keywords": "BPF JIT, RISC-V, registers", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes a BPF JIT issue on RISC-V by correcting register handling for tail calls.", + "keywords": "BPF JIT, RISC-V, registers", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 835/6895 - Commit ID: a352a82496d17f210a88b4fe2de7904afdb92003 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: a352a82496d17f210a88b4fe2de7904afdb92003 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1576719232 + Commit Message: + Merge branch 'libbpf-extern-followups' Andrii Nakryiko says: ==================== Based on latest feedback and discussions, this patch set implements the following changes: - Kconfig-provided externs have to be in .kconfig section, for which bpf_helpers.h provides convenient __kconfig macro (Daniel); - instead of allowing to override Kconfig file path, switch this to ability to extend and override system Kconfig with user-provided custom values (Alexei); - BTF is required when externs are used. ==================== Signed-off-by: Alexei Starovoitov + Changed Files: nan + Parent Hashes: d69587062c347314a019cf6ee27f2e4b494868e1 630628cb7dc39780660d8fcedc66e0298a82f9da +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit merges changes related to configuring externs in libbpf, involving Kconfig sections, user custom values, and BTF requirements.", + "keywords": "libbpf,BTF,Kconfig", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit merges changes related to configuring externs in libbpf with updates involving Kconfig sections and BTF requirements.", + "keywords": "libbpf,Kconfig,BTF", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 836/6895 - Commit ID: 630628cb7dc39780660d8fcedc66e0298a82f9da +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 630628cb7dc39780660d8fcedc66e0298a82f9da + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576719216 + Commit Message: + libbpf: BTF is required when externs are present BTF is required to get type information about extern variables. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191219002837.3074619-4-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.c | 3 ++-; 1 file changed, 2 insertions(+), 1 deletion(-) + Parent Hashes: 8601fd422148a8f7ff5f7eaf75b6703d5166332c +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit enforces BTF requirement for extern variables in libbpf to access their type information.", + "keywords": "BTF,libbpf,externs", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit enforces BTF requirement for extern variables in libbpf to access their type information.", + "keywords": "BTF,libbpf,externs", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 837/6895 - Commit ID: 8601fd422148a8f7ff5f7eaf75b6703d5166332c +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 8601fd422148a8f7ff5f7eaf75b6703d5166332c + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576719216 + Commit Message: + libbpf: Allow to augment system Kconfig through extra optional config Instead of all or nothing approach of overriding Kconfig file location, allow to extend it with extra values and override chosen subset of values though optional user-provided extra config, passed as a string through open options' .kconfig option. If same config key is present in both user-supplied config and Kconfig, user-supplied one wins. This allows applications to more easily test various conditions despite host kernel's real configuration. If all of BPF object's __kconfig externs are satisfied from user-supplied config, system Kconfig won't be read at all. Simplify selftests by not needing to create temporary Kconfig files. Suggested-by: Alexei Starovoitov Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191219002837.3074619-3-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.c | 204 +++++++++++++--------; tools/lib/bpf/libbpf.h | 8 +-; .../testing/selftests/bpf/prog_tests/core_extern.c | 32 +---; 3 files changed, 132 insertions(+), 112 deletions(-) + Parent Hashes: 81bfdd087bf31a87c5ff25cc7004d5308954a35c +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit allows libbpf to extend system Kconfig with optional user-provided configurations improving testing flexibility.", + "keywords": "libbpf,Kconfig,configuration", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit allows libbpf to extend Kconfig with user-provided configurations improving testing flexibility.", + "keywords": "libbpf,Kconfig,configuration", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 838/6895 - Commit ID: 81bfdd087bf31a87c5ff25cc7004d5308954a35c +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 81bfdd087bf31a87c5ff25cc7004d5308954a35c + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576719216 + Commit Message: + libbpf: Put Kconfig externs into .kconfig section Move Kconfig-provided externs into custom .kconfig section. Add __kconfig into bpf_helpers.h for user convenience. Update selftests accordingly. Suggested-by: Daniel Borkmann Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191219002837.3074619-2-andriin@fb.com + Changed Files: tools/bpf/bpftool/gen.c | 8 +--; tools/lib/bpf/bpf_helpers.h | 2 +; tools/lib/bpf/libbpf.c | 58 +++++++++++++---------; tools/testing/selftests/bpf/prog_tests/skeleton.c | 16 +++---; .../testing/selftests/bpf/progs/test_core_extern.c | 20 ++++----; tools/testing/selftests/bpf/progs/test_skeleton.c | 4 +-; 6 files changed, 60 insertions(+), 48 deletions(-) + Parent Hashes: d69587062c347314a019cf6ee27f2e4b494868e1 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit places Kconfig externs into a specific .kconfig section and updates selftests for libbpf.", + "keywords": "Kconfig externs bpf_helpers", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit refactors libbpf by relocating Kconfig externs to a .kconfig section and updating associated selftests.", + "keywords": "Kconfig, libbpf, refactor", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 839/6895 - Commit ID: d69587062c347314a019cf6ee27f2e4b494868e1 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: d69587062c347314a019cf6ee27f2e4b494868e1 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576718267 + Commit Message: + libbpf: Add bpf_link__disconnect() API to preserve underlying BPF resource There are cases in which BPF resource (program, map, etc) has to outlive userspace program that "installed" it in the system in the first place. When BPF program is attached, libbpf returns bpf_link object, which is supposed to be destroyed after no longer necessary through bpf_link__destroy() API. Currently, bpf_link destruction causes both automatic detachment and frees up any resources allocated to for bpf_link in-memory representation. This is inconvenient for the case described above because of coupling of detachment and resource freeing. This patch introduces bpf_link__disconnect() API call, which marks bpf_link as disconnected from its underlying BPF resouces. This means that when bpf_link is destroyed later, all its memory resources will be freed, but BPF resource itself won't be detached. This design allows to follow strict and resource-leak-free design by default, while giving easy and straightforward way for user code to opt for keeping BPF resource attached beyond lifetime of a bpf_link. For some BPF programs (i.e., FS-based tracepoints, kprobes, raw tracepoint, etc), user has to make sure to pin BPF program to prevent kernel to automatically detach it on process exit. This should typically be achived by pinning BPF program (or map in some cases) in BPF FS. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191218225039.2668205-1-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.c | 40 ++++++++++++++++++++++++++++++----------; tools/lib/bpf/libbpf.h | 1 +; tools/lib/bpf/libbpf.map | 1 +; 3 files changed, 32 insertions(+), 10 deletions(-) + Parent Hashes: 6de6c1f840c051017f2308503858ff19344c56b3 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit introduces the bpf_link__disconnect API to separate detachment from resource cleanup in libbpf.", + "keywords": "bpf_link, API, disconnect", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit introduces the bpf_link__disconnect API to manage resource cleanup separately from detachment in libbpf.", + "keywords": "bpf_link, API, disconnect", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 840/6895 - Commit ID: 6de6c1f840c051017f2308503858ff19344c56b3 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 6de6c1f840c051017f2308503858ff19344c56b3 + Author Name: Nikita V. Shirokov + Author Email: tehnerd@tehnerd.com + Commit Date: 1576717558 + Commit Message: + bpf: Allow to change skb mark in test_run allow to pass skb's mark field into bpf_prog_test_run ctx for BPF_PROG_TYPE_SCHED_CLS prog type. that would allow to test bpf programs which are doing decision based on this field Signed-off-by: Nikita V. Shirokov Signed-off-by: Alexei Starovoitov + Changed Files: net/bpf/test_run.c | 10 +++++++++-; tools/testing/selftests/bpf/prog_tests/skb_ctx.c | 5 +++++; tools/testing/selftests/bpf/progs/test_skb_ctx.c | 1 +; 3 files changed, 15 insertions(+), 1 deletion(-) + Parent Hashes: dacce6412e09b5dce19514e2c4e2a8aab0eb217f +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit modifies the bpf_prog_test_run context to allow testing eBPF programs that use skb mark field for decision-making.", + "keywords": "skb,mark,test", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Scheduler related type programs. It modifies programs that interact with kernel-level scheduling mechanisms." + ] +} +Rethinking... +new content: +{ + "summary": "This commit allows skb's mark field to be tested in eBPF programs for SCHED_CLS type using bpf_prog_test_run context.", + "keywords": "skb,mark,test_run", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "tc related type programs. It affects programs managing traffic control (tc) for queuing or prioritizing network traffic." + ] +} +-------------------- +-------------------- +Processing Commit 841/6895 - Commit ID: dacce6412e09b5dce19514e2c4e2a8aab0eb217f +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: dacce6412e09b5dce19514e2c4e2a8aab0eb217f + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576717432 + Commit Message: + bpftool: Work-around rst2man conversion bug Work-around what appears to be a bug in rst2man convertion tool, used to create man pages out of reStructureText-formatted documents. If text line starts with dot, rst2man will put it in resulting man file verbatim. This seems to cause man tool to interpret it as a directive/command (e.g., `.bs`), and subsequently not render entire line because it's unrecognized one. Enclose '.xxx' words in extra formatting to work around. Fixes: cb21ac588546 ("bpftool: Add gen subcommand manpage") Reported-by: Alexei Starovoitov Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20191218214314.2403729-1-andriin@fb.com + Changed Files: tools/bpf/bpftool/gen.c | 4 ++--; 1 file changed, 2 insertions(+), 2 deletions(-) + Parent Hashes: 58d8dc2a98f50d4741a49e047bd7b322d7692d0b +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit simplifies a format string in bpftool to avoid libc issues.", + "keywords": "bpftool,format,string", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit simplifies the format string in bpftool to ensure compatibility with all libc versions.", + "keywords": "bpftool,format,libc", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 843/6895 - Commit ID: f596cf0d8062cb5d0a4513a8b3afca318c13be10 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: f596cf0d8062cb5d0a4513a8b3afca318c13be10 + Author Name: Alexander Lobakin + Author Email: alobakin@dlink.ru + Commit Date: 1576710904 + Commit Message: + MIPS: BPF: eBPF JIT: check for MIPS ISA compliance in Kconfig It is completely wrong to check for compile-time MIPS ISA revision in the body of bpf_int_jit_compile() as it may lead to get MIPS JIT fully omitted by the CC while the rest system will think that the JIT is actually present and works [1]. We can check if the selected CPU really supports MIPS eBPF JIT at configure time and avoid such situations when kernel can be built without both JIT and interpreter, but with CONFIG_BPF_SYSCALL=y. [1] https://lore.kernel.org/linux-mips/09d713a59665d745e21d021deeaebe0a@dlink.ru/ Fixes: 716850ab104d ("MIPS: eBPF: Initial eBPF support for MIPS32 architecture.") Cc: # v5.2+ Signed-off-by: Alexander Lobakin Signed-off-by: Paul Burton Cc: Ralf Baechle Cc: James Hogan Cc: Hassan Naveed Cc: Alexei Starovoitov Cc: Daniel Borkmann Cc: Martin KaFai Lau Cc: Song Liu Cc: Yonghong Song Cc: Andrii Nakryiko Cc: linux-mips@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: netdev@vger.kernel.org Cc: bpf@vger.kernel.org + Changed Files: arch/mips/Kconfig | 2 +-; arch/mips/net/ebpf_jit.c | 2 +-; 2 files changed, 2 insertions(+), 2 deletions(-) + Parent Hashes: f8fffebdea752a25757b906f3dffecf1a59a6194 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit modifies eBPF JIT configuration checks for MIPS ISA compliance at compile time to prevent system misconfiguration.", + "keywords": "MIPS,JIT,compliance", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit modifies eBPF JIT configuration checks for MIPS ISA compliance at compile time to prevent system misconfiguration.", + "keywords": "MIPS,JIT,compliance", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 844/6895 - Commit ID: f8fffebdea752a25757b906f3dffecf1a59a6194 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: f8fffebdea752a25757b906f3dffecf1a59a6194 + Author Name: Paul Burton + Author Email: paulburton@kernel.org + Commit Date: 1576710903 + Commit Message: + MIPS: BPF: Disable MIPS32 eBPF JIT Commit 716850ab104d ("MIPS: eBPF: Initial eBPF support for MIPS32 architecture.") enabled our eBPF JIT for MIPS32 kernels, whereas it has previously only been availailable for MIPS64. It was my understanding at the time that the BPF test suite was passing & JITing a comparable number of tests to our cBPF JIT [1], but it turns out that was not the case. The eBPF JIT has a number of problems on MIPS32: - Most notably various code paths still result in emission of MIPS64 instructions which will cause reserved instruction exceptions & kernel panics when run on MIPS32 CPUs. - The eBPF JIT doesn't account for differences between the O32 ABI used by MIPS32 kernels versus the N64 ABI used by MIPS64 kernels. Notably arguments beyond the first 4 are passed on the stack in O32, and this is entirely unhandled when JITing a BPF_CALL instruction. Stack space must be reserved for arguments even if they all fit in registers, and the callee is free to assume that stack space has been reserved for its use - with the eBPF JIT this is not the case, so calling any function can result in clobbering values on the stack & unpredictable behaviour. Function arguments in eBPF are always 64-bit values which is also entirely unhandled - the JIT still uses a single (32-bit) register per argument. As a result all function arguments are always passed incorrectly when JITing a BPF_CALL instruction, leading to kernel crashes or strange behavior. - The JIT attempts to bail our on use of ALU64 instructions or 64-bit memory access instructions. The code doing this at the start of build_one_insn() incorrectly checks whether BPF_OP() equals BPF_DW, when it should really be checking BPF_SIZE() & only doing so when BPF_CLASS() is one of BPF_{LD,LDX,ST,STX}. This results in false positives that cause more bailouts than intended, and that in turns hides some of the problems described above. - The kernel's cBPF->eBPF translation makes heavy use of 64-bit eBPF instructions that the MIPS32 eBPF JIT bails out on, leading to most cBPF programs not being JITed at all. Until these problems are resolved, revert the enabling of the eBPF JIT on MIPS32 done by commit 716850ab104d ("MIPS: eBPF: Initial eBPF support for MIPS32 architecture."). Note that this does not undo the changes made to the eBPF JIT by that commit, since they are a useful starting point to providing MIPS32 support - they're just not nearly complete. [1] https://lore.kernel.org/linux-mips/MWHPR2201MB13583388481F01A422CE7D66D4410@MWHPR2201MB1358.namprd22.prod.outlook.com/ Signed-off-by: Paul Burton Fixes: 716850ab104d ("MIPS: eBPF: Initial eBPF support for MIPS32 architecture.") Cc: Daniel Borkmann Cc: Hassan Naveed Cc: Tony Ambardar Cc: bpf@vger.kernel.org Cc: netdev@vger.kernel.org Cc: # v5.2+ Cc: linux-mips@vger.kernel.org Cc: linux-kernel@vger.kernel.org + Changed Files: arch/mips/Kconfig | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: a4a3893114a41e365274d5fab5d9ff5acc235ff0 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit disables the eBPF JIT compiler for MIPS32 due to multiple issues with instruction emission and argument handling.", + "keywords": "MIPS32,JIT,eBPF", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit disables eBPF JIT for MIPS32 due to multiple issues related to instruction emission and argument handling.", + "keywords": "MIPS32,JIT,issues", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 845/6895 - Commit ID: 58d8dc2a98f50d4741a49e047bd7b322d7692d0b +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 58d8dc2a98f50d4741a49e047bd7b322d7692d0b + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1576649800 + Commit Message: + Merge branch 'skel-fixes' Andrii Nakryiko says: ==================== Simplify skeleton usage by embedding source BPF object file inside skeleton itself. This allows to keep skeleton and object file in sync at all times with no chance of confusion. Also, add bpftool-gen.rst manpage, explaining concepts and ideas behind skeleton. In examples section it also includes a complete small BPF application utilizing skeleton, as a demonstration of API. Patch #2 also removes BPF_EMBED_OBJ, as there is currently no use of it. v2->v3: - (void) in no-args function (Alexei); - bpftool-gen.rst code block formatting fix (Alexei); - simplified xxx__create_skeleton to fill in obj and return error code; v1->v2: - remove whitespace from empty lines in code blocks (Yonghong). ==================== Signed-off-by: Alexei Starovoitov + Changed Files: nan + Parent Hashes: 4a3d6c6a6e4d652808729e7a2a8c3774a5a5c814 cb21ac58854605e6c15fd7da2c619823967b3140 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges a branch to simplify skeleton usage by embedding the BPF object file and updates documentation for bpftool-gen.", + "keywords": "merge,skeleton,bpftool", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges a branch simplifying the skeleton by embedding the BPF object file and updating its documentation.", + "keywords": "merge,skeleton,bpf", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 846/6895 - Commit ID: cb21ac58854605e6c15fd7da2c619823967b3140 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: cb21ac58854605e6c15fd7da2c619823967b3140 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576649796 + Commit Message: + bpftool: Add gen subcommand manpage Add bpftool-gen.rst describing skeleton on the high level. Also include a small, but complete, example BPF app (BPF side, userspace side, generated skeleton) in example section to demonstrate skeleton API and its usage. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20191218052552.2915188-4-andriin@fb.com + Changed Files: tools/bpf/bpftool/Documentation/bpftool-gen.rst | 304 ++++++++++++++++++++++++; tools/bpf/bpftool/Documentation/bpftool.rst | 3 +-; 2 files changed, 306 insertions(+), 1 deletion(-) + Parent Hashes: 3bf3c79b772f4155312c000310abab700aba2200 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds a manpage for the 'gen' subcommand of the bpftool, including a complete BPF application example.", + "keywords": "bpftool, gen, manpage", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds detailed documentation for the bpftool gen subcommand, including examples of BPF applications.", + "keywords": "bpftool, documentation, example", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 847/6895 - Commit ID: 3bf3c79b772f4155312c000310abab700aba2200 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 3bf3c79b772f4155312c000310abab700aba2200 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576649796 + Commit Message: + libbpf: Remove BPF_EMBED_OBJ macro from libbpf.h Drop BPF_EMBED_OBJ and struct bpf_embed_data now that skeleton automatically embeds contents of its source object file. While BPF_EMBED_OBJ is useful independently of skeleton, we are currently don't have any use cases utilizing it, so let's remove them until/if we need it. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20191218052552.2915188-3-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.h | 35 -----------------------------------; 1 file changed, 35 deletions(-) + Parent Hashes: 5dc7a8b2114479fd945956ece9875f747a996a8e +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit removes the BPF_EMBED_OBJ macro and struct bpf_embed_data from libbpf.h.", + "keywords": "libbpf, BPF_EMBED_OBJ, removal", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit removes the BPF_EMBED_OBJ macro and related struct from libbpf.h due to lack of utilization.", + "keywords": "libbpf, macro, removal", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 848/6895 - Commit ID: 5dc7a8b2114479fd945956ece9875f747a996a8e +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 5dc7a8b2114479fd945956ece9875f747a996a8e + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576649795 + Commit Message: + bpftool, selftests/bpf: Embed object file inside skeleton Embed contents of BPF object file used for BPF skeleton generation inside skeleton itself. This allows to keep BPF object file and its skeleton in sync at all times, and simpifies skeleton instantiation. Also switch existing selftests to not require BPF_EMBED_OBJ anymore. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20191218052552.2915188-2-andriin@fb.com + Changed Files: tools/bpf/bpftool/gen.c | 232 +++++++++++++--------; .../selftests/bpf/prog_tests/attach_probe.c | 4 +-; .../testing/selftests/bpf/prog_tests/core_extern.c | 4 +-; .../selftests/bpf/prog_tests/fentry_fexit.c | 10 +-; .../testing/selftests/bpf/prog_tests/fentry_test.c | 7 +-; tools/testing/selftests/bpf/prog_tests/mmap.c | 4 +-; tools/testing/selftests/bpf/prog_tests/skeleton.c | 4 +-; .../selftests/bpf/prog_tests/stacktrace_build_id.c | 4 +-; .../bpf/prog_tests/stacktrace_build_id_nmi.c | 4 +-; 9 files changed, 154 insertions(+), 119 deletions(-) + Parent Hashes: 4a3d6c6a6e4d652808729e7a2a8c3774a5a5c814 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Embed BPF object files directly into skeletons to simplify instantiation and maintain synchronization.", + "keywords": "bpftool,skeleton,selftests", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Embed BPF object files directly into skeletons to simplify instantiation and maintain synchronization.", + "keywords": "bpftool,skeleton,selftests", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 849/6895 - Commit ID: 4a3d6c6a6e4d652808729e7a2a8c3774a5a5c814 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 4a3d6c6a6e4d652808729e7a2a8c3774a5a5c814 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576636715 + Commit Message: + libbpf: Reduce log level for custom section names Libbpf is trying to recognize BPF program type based on its section name during bpf_object__open() phase. This is not strictly enforced and user code has ability to specify/override correct BPF program type after open. But if BPF program is using custom section name, libbpf will still emit warnings, which can be quite annoying to users. This patch reduces log level of information messages emitted by libbpf if section name is not canonical. User can still get a list of all supported section names as debug-level message. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191217234228.1739308-1-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.c | 6 +++---; 1 file changed, 3 insertions(+), 3 deletions(-) + Parent Hashes: fb9a98e160f10555936e1c7041d4efda4954d1df +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit reduces log level for non-canonical section names in libbpf to avoid annoying warnings.", + "keywords": "libbpf,log level,section names", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit reduces log level for non-canonical section names in libbpf to avoid annoying warnings.", + "keywords": "libbpf,log level,section", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 850/6895 - Commit ID: fb9a98e160f10555936e1c7041d4efda4954d1df +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: fb9a98e160f10555936e1c7041d4efda4954d1df + Author Name: Toke Høiland-Jørgensen + Author Email: toke@redhat.com + Commit Date: 1576624771 + Commit Message: + libbpf: Fix libbpf_common.h when installing libbpf through 'make install' This fixes two issues with the newly introduced libbpf_common.h file: - The header failed to include for the definition of memset() - The new file was not included in the install_headers rule in the Makefile Both of these issues cause breakage when installing libbpf with 'make install' and trying to use it in applications. Fixes: 544402d4b493 ("libbpf: Extract common user-facing helpers") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20191217112810.768078-1-toke@redhat.com + Changed Files: tools/lib/bpf/Makefile | 1 +; tools/lib/bpf/libbpf_common.h | 2 ++; 2 files changed, 3 insertions(+) + Parent Hashes: 92f7440ecc9331aa1e274273d4a3cb5c58b69706 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes header inclusion and installation issues in libbpf_common.h for libbpf.", + "keywords": "libbpf,header,fix", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes header inclusion and installation issues in libbpf_common.h for libbpf.", + "keywords": "libbpf,header,fix", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 851/6895 - Commit ID: 92f7440ecc9331aa1e274273d4a3cb5c58b69706 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 92f7440ecc9331aa1e274273d4a3cb5c58b69706 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576624460 + Commit Message: + selftests/bpf: More succinct Makefile output Similarly to bpftool/libbpf output, make selftests/bpf output succinct per-item output line. Output is roughly as follows: $ make ... CLANG-LLC [test_maps] pyperf600.o CLANG-LLC [test_maps] strobemeta.o CLANG-LLC [test_maps] pyperf100.o EXTRA-OBJ [test_progs] cgroup_helpers.o EXTRA-OBJ [test_progs] trace_helpers.o BINARY test_align BINARY test_verifier_log GEN-SKEL [test_progs] fexit_bpf2bpf.skel.h GEN-SKEL [test_progs] test_global_data.skel.h GEN-SKEL [test_progs] sendmsg6_prog.skel.h ... To see the actual command invocation, verbose mode can be turned on with V=1 argument: $ make V=1 ... very verbose output ... Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20191217061425.2346359-1-andriin@fb.com + Changed Files: tools/testing/selftests/bpf/Makefile | 36 ++++++++++++++++++++++++++++++++++++; 1 file changed, 36 insertions(+) + Parent Hashes: dbd8f6bae6f4a98aa517aeda6e5276ed4a20f571 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit improves Makefile output for selftests/bpf to make it more succinct, similar to bpftool/libbpf output.", + "keywords": "Makefile,selftests,bpf", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit modifies the Makefile for selftests/bpf to produce more succinct output, similar to bpftool/libbpf.", + "keywords": "Makefile,selftests,succinct", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 852/6895 - Commit ID: e47304232b373362228bf233f17bd12b11c9aafc +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: e47304232b373362228bf233f17bd12b11c9aafc + Author Name: Daniel Borkmann + Author Email: daniel@iogearbox.net + Commit Date: 1576601882 + Commit Message: + bpf: Fix cgroup local storage prog tracking Recently noticed that we're tracking programs related to local storage maps through their prog pointer. This is a wrong assumption since the prog pointer can still change throughout the verification process, for example, whenever bpf_patch_insn_single() is called. Therefore, the prog pointer that was assigned via bpf_cgroup_storage_assign() is not guaranteed to be the same as we pass in bpf_cgroup_storage_release() and the map would therefore remain in busy state forever. Fix this by using the prog's aux pointer which is stable throughout verification and beyond. Fixes: de9cbbaadba5 ("bpf: introduce cgroup storage maps") Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Cc: Roman Gushchin Cc: Martin KaFai Lau Link: https://lore.kernel.org/bpf/1471c69eca3022218666f909bc927a92388fd09e.1576580332.git.daniel@iogearbox.net + Changed Files: include/linux/bpf-cgroup.h | 8 ++++----; kernel/bpf/core.c | 3 +--; kernel/bpf/local_storage.c | 24 ++++++++++++------------; kernel/bpf/verifier.c | 2 +-; 4 files changed, 18 insertions(+), 19 deletions(-) + Parent Hashes: a2ea07465c8d7984cc6b8b1f0b3324f9b138094a +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes the handling of cgroup local storage maps by using a stable prog's aux pointer instead of the prog pointer.", + "keywords": "cgroup,local,storage", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups)." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes the handling of cgroup local storage maps by using a stable prog's aux pointer instead of the prog pointer.", + "keywords": "cgroup,local,storage", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups)." + ] +} +-------------------- +-------------------- +Processing Commit 853/6895 - Commit ID: dbd8f6bae6f4a98aa517aeda6e5276ed4a20f571 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: dbd8f6bae6f4a98aa517aeda6e5276ed4a20f571 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576536929 + Commit Message: + libbpf: Add zlib as a dependency in pkg-config template List zlib as another dependency of libbpf in pkg-config template. Verified it is correctly resolved to proper -lz flag: $ make DESTDIR=/tmp/libbpf-install install $ pkg-config --libs /tmp/libbpf-install/usr/local/lib64/pkgconfig/libbpf.pc -L/usr/local/lib64 -lbpf $ pkg-config --libs --static /tmp/libbpf-install/usr/local/lib64/pkgconfig/libbpf.pc -L/usr/local/lib64 -lbpf -lelf -lz Fixes: 166750bc1dd2 ("libbpf: Support libbpf-provided extern variables") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Cc: Luca Boccassi Link: https://lore.kernel.org/bpf/20191216183830.3972964-1-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.pc.template | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: dc3a2d254782dea8e23a55f46129105ecfe787fb +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds zlib as a dependency in libbpf's pkg-config template to ensure it resolves to the correct -lz flag.", + "keywords": "zlib,libbpf,pkg-config", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds zlib dependency to libbpf's pkg-config template for correct flag resolution.", + "keywords": "zlib,libbpf,pkg-config", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 854/6895 - Commit ID: dc3a2d254782dea8e23a55f46129105ecfe787fb +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: dc3a2d254782dea8e23a55f46129105ecfe787fb + Author Name: Toke Høiland-Jørgensen + Author Email: toke@redhat.com + Commit Date: 1576536754 + Commit Message: + libbpf: Print hint about ulimit when getting permission denied error Probably the single most common error newcomers to XDP are stumped by is the 'permission denied' error they get when trying to load their program and 'ulimit -l' is set too low. For examples, see [0], [1]. Since the error code is UAPI, we can't change that. Instead, this patch adds a few heuristics in libbpf and outputs an additional hint if they are met: If an EPERM is returned on map create or program load, and geteuid() shows we are root, and the current RLIMIT_MEMLOCK is not infinity, we output a hint about raising 'ulimit -l' as an additional log line. [0] https://marc.info/?l=xdp-newbies&m=157043612505624&w=2 [1] https://github.com/xdp-project/xdp-tutorial/issues/86 Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Acked-by: Jesper Dangaard Brouer Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20191216181204.724953-1-toke@redhat.com + Changed Files: tools/lib/bpf/libbpf.c | 29 +++++++++++++++++++++++++++++; 1 file changed, 29 insertions(+) + Parent Hashes: d50ecc46d18fa19ccf06e0c4d2ee8a050c665e3d +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds a hint for XDP users on 'ulimit -l' when permission denied errors occur in libbpf.", + "keywords": "libbpf,ulimit,permission", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +Rethinking... +new content: +{ + "summary": "The commit updates libbpf to provide hints on 'ulimit -l' setting when EPERM errors occur during XDP program load.", + "keywords": "libbpf,ulimit,XDP", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +-------------------- +-------------------- +Processing Commit 855/6895 - Commit ID: a2ea07465c8d7984cc6b8b1f0b3324f9b138094a +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: a2ea07465c8d7984cc6b8b1f0b3324f9b138094a + Author Name: Daniel Borkmann + Author Email: daniel@iogearbox.net + Commit Date: 1576522769 + Commit Message: + bpf: Fix missing prog untrack in release_maps Commit da765a2f5993 ("bpf: Add poke dependency tracking for prog array maps") wrongly assumed that in case of prog load errors, we're cleaning up all program tracking via bpf_free_used_maps(). However, it can happen that we're still at the point where we didn't copy map pointers into the prog's aux section such that env->prog->aux->used_maps is still zero, running into a UAF. In such case, the verifier has similar release_maps() helper that drops references to used maps from its env. Consolidate the release code into __bpf_free_used_maps() and call it from all sides to fix it. Fixes: da765a2f5993 ("bpf: Add poke dependency tracking for prog array maps") Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/1c2909484ca524ae9f55109b06f22b6213e76376.1576514756.git.daniel@iogearbox.net + Changed Files: include/linux/bpf.h | 2 ++; kernel/bpf/core.c | 14 ++++++++++----; kernel/bpf/verifier.c | 14 ++------------; 3 files changed, 14 insertions(+), 16 deletions(-) + Parent Hashes: 5133498f4ad1123a5ffd4c08df6431dab882cc32 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes a use-after-free error by consolidating map release code to handle unused maps correctly in eBPF program tracking.", + "keywords": "prog,untrack,release_maps", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes a missing program untrack issue causing use-after-free by consolidating release code for map references in eBPF.", + "keywords": "prog,untrack,release", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 856/6895 - Commit ID: d50ecc46d18fa19ccf06e0c4d2ee8a050c665e3d +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: d50ecc46d18fa19ccf06e0c4d2ee8a050c665e3d + Author Name: Toke Høiland-Jørgensen + Author Email: toke@redhat.com + Commit Date: 1576508738 + Commit Message: + samples/bpf: Attach XDP programs in driver mode by default When attaching XDP programs, userspace can set flags to request the attach mode (generic/SKB mode, driver mode or hw offloaded mode). If no such flags are requested, the kernel will attempt to attach in driver mode, and then silently fall back to SKB mode if this fails. The silent fallback is a major source of user confusion, as users will try to load a program on a device without XDP support, and instead of an error they will get the silent fallback behaviour, not notice, and then wonder why performance is not what they were expecting. In an attempt to combat this, let's switch all the samples to default to explicitly requesting driver-mode attach. As part of this, ensure that all the userspace utilities have a switch to enable SKB mode. For those that have a switch to request driver mode, keep it but turn it into a no-op. Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Acked-by: Jesper Dangaard Brouer Acked-by: David Ahern Link: https://lore.kernel.org/bpf/20191216110742.364456-1-toke@redhat.com + Changed Files: samples/bpf/xdp1_user.c | 5 ++++-; samples/bpf/xdp_adjust_tail_user.c | 5 ++++-; samples/bpf/xdp_fwd_user.c | 17 ++++++++++++++---; samples/bpf/xdp_redirect_cpu_user.c | 4 ++++; samples/bpf/xdp_redirect_map_user.c | 5 ++++-; samples/bpf/xdp_redirect_user.c | 5 ++++-; samples/bpf/xdp_router_ipv4_user.c | 3 +++; samples/bpf/xdp_rxq_info_user.c | 4 ++++; samples/bpf/xdp_sample_pkts_user.c | 12 +++++++++---; samples/bpf/xdp_tx_iptunnel_user.c | 5 ++++-; samples/bpf/xdpsock_user.c | 5 ++++-; 11 files changed, 58 insertions(+), 12 deletions(-) + Parent Hashes: 450278977acbf494a20367c22fbb38729772d1fc +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit changes default behaviour in eBPF samples to request XDP driver-mode attachment explicitly to avoid user confusion due to silent fallback to SKB mode.", + "keywords": "XDP,driver mode,samples", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit modifies eBPF samples to default to driver-mode XDP program attachment to avoid silent fallback confusion.", + "keywords": "XDP,driver mode,samples", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 857/6895 - Commit ID: 450278977acbf494a20367c22fbb38729772d1fc +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 450278977acbf494a20367c22fbb38729772d1fc + Author Name: Toke Høiland-Jørgensen + Author Email: toke@redhat.com + Commit Date: 1576508592 + Commit Message: + samples/bpf: Set -fno-stack-protector when building BPF programs It seems Clang can in some cases turn on stack protection by default, which doesn't work with BPF. This was reported once before[0], but it seems the flag to explicitly turn off the stack protector wasn't added to the Makefile, so do that now. The symptom of this is compile errors like the following: error: :0:0: in function bpf_prog1 i32 (%struct.__sk_buff*): A call to built-in function '__stack_chk_fail' is not supported. [0] https://www.spinics.net/lists/netdev/msg556400.html Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191216103819.359535-1-toke@redhat.com + Changed Files: samples/bpf/Makefile | 1 +; 1 file changed, 1 insertion(+) + Parent Hashes: 5615ed472dc04e38a1affca69059f17c1178f770 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Added -fno-stack-protector flag to the Makefile for building BPF programs to avoid Clang's default stack protection.", + "keywords": "stack-protector,Makefile,BPF", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Added -fno-stack-protector flag to the Makefile for building BPF programs to prevent Clang from using unsupported stack protection.", + "keywords": "stack-protector,Makefile,Clang", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 858/6895 - Commit ID: 5615ed472dc04e38a1affca69059f17c1178f770 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 5615ed472dc04e38a1affca69059f17c1178f770 + Author Name: Toke Høiland-Jørgensen + Author Email: toke@redhat.com + Commit Date: 1576508290 + Commit Message: + samples/bpf: Add missing -lz to TPROGS_LDLIBS Since libbpf now links against zlib, this needs to be included in the linker invocation for the userspace programs in samples/bpf that link statically against libbpf. Fixes: 166750bc1dd2 ("libbpf: Support libbpf-provided extern variables") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Tested-by: Björn Töpel Link: https://lore.kernel.org/bpf/20191216102405.353834-1-toke@redhat.com + Changed Files: samples/bpf/Makefile | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: 5984dc6cb5aa6cce342a44f01f984fde09ed05b1 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds the zlib library to the linker flags for userspace programs in samples/bpf that link with libbpf.", + "keywords": "zlib, libbpf, linker", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds zlib linking to userspace program makefile for static linking with libbpf in samples/bpf.", + "keywords": "zlib, libbpf, linker", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 859/6895 - Commit ID: 5984dc6cb5aa6cce342a44f01f984fde09ed05b1 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 5984dc6cb5aa6cce342a44f01f984fde09ed05b1 + Author Name: Prashant Bhole + Author Email: prashantbhole.linux@gmail.com + Commit Date: 1576508130 + Commit Message: + samples/bpf: Reintroduce missed build targets Add xdp_redirect and per_socket_stats_example in build targets. They got removed from build targets in Makefile reorganization. Fixes: 1d97c6c2511f ("samples/bpf: Base target programs rules on Makefile.target") Signed-off-by: Prashant Bhole Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191216071619.25479-1-prashantbhole.linux@gmail.com + Changed Files: samples/bpf/Makefile | 2 ++; 1 file changed, 2 insertions(+) + Parent Hashes: 159ecc002b5f55f9c58de533551a2ee552861185 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit reintroduces two missed build targets in the samples/bpf Makefile.", + "keywords": "reintroduce,build,Makefile", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds xdp_redirect and per_socket_stats_example back to the build targets in the samples/bpf Makefile.", + "keywords": "build,Makefile,samples", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 860/6895 - Commit ID: 159ecc002b5f55f9c58de533551a2ee552861185 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 159ecc002b5f55f9c58de533551a2ee552861185 + Author Name: Paul Chaignon + Author Email: paul.chaignon@orange.com + Commit Date: 1576502328 + Commit Message: + bpftool: Fix compilation warning on shadowed variable The ident variable has already been declared at the top of the function and doesn't need to be re-declared. Fixes: 985ead416df39 ("bpftool: Add skeleton codegen command") Signed-off-by: Paul Chaignon Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191216112733.GA28366@Omicron + Changed Files: tools/bpf/bpftool/gen.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: a79ac2d1036a824abba982c33e938b717d1b659f +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes a compilation warning about a shadowed variable in bpftool by adjusting the variable declaration.", + "keywords": "compilation,warning,shadowed", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes a shadowed variable compilation warning in bpftool by adjusting the variable declaration.", + "keywords": "compilation,shadowed,variable", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 861/6895 - Commit ID: a79ac2d1036a824abba982c33e938b717d1b659f +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: a79ac2d1036a824abba982c33e938b717d1b659f + Author Name: Prashant Bhole + Author Email: prashantbhole.linux@gmail.com + Commit Date: 1576502056 + Commit Message: + libbpf: Fix build by renaming variables In btf__align_of() variable name 't' is shadowed by inner block declaration of another variable with same name. Patch renames variables in order to fix it. CC sharedobjs/btf.o btf.c: In function ‘btf__align_of’: btf.c:303:21: error: declaration of ‘t’ shadows a previous local [-Werror=shadow] 303 | int i, align = 1, t; | ^ btf.c:283:25: note: shadowed declaration is here 283 | const struct btf_type *t = btf__type_by_id(btf, id); | Fixes: 3d208f4ca111 ("libbpf: Expose btf__align_of() API") Signed-off-by: Prashant Bhole Signed-off-by: Daniel Borkmann Tested-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/20191216082738.28421-1-prashantbhole.linux@gmail.com + Changed Files: tools/lib/bpf/btf.c | 12 ++++++------; 1 file changed, 6 insertions(+), 6 deletions(-) + Parent Hashes: 0849e1028088fb9e3f1de577106b89a513ba986e +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit resolves a variable shadowing issue in the btf__align_of function within libbpf.", + "keywords": "libbpf,shadowing,btf", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit resolves a variable shadowing issue in the btf__align_of function within libbpf.", + "keywords": "libbpf,shadowing,btf", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 862/6895 - Commit ID: 0849e1028088fb9e3f1de577106b89a513ba986e +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 0849e1028088fb9e3f1de577106b89a513ba986e + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1576457635 + Commit Message: + Merge branch 'support-flex-arrays' Andrii Nakryiko says: ==================== Add support for flexible array accesses in a relocatable manner in BPF CO-RE. It's a typical pattern in C, and kernel in particular, to provide a fixed-length struct with zero-sized or dimensionless array at the end. In such cases variable-sized array contents follows immediately after the end of a struct. This patch set adds support for such access pattern by allowing accesses to such arrays. Patch #1 adds libbpf support. Patch #2 adds few test cases for validation. ==================== Signed-off-by: Alexei Starovoitov + Changed Files: nan + Parent Hashes: 01c6f7aaacf982fd80d5e855f0c6187d8155ffed 5f2eeceffb92a0d799b141df7af3d1ac77337dc4 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges support for flexible array accesses in BPF CO-RE by enhancing libbpf and adding test cases.", + "keywords": "flexible, array, libbpf", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges support for flexible array accesses in BPF CO-RE by enhancing libbpf and adding test cases.", + "keywords": "flexible, array, libbpf", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 863/6895 - Commit ID: 5f2eeceffb92a0d799b141df7af3d1ac77337dc4 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 5f2eeceffb92a0d799b141df7af3d1ac77337dc4 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576457631 + Commit Message: + selftests/bpf: Add flexible array relocation tests Add few tests validation CO-RE relocation handling of flexible array accesses. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191215070844.1014385-3-andriin@fb.com + Changed Files: .../testing/selftests/bpf/prog_tests/core_reloc.c | 4 +++; .../btf__core_reloc_arrays___equiv_zero_sz_arr.c | 3 ++; .../btf__core_reloc_arrays___err_bad_zero_sz_arr.c | 3 ++; .../bpf/progs/btf__core_reloc_arrays___fixed_arr.c | 3 ++; .../testing/selftests/bpf/progs/core_reloc_types.h | 39 ++++++++++++++++++++++; .../selftests/bpf/progs/test_core_reloc_arrays.c | 8 ++---; 6 files changed, 56 insertions(+), 4 deletions(-) + Parent Hashes: 1b484b301cec404e8a329f05edf848fc0a5875c0 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds tests to validate CO-RE relocation handling of flexible array accesses in BPF selftests.", + "keywords": "tests, CO-RE, relocation", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds tests to validate CO-RE relocation handling of flexible array accesses in BPF selftests.", + "keywords": "tests, CO-RE, relocation", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 864/6895 - Commit ID: 1b484b301cec404e8a329f05edf848fc0a5875c0 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 1b484b301cec404e8a329f05edf848fc0a5875c0 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576457630 + Commit Message: + libbpf: Support flexible arrays in CO-RE Some data stuctures in kernel are defined with either zero-sized array or flexible (dimensionless) array at the end of a struct. Actual data of such array follows in memory immediately after the end of that struct, forming its variable-sized "body" of elements. Support such access pattern in CO-RE relocation handling. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191215070844.1014385-2-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.c | 34 +++++++++++++++++++++++++++++-----; 1 file changed, 29 insertions(+), 5 deletions(-) + Parent Hashes: 01c6f7aaacf982fd80d5e855f0c6187d8155ffed +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Adds support for flexible arrays in CO-RE relocation handling within libbpf.", + "keywords": "flexible, CO-RE, relocation", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Adds support for flexible arrays in CO-RE relocation handling within libbpf.", + "keywords": "flexible, CO-RE, relocation", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 865/6895 - Commit ID: 01c6f7aaacf982fd80d5e855f0c6187d8155ffed +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 01c6f7aaacf982fd80d5e855f0c6187d8155ffed + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1576457062 + Commit Message: + Merge branch 'extern-var-support' Andrii Nakryiko says: ==================== It's often important for BPF program to know kernel version or some specific config values (e.g., CONFIG_HZ to convert jiffies to seconds) and change or adjust program logic based on their values. As of today, any such need has to be resolved by recompiling BPF program for specific kernel and kernel configuration. In practice this is usually achieved by using BCC and its embedded LLVM/Clang. With such set up #ifdef CONFIG_XXX and similar compile-time constructs allow to deal with kernel varieties. With CO-RE (Compile Once – Run Everywhere) approach, this is not an option, unfortunately. All such logic variations have to be done as a normal C language constructs (i.e., if/else, variables, etc), not a preprocessor directives. This patch series add support for such advanced scenarios through C extern variables. These extern variables will be recognized by libbpf and supplied through extra .extern internal map, similarly to global data. This .extern map is read-only, which allows BPF verifier to track its content precisely as constants. That gives an opportunity to have pre-compiled BPF program, which can potentially use BPF functionality (e.g., BPF helpers) or kernel features (types, fields, etc), that are available only on a subset of targeted kernels, while effectively eleminating (through verifier's dead code detection) such unsupported functionality for other kernels (typically, older versions). Patch #3 explicitly tests a scenario of using unsupported BPF helper, to validate the approach. This patch set heavily relies on BTF type information emitted by compiler for each extern variable declaration. Based on specific types, libbpf does strict checks of config data values correctness. See patch #1 for details. Outline of the patch set: - patch #1 does a small clean up of internal map names contants; - patch #2 adds all of the libbpf internal machinery for externs support, including setting up BTF information for .extern data section; - patch #3 adds support for .extern into BPF skeleton; - patch #4 adds externs selftests, as well as enhances test_skeleton.c test to validate mmap()-ed .extern datasection functionality. v3->v4: - clean up copyrights and rebase onto latest skeleton patches (Alexei); v2->v3: - truncate too long strings (Alexei); - clean ups, adding comments (Alexei); v1->v2: - use BTF type information for externs (Alexei); - add strings support; - add BPF skeleton support for .extern. ==================== Signed-off-by: Alexei Starovoitov + Changed Files: nan + Parent Hashes: f7c0bbf27ec699ec6462751f5e5450c38be4c980 330a73a7b6ca93a415de1b7da68d7a0698fe4937 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges the 'extern-var-support' branch, enabling BPF programs to use C extern variables for kernel configuration adaptation.", + "keywords": "extern variables, libbpf, BTF", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit merges 'extern-var-support' branch, enabling BPF programs to use extern variables for kernel configuration adaptation using libbpf and BTF.", + "keywords": "extern variables libbpf BTF", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 866/6895 - Commit ID: 330a73a7b6ca93a415de1b7da68d7a0698fe4937 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 330a73a7b6ca93a415de1b7da68d7a0698fe4937 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576456872 + Commit Message: + selftests/bpf: Add tests for libbpf-provided externs Add a set of tests validating libbpf-provided extern variables. One crucial feature that's tested is dead code elimination together with using invalid BPF helper. CONFIG_MISSING is not supposed to exist and should always be specified by libbpf as zero, which allows BPF verifier to correctly do branch pruning and not fail validation, when invalid BPF helper is called from dead if branch. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191214014710.3449601-5-andriin@fb.com + Changed Files: .../testing/selftests/bpf/prog_tests/core_extern.c | 195 +++++++++++++++++++++; tools/testing/selftests/bpf/prog_tests/skeleton.c | 18 +-; .../testing/selftests/bpf/progs/test_core_extern.c | 62 +++++++; tools/testing/selftests/bpf/progs/test_skeleton.c | 9 +; 4 files changed, 283 insertions(+), 1 deletion(-) + Parent Hashes: 2ad97d473db57ab866f0756806bb94515f7f2551 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds new tests for libbpf extern variables and includes checks for dead code elimination with invalid BPF helper handling.", + "keywords": "tests, libbpf, externs", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit introduces tests for libbpf extern variables focusing on dead code elimination and invalid BPF helper handling.", + "keywords": "tests, libbpf, externs", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 867/6895 - Commit ID: 2ad97d473db57ab866f0756806bb94515f7f2551 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 2ad97d473db57ab866f0756806bb94515f7f2551 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576456872 + Commit Message: + bpftool: Generate externs datasec in BPF skeleton Add support for generation of mmap()-ed read-only view of libbpf-provided extern variables. As externs are not supposed to be provided by user code (that's what .data, .bss, and .rodata is for), don't mmap() it initially. Only after skeleton load is performed, map .extern contents as read-only memory. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191214014710.3449601-4-andriin@fb.com + Changed Files: tools/bpf/bpftool/gen.c | 4 ++++; tools/lib/bpf/libbpf.c | 10 +++++-----; 2 files changed, 9 insertions(+), 5 deletions(-) + Parent Hashes: 166750bc1dd256b2184b22588fb9fe6d3fbb93ae +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds support for mapping extern variables as read-only memory in eBPF skeletons after loading.", + "keywords": "bpftool, externs, libbpf", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds support for generating externs section in BPF skeletons with read-only mmap in bpftool and libbpf.", + "keywords": "bpftool, externs, libbpf", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 868/6895 - Commit ID: 166750bc1dd256b2184b22588fb9fe6d3fbb93ae +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 166750bc1dd256b2184b22588fb9fe6d3fbb93ae + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576456872 + Commit Message: + libbpf: Support libbpf-provided extern variables Add support for extern variables, provided to BPF program by libbpf. Currently the following extern variables are supported: - LINUX_KERNEL_VERSION; version of a kernel in which BPF program is executing, follows KERNEL_VERSION() macro convention, can be 4- and 8-byte long; - CONFIG_xxx values; a set of values of actual kernel config. Tristate, boolean, strings, and integer values are supported. Set of possible values is determined by declared type of extern variable. Supported types of variables are: - Tristate values. Are represented as `enum libbpf_tristate`. Accepted values are **strictly** 'y', 'n', or 'm', which are represented as TRI_YES, TRI_NO, or TRI_MODULE, respectively. - Boolean values. Are represented as bool (_Bool) types. Accepted values are 'y' and 'n' only, turning into true/false values, respectively. - Single-character values. Can be used both as a substritute for bool/tristate, or as a small-range integer: - 'y'/'n'/'m' are represented as is, as characters 'y', 'n', or 'm'; - integers in a range [-128, 127] or [0, 255] (depending on signedness of char in target architecture) are recognized and represented with respective values of char type. - Strings. String values are declared as fixed-length char arrays. String of up to that length will be accepted and put in first N bytes of char array, with the rest of bytes zeroed out. If config string value is longer than space alloted, it will be truncated and warning message emitted. Char array is always zero terminated. String literals in config have to be enclosed in double quotes, just like C-style string literals. - Integers. 8-, 16-, 32-, and 64-bit integers are supported, both signed and unsigned variants. Libbpf enforces parsed config value to be in the supported range of corresponding integer type. Integers values in config can be: - decimal integers, with optional + and - signs; - hexadecimal integers, prefixed with 0x or 0X; - octal integers, starting with 0. Config file itself is searched in /boot/config-$(uname -r) location with fallback to /proc/config.gz, unless config path is specified explicitly through bpf_object_open_opts' kernel_config_path option. Both gzipped and plain text formats are supported. Libbpf adds explicit dependency on zlib because of this, but this shouldn't be a problem, given libelf already depends on zlib. All detected extern variables, are put into a separate .extern internal map. It, similarly to .rodata map, is marked as read-only from BPF program side, as well as is frozen on load. This allows BPF verifier to track extern values as constants and perform enhanced branch prediction and dead code elimination. This can be relied upon for doing kernel version/feature detection and using potentially unsupported field relocations or BPF helpers in a CO-RE-based BPF program, while still having a single version of BPF program running on old and new kernels. Selftests are validating this explicitly for unexisting BPF helper. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191214014710.3449601-3-andriin@fb.com + Changed Files: include/uapi/linux/btf.h | 3 +-; tools/include/uapi/linux/btf.h | 7 +-; tools/lib/bpf/Makefile | 15 +-; tools/lib/bpf/bpf_helpers.h | 9 +; tools/lib/bpf/btf.c | 9 +-; tools/lib/bpf/libbpf.c | 738 ++++++++++++++++++++++++++++++++---; tools/lib/bpf/libbpf.h | 12 +-; tools/testing/selftests/bpf/Makefile | 2 +-; 8 files changed, 729 insertions(+), 66 deletions(-) + Parent Hashes: ac9d1389631a4bee0df47e50d6bee8b94230759d +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds support for libbpf-provided extern variables in BPF programs, enhancing compatibility across different kernel versions.", + "keywords": "libbpf,extern variables,kernel", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds support for extern variables in BPF programs, improving kernel version and configuration compatibility.", + "keywords": "libbpf,extern,kernel", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 869/6895 - Commit ID: ac9d1389631a4bee0df47e50d6bee8b94230759d +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: ac9d1389631a4bee0df47e50d6bee8b94230759d + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576456872 + Commit Message: + libbpf: Extract internal map names into constants Instead of duplicating string literals, keep them in one place and consistent. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191214014710.3449601-2-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.c | 23 ++++++++++++++---------; 1 file changed, 14 insertions(+), 9 deletions(-) + Parent Hashes: f7c0bbf27ec699ec6462751f5e5450c38be4c980 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit refactors libbpf by extracting internal map names into constants for consistency.", + "keywords": "libbpf,constants,refactor", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit refactors libbpf by extracting internal map names into constants for consistency.", + "keywords": "libbpf,constants,refactor", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 870/6895 - Commit ID: f7c0bbf27ec699ec6462751f5e5450c38be4c980 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: f7c0bbf27ec699ec6462751f5e5450c38be4c980 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1576455378 + Commit Message: + Merge branch 'bpf-obj-skel' Andrii Nakryiko says: ==================== This patch set introduces an alternative and complimentary to existing libbpf API interface for working with BPF objects, maps, programs, and global data from userspace side. This approach is relying on code generation. bpftool produces a struct (a.k.a. skeleton) tailored and specific to provided BPF object file. It includes hard-coded fields and data structures for every map, program, link, and global data present. Altogether this approach significantly reduces amount of userspace boilerplate code required to open, load, attach, and work with BPF objects. It improves attach/detach story, by providing pre-allocated space for bpf_links, and ensuring they are properly detached on shutdown. It allows to do away with by name/title lookups of maps and programs, because libbpf's skeleton API, in conjunction with generated code from bpftool, is filling in hard-coded fields with actual pointers to corresponding struct bpf_map/bpf_program/bpf_link. Also, thanks to BPF array mmap() support, working with global data (variables) from userspace is now as natural as it is from BPF side: each variable is just a struct field inside skeleton struct. Furthermore, this allows to have a natural way for userspace to pre-initialize global data (including previously impossible to initialize .rodata) by just assigning values to the same per-variable fields. Libbpf will carefully take into account this initialization image, will use it to pre-populate BPF maps at creation time, and will re-mmap() BPF map's contents at exactly the same userspace memory address such that it can continue working with all the same pointers without any interruptions. If kernel doesn't support mmap(), global data will still be successfully initialized, but after map creation global data structures inside skeleton will be NULL-ed out. This allows userspace application to gracefully handle lack of mmap() support, if necessary. A bunch of selftests are also converted to using skeletons, demonstrating significant simplification of userspace part of test and reduction in amount of code necessary. v3->v4: - add OPTS_VALID check to btf_dump__emit_type_decl (Alexei); - expose skeleton as LIBBPF_API functions (Alexei); - copyright clean up, update internal map init refactor (Alexei); v2->v3: - make skeleton part of public API; - expose btf_dump__emit_type_decl and btf__align_of APIs; - move LIBBPF_API and DECLARE_LIBBPF_OPTS into libbpf_common.h for reuse; v1->v2: - checkpatch.pl and reverse Christmas tree styling (Jakub); - sanitize variable names to accomodate in-function static vars; rfc->v1: - runqslower moved out into separate patch set waiting for vmlinux.h improvements; - skeleton generation code deals with unknown internal maps more gracefully. ==================== Signed-off-by: Alexei Starovoitov + Changed Files: nan + Parent Hashes: aa915931ac3e53ccf371308e6750da510e3591dd d9c00c3b1639a3c8f46663cc042a3768d222021f +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit introduces a new libbpf API for generating skeletons to simplify BPF object handling from userspace.", + "keywords": "libbpf,skeletons,userspace", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges changes to introduce libbpf's skeleton API for easier BPF object handling in userspace.", + "keywords": "libbpf,skeleton,userspace", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 871/6895 - Commit ID: d9c00c3b1639a3c8f46663cc042a3768d222021f +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: d9c00c3b1639a3c8f46663cc042a3768d222021f + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576454286 + Commit Message: + bpftool: Add `gen skeleton` BASH completions Add BASH completions for gen sub-command. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Cc: Quentin Monnet Link: https://lore.kernel.org/bpf/20191214014341.3442258-18-andriin@fb.com + Changed Files: tools/bpf/bpftool/bash-completion/bpftool | 11 +++++++++++; 1 file changed, 11 insertions(+) + Parent Hashes: 197448eaac1ab330fb485769bccb62346ba1f458 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds BASH completions for the 'gen skeleton' sub-command in bpftool.", + "keywords": "BASH completions,gen skeleton,bpftool", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds BASH completions for the 'gen skeleton' sub-command in bpftool, enhancing user interaction utility.", + "keywords": "BASH completions,gen skeleton,bpftool", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 872/6895 - Commit ID: 197448eaac1ab330fb485769bccb62346ba1f458 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 197448eaac1ab330fb485769bccb62346ba1f458 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576454285 + Commit Message: + selftests/bpf: Add test validating data section to struct convertion layout Add a simple selftests validating datasection-to-struct layour dumping. Global variables are constructed in such a way as to cause both natural and artificial padding (through custom alignment requirement). Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191214014341.3442258-17-andriin@fb.com + Changed Files: tools/testing/selftests/bpf/prog_tests/skeleton.c | 51 +++++++++++++++++++++++; tools/testing/selftests/bpf/progs/test_skeleton.c | 37 ++++++++++++++++; 2 files changed, 88 insertions(+) + Parent Hashes: dde53c1b763b5038545efa5d812758ce589654e1 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds self-tests for validating data section to struct conversion layout in eBPF self-testing suite.", + "keywords": "selftests,bpf,datasection", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds self-tests for validating data section to struct conversion layout in eBPF self-testing suite.", + "keywords": "selftests,bpf,datasection", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 873/6895 - Commit ID: dde53c1b763b5038545efa5d812758ce589654e1 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: dde53c1b763b5038545efa5d812758ce589654e1 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576454285 + Commit Message: + selftests/bpf: Convert few more selftest to skeletons Convert few more selftests to use generated BPF skeletons as a demonstration on how to use it. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191214014341.3442258-16-andriin@fb.com + Changed Files: .../selftests/bpf/prog_tests/fentry_fexit.c | 105 ++++++++-------------; .../testing/selftests/bpf/prog_tests/fentry_test.c | 72 ++++++--------; tools/testing/selftests/bpf/prog_tests/mmap.c | 58 +++++-------; .../selftests/bpf/prog_tests/stacktrace_build_id.c | 79 ++++++----------; .../bpf/prog_tests/stacktrace_build_id_nmi.c | 84 +++++++----------; 5 files changed, 149 insertions(+), 249 deletions(-) + Parent Hashes: f3c926a4df2cddf6230c3f56b1f43e439552cdad +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Converted several selftests to use generated BPF skeletons for demonstration purposes.", + "keywords": "selftests,skeletons,skeleton", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Converted several selftests to use generated BPF skeletons for demonstration purposes.", + "keywords": "selftests,skeletons,convert", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 874/6895 - Commit ID: f3c926a4df2cddf6230c3f56b1f43e439552cdad +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: f3c926a4df2cddf6230c3f56b1f43e439552cdad + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576454285 + Commit Message: + selftests/bpf: Add BPF skeletons selftests and convert attach_probe.c Add BPF skeleton generation to selftest/bpf's Makefile. Convert attach_probe.c to use skeleton. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191214014341.3442258-15-andriin@fb.com + Changed Files: tools/testing/selftests/bpf/.gitignore | 2 +; tools/testing/selftests/bpf/Makefile | 36 ++++--; .../selftests/bpf/prog_tests/attach_probe.c | 135 +++++----------------; .../selftests/bpf/progs/test_attach_probe.c | 34 ++----; 4 files changed, 74 insertions(+), 133 deletions(-) + Parent Hashes: 985ead416df39d6fe8e89580cc1db6aa273e0175 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds BPF skeletons selftests and converts attach_probe.c to use skeleton in the selftest/bpf directory.", + "keywords": "BPF,skeleton,selftests", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds BPF skeletons selftests and converts attach_probe.c to BPF skeleton usage within the selftest/bpf directory.", + "keywords": "BPF,skeleton,selftests", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 875/6895 - Commit ID: 985ead416df39d6fe8e89580cc1db6aa273e0175 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 985ead416df39d6fe8e89580cc1db6aa273e0175 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576454285 + Commit Message: + bpftool: Add skeleton codegen command Add `bpftool gen skeleton` command, which takes in compiled BPF .o object file and dumps a BPF skeleton struct and related code to work with that skeleton. Skeleton itself is tailored to a specific structure of provided BPF object file, containing accessors (just plain struct fields) for every map and program, as well as dedicated space for bpf_links. If BPF program is using global variables, corresponding structure definitions of compatible memory layout are emitted as well, making it possible to initialize and subsequently read/update global variables values using simple and clear C syntax for accessing fields. This skeleton majorly improves usability of opening/loading/attaching of BPF object, as well as interacting with it throughout the lifetime of loaded BPF object. Generated skeleton struct has the following structure: struct { /* used by libbpf's skeleton API */ struct bpf_object_skeleton *skeleton; /* bpf_object for libbpf APIs */ struct bpf_object *obj; struct { /* for every defined map in BPF object: */ struct bpf_map *; } maps; struct { /* for every program in BPF object: */ struct bpf_program *; } progs; struct { /* for every program in BPF object: */ struct bpf_link *; } links; /* for every present global data section: */ struct __ { /* memory layout of corresponding data section, * with every defined variable represented as a struct field * with exactly the same type, but without const/volatile * modifiers, e.g.: */ int *my_var_1; ... } *; }; This provides great usability improvements: - no need to look up maps and programs by name, instead just my_obj->maps.my_map or my_obj->progs.my_prog would give necessary bpf_map/bpf_program pointers, which user can pass to existing libbpf APIs; - pre-defined places for bpf_links, which will be automatically populated for program types that libbpf knows how to attach automatically (currently tracepoints, kprobe/kretprobe, raw tracepoint and tracing programs). On tearing down skeleton, all active bpf_links will be destroyed (meaning BPF programs will be detached, if they are attached). For cases in which libbpf doesn't know how to auto-attach BPF program, user can manually create link after loading skeleton and they will be auto-detached on skeleton destruction: my_obj->links.my_fancy_prog = bpf_program__attach_cgroup_whatever( my_obj->progs.my_fancy_prog, rodata->my_var = 123; my_obj__load(skel); /* 123 will be initialization value for my_var */ After load, if kernel supports mmap() for BPF arrays, user can still read (and write for .bss and .data) variables values, but at that point it will be directly mmap()-ed to BPF array, backing global variables. This allows to seamlessly exchange data with BPF side. From userspace program's POV, all the pointers and memory contents stay the same, but mapped kernel memory changes to point to created map. If kernel doesn't yet support mmap() for BPF arrays, it's still possible to use those data section structs to pre-initialize .bss, .data, and .rodata, but after load their pointers will be reset to NULL, allowing user code to gracefully handle this condition, if necessary. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191214014341.3442258-14-andriin@fb.com + Changed Files: tools/bpf/bpftool/gen.c | 551 +++++++++++++++++++++++++++++++++++++++++++++++; tools/bpf/bpftool/main.c | 3 +-; tools/bpf/bpftool/main.h | 1 +; 3 files changed, 554 insertions(+), 1 deletion(-) + Parent Hashes: d66562fba1ce66975bd61b0786fb8b1810f33caa +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Added a new command to bpftool for generating BPF skeletons to improve usability of BPF object handling.", + "keywords": "bpftool,skeleton,command", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Added a new command to bpftool for generating BPF skeletons to improve usability of BPF object handling.", + "keywords": "bpftool,skeleton,command", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 876/6895 - Commit ID: d66562fba1ce66975bd61b0786fb8b1810f33caa +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: d66562fba1ce66975bd61b0786fb8b1810f33caa + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576454285 + Commit Message: + libbpf: Add BPF object skeleton support Add new set of APIs, allowing to open/load/attach BPF object through BPF object skeleton, generated by bpftool for a specific BPF object file. All the xxx_skeleton() APIs wrap up corresponding bpf_object_xxx() APIs, but additionally also automate map/program lookups by name, global data initialization and mmap()-ing, etc. All this greatly improves and simplifies userspace usability of working with BPF programs. See follow up patches for examples. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191214014341.3442258-13-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.c | 162 +++++++++++++++++++++++++++++++++++++++++++++++; tools/lib/bpf/libbpf.h | 38 +++++++++++; tools/lib/bpf/libbpf.map | 5 ++; 3 files changed, 205 insertions(+) + Parent Hashes: 3f51935314b8c0e0f45f28bed2e7a023b2c7627c +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds BPF object skeleton support to libbpf, improving userspace interaction with BPF programs.", + "keywords": "BPF, skeleton, libbpf", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds BPF object skeleton support in libbpf to enhance userspace interaction with BPF programs.", + "keywords": "BPF, libbpf, skeleton", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 877/6895 - Commit ID: 3f51935314b8c0e0f45f28bed2e7a023b2c7627c +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 3f51935314b8c0e0f45f28bed2e7a023b2c7627c + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576454285 + Commit Message: + libbpf: Reduce log level of supported section names dump It's quite spammy. And now that bpf_object__open() is trying to determine program type from its section name, we are getting these verbose messages all the time. Reduce their log level to DEBUG. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191214014341.3442258-12-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: 13acb508ae203075134327551a6705e6e8f23d48 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit reduces the log level of the supported section names dump in libbpf to DEBUG to reduce verbosity.", + "keywords": "log level, libbpf, debug", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit reduces the verbosity of section name logs in libbpf by setting the log level to DEBUG.", + "keywords": "log level, libbpf, debug", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 878/6895 - Commit ID: 13acb508ae203075134327551a6705e6e8f23d48 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 13acb508ae203075134327551a6705e6e8f23d48 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576454285 + Commit Message: + libbpf: Postpone BTF ID finding for TRACING programs to load phase Move BTF ID determination for BPF_PROG_TYPE_TRACING programs to a load phase. Performing it at open step is inconvenient, because it prevents BPF skeleton generation on older host kernel, which doesn't contain BTF_KIND_FUNCs information in vmlinux BTF. This is a common set up, though, when, e.g., selftests are compiled on older host kernel, but the test program itself is executed in qemu VM with bleeding edge kernel. Having this BTF searching performed at load time allows to successfully use bpf_object__open() for codegen and inspection of BPF object file. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191214014341.3442258-11-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.c | 37 ++++++++++++++++++-------------------; 1 file changed, 18 insertions(+), 19 deletions(-) + Parent Hashes: eba9c5f498a11a8558e099d14692c24f2fea27e3 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Postpones BTF ID finding for TRACING programs to the load phase in libbpf.", + "keywords": "BTF ID, TRACING programs, load phase", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing." + ] +} +Rethinking... +new content: +{ + "summary": "Postpones BTF ID finding for TRACING programs to the load phase in libbpf for improved compatibility on older kernels.", + "keywords": "BTF ID, TRACING, libbpf", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing." + ] +} +-------------------- +-------------------- +Processing Commit 879/6895 - Commit ID: eba9c5f498a11a8558e099d14692c24f2fea27e3 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: eba9c5f498a11a8558e099d14692c24f2fea27e3 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576454285 + Commit Message: + libbpf: Refactor global data map initialization Refactor global data map initialization to use anonymous mmap()-ed memory instead of malloc()-ed one. This allows to do a transparent re-mmap()-ing of already existing memory address to point to BPF map's memory after bpf_object__load() step (done in follow up patch). This choreographed setup allows to have a nice and unsurprising way to pre-initialize read-only (and r/w as well) maps by user and after BPF map creation keep working with mmap()-ed contents of this map. All in a way that doesn't require user code to update any pointers: the illusion of working with memory contents is preserved before and after actual BPF map instantiation. Selftests and runqslower example demonstrate this feature in follow up patches. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191214014341.3442258-10-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.c | 97 ++++++++++++++++++++++++++++++--------------------; 1 file changed, 59 insertions(+), 38 deletions(-) + Parent Hashes: 01af3bf06755dc5cda7050fe5d898998e5775e63 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit refactors global data map initialization in libbpf to use mmap() instead of malloc for efficient memory management.", + "keywords": "libbpf,map,mmap", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit refactors global data map initialization in libbpf to use mmap() instead of malloc for efficient memory management.", + "keywords": "libbpf,map,mmap", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 880/6895 - Commit ID: 01af3bf06755dc5cda7050fe5d898998e5775e63 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 01af3bf06755dc5cda7050fe5d898998e5775e63 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576454285 + Commit Message: + libbpf: Expose BPF program's function name Add APIs to get BPF program function name, as opposed to bpf_program__title(), which returns BPF program function's section name. Function name has a benefit of being a valid C identifier and uniquely identifies a specific BPF program, while section name can be duplicated across multiple independent BPF programs. Add also bpf_object__find_program_by_name(), similar to bpf_object__find_program_by_title(), to facilitate looking up BPF programs by their C function names. Convert one of selftests to new API for look up. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191214014341.3442258-9-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.c | 28 ++++++++++++++++++----; tools/lib/bpf/libbpf.h | 9 +++++--; tools/lib/bpf/libbpf.map | 2 ++; .../testing/selftests/bpf/prog_tests/rdonly_maps.c | 11 ++++-----; 4 files changed, 36 insertions(+), 14 deletions(-) + Parent Hashes: 9f81654eebe8de7e0db15534816d8f6c84b2e1e5 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds APIs to retrieve BPF program function names and updates existing self-tests to utilize these new APIs.", + "keywords": "libbpf,function name,API", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit introduces new APIs for accessing BPF program function names by C identifiers and updates tests to use these APIs.", + "keywords": "libbpf,APIs,function name", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 881/6895 - Commit ID: 9f81654eebe8de7e0db15534816d8f6c84b2e1e5 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 9f81654eebe8de7e0db15534816d8f6c84b2e1e5 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576454285 + Commit Message: + libbpf: Expose BTF-to-C type declaration emitting API Expose API that allows to emit type declaration and field/variable definition (if optional field name is specified) in valid C syntax for any provided BTF type. This is going to be used by bpftool when emitting data section layout as a struct. As part of making this API useful in a stand-alone fashion, move initialization of some of the internal btf_dump state to earlier phase. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191214014341.3442258-8-andriin@fb.com + Changed Files: tools/lib/bpf/btf.h | 22 ++++++++++++++++; tools/lib/bpf/btf_dump.c | 68 ++++++++++++++++++++++++++++++------------------; tools/lib/bpf/libbpf.map | 1 +; 3 files changed, 65 insertions(+), 26 deletions(-) + Parent Hashes: 3d208f4ca111a614903f49d5a77b93ddc6de294e +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit exposes an API for emitting BTF-to-C type declarations in libbpf, aiding bpftool's data section layout generation.", + "keywords": "libbpf,BTF-to-C,API", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit exposes an API for emitting BTF-to-C type declarations in libbpf, aiding bpftool's data section layout generation.", + "keywords": "libbpf,BTF-to-C,API", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 882/6895 - Commit ID: 3d208f4ca111a614903f49d5a77b93ddc6de294e +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 3d208f4ca111a614903f49d5a77b93ddc6de294e + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576454285 + Commit Message: + libbpf: Expose btf__align_of() API Expose BTF API that calculates type alignment requirements. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191214014341.3442258-7-andriin@fb.com + Changed Files: tools/lib/bpf/btf.c | 39 +++++++++++++++++++++++++++++++++++++++; tools/lib/bpf/btf.h | 1 +; tools/lib/bpf/btf_dump.c | 47 ++++++-----------------------------------------; tools/lib/bpf/libbpf.map | 1 +; 4 files changed, 47 insertions(+), 41 deletions(-) + Parent Hashes: 544402d4b49332a4a9b2b8fff20f9d9f5ef86559 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit exposes a new BTF API for determining type alignment requirements in libbpf.", + "keywords": "BTF, libbpf, alignment", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit introduces a new BTF API function to determine type alignment in the libbpf library.", + "keywords": "API, libbpf, alignment", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 883/6895 - Commit ID: 544402d4b49332a4a9b2b8fff20f9d9f5ef86559 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 544402d4b49332a4a9b2b8fff20f9d9f5ef86559 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576454285 + Commit Message: + libbpf: Extract common user-facing helpers LIBBPF_API and DECLARE_LIBBPF_OPTS are needed in many public libbpf API headers. Extract them into libbpf_common.h to avoid unnecessary interdependency between btf.h, libbpf.h, and bpf.h or code duplication. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191214014341.3442258-6-andriin@fb.com + Changed Files: tools/lib/bpf/bpf.h | 6 ++----; tools/lib/bpf/btf.h | 6 ++----; tools/lib/bpf/libbpf.h | 28 ++--------------------------; tools/lib/bpf/libbpf_common.h | 38 ++++++++++++++++++++++++++++++++++++++; 4 files changed, 44 insertions(+), 34 deletions(-) + Parent Hashes: 917f6b7b07a46e53fa73e112d23c97d1b201a877 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Refactor libbpf by extracting commonly used macros into a shared header to reduce interdependencies among header files.", + "keywords": "libbpf, helpers, refactor", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Refactor libbpf by extracting common macros into libbpf_common.h to reduce header interdependencies and code duplication.", + "keywords": "libbpf, macros, interdependency", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 884/6895 - Commit ID: 917f6b7b07a46e53fa73e112d23c97d1b201a877 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 917f6b7b07a46e53fa73e112d23c97d1b201a877 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576454284 + Commit Message: + libbpf: Add BPF_EMBED_OBJ macro for embedding BPF .o files Add a convenience macro BPF_EMBED_OBJ, which allows to embed other files (typically used to embed BPF .o files) into a hosting userspace programs. To C program it is exposed as struct bpf_embed_data, containing a pointer to raw data and its size in bytes. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191214014341.3442258-5-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.h | 35 ++++++++++++++++++++++; .../selftests/bpf/prog_tests/attach_probe.c | 23 ++------------; 2 files changed, 38 insertions(+), 20 deletions(-) + Parent Hashes: 612d05be250aa8804d3baba7a12445a267a580d3 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit introduces a macro to embed BPF .o files into userspace programs in libbpf.", + "keywords": "BPF_EMBED_OBJ,libbpf,macro", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit introduces a macro to embed BPF .o files into userspace programs in libbpf.", + "keywords": "BPF_EMBED_OBJ,libbpf,macro", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 885/6895 - Commit ID: 612d05be250aa8804d3baba7a12445a267a580d3 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 612d05be250aa8804d3baba7a12445a267a580d3 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576454284 + Commit Message: + libbpf: Move non-public APIs from libbpf.h to libbpf_internal.h Few libbpf APIs are not public but currently exposed through libbpf.h to be used by bpftool. Move them to libbpf_internal.h, where intent of being non-stable and non-public is much more obvious. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191214014341.3442258-4-andriin@fb.com + Changed Files: tools/bpf/bpftool/net.c | 1 +; tools/lib/bpf/libbpf.h | 17 -----------------; tools/lib/bpf/libbpf_internal.h | 17 +++++++++++++++++; 3 files changed, 18 insertions(+), 17 deletions(-) + Parent Hashes: d7a18ea7e8b612669acd0131fd075e5c735c1ce5 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Moved non-public libbpf APIs from libbpf.h to libbpf_internal.h for better separation.", + "keywords": "libbpf, APIs, internal", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Non-public libbpf APIs were moved to libbpf_internal.h for improved clarity on their non-public status.", + "keywords": "libbpf, internal, APIs", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 886/6895 - Commit ID: d7a18ea7e8b612669acd0131fd075e5c735c1ce5 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: d7a18ea7e8b612669acd0131fd075e5c735c1ce5 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576454284 + Commit Message: + libbpf: Add generic bpf_program__attach() Generalize BPF program attaching and allow libbpf to auto-detect type (and extra parameters, where applicable) and attach supported BPF program types based on program sections. Currently this is supported for: - kprobe/kretprobe; - tracepoint; - raw tracepoint; - tracing programs (typed raw TP/fentry/fexit). More types support can be trivially added within this framework. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191214014341.3442258-3-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.c | 181 +++++++++++++++++----; tools/lib/bpf/libbpf.h | 2 +; tools/lib/bpf/libbpf.map | 2 +; .../testing/selftests/bpf/prog_tests/probe_user.c | 6 +-; 4 files changed, 153 insertions(+), 38 deletions(-) + Parent Hashes: 0d13bfce023ac7cef4d0a50b83750254ce31c479 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit enhances libbpf by adding bpf_program__attach() to generalize BPF program attachment across multiple program types and sections.", + "keywords": "libbpf,attach,generalize", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.", + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit enhances libbpf by adding bpf_program__attach() to generalize BPF program attachment across multiple program types and sections.", + "keywords": "libbpf,attach,generalize", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.", + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 887/6895 - Commit ID: 0d13bfce023ac7cef4d0a50b83750254ce31c479 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 0d13bfce023ac7cef4d0a50b83750254ce31c479 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576454284 + Commit Message: + libbpf: Don't require root for bpf_object__open() Reorganize bpf_object__open and bpf_object__load steps such that bpf_object__open doesn't need root access. This was previously done for feature probing and BTF sanitization. This doesn't have to happen on open, though, so move all those steps into the load phase. This is important, because it makes it possible for tools like bpftool, to just open BPF object file and inspect their contents: programs, maps, BTF, etc. For such operations it is prohibitive to require root access. On the other hand, there is a lot of custom libbpf logic in those steps, so its best avoided for tools to reimplement all that on their own. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191214014341.3442258-2-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.c | 83 +++++++++++++++++++++++++-------------------------; 1 file changed, 41 insertions(+), 42 deletions(-) + Parent Hashes: aa915931ac3e53ccf371308e6750da510e3591dd +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Reorganize libbpf to allow non-root access to bpf_object__open for easier inspection of BPF object files.", + "keywords": "libbpf,non-root,bpf_object__open", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Reorganize libbpf to allow non-root access for inspecting BPF object files by deferring certain actions to the load phase.", + "keywords": "libbpf,non-root,inspection", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 888/6895 - Commit ID: aa915931ac3e53ccf371308e6750da510e3591dd +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: aa915931ac3e53ccf371308e6750da510e3591dd + Author Name: Thadeu Lima de Souza Cascardo + Author Email: cascardo@canonical.com + Commit Date: 1576431658 + Commit Message: + libbpf: Fix readelf output parsing for Fedora Fedora binutils has been patched to show "other info" for a symbol at the end of the line. This was done in order to support unmaintained scripts that would break with the extra info. [1] [1] https://src.fedoraproject.org/rpms/binutils/c/b8265c46f7ddae23a792ee8306fbaaeacba83bf8 This in turn has been done to fix the build of ruby, because of checksec. [2] Thanks Michael Ellerman for the pointer. [2] https://bugzilla.redhat.com/show_bug.cgi?id=1479302 As libbpf Makefile is not unmaintained, we can simply deal with either output format, by just removing the "other info" field, as it always comes inside brackets. Fixes: 3464afdf11f9 (libbpf: Fix readelf output parsing on powerpc with recent binutils) Reported-by: Justin Forbes Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Cc: Aurelien Jarno Link: https://lore.kernel.org/bpf/20191213101114.GA3986@calabresa + Changed Files: tools/lib/bpf/Makefile | 2 ++; 1 file changed, 2 insertions(+) + Parent Hashes: a06ae6acc14b7f8c07ce9d9685e7b90fcba5b52f +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit fixes libbpf's readelf output parsing to handle Fedora binutils changes.", + "keywords": "libbpf, readelf, Fedora", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit fixes libbpf's readelf output parsing to handle Fedora binutils format changes.", + "keywords": "libbpf, readelf, Fedora", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 889/6895 - Commit ID: a06ae6acc14b7f8c07ce9d9685e7b90fcba5b52f +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: a06ae6acc14b7f8c07ce9d9685e7b90fcba5b52f + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1576431141 + Commit Message: + Merge branch 'bpftool-match-by-name' Paul Chaignon says: ==================== When working with frequently modified BPF programs, both the ID and the tag may change. bpftool currently doesn't provide a "stable" way to match such programs. This patchset allows bpftool to match programs and maps by name. When given a tag that matches several programs, bpftool currently only considers the first match. The first patch changes that behavior to either process all matching programs (for the show and dump commands) or error out. The second patch implements program lookup by name, with the same behavior as for tags in case of ambiguity. The last patch implements map lookup by name. Changelogs: Changes in v2: - Fix buffer overflow after realloc. - Add example output to commit message. - Properly close JSON arrays on errors. - Fix style errors (line breaks, for loops, exit labels, type for tagname). - Move do_show code for argc == 2 to do_show_subset functions. - Rebase. ==================== Signed-off-by: Alexei Starovoitov + Changed Files: nan + Parent Hashes: a06bf42f5a95ff462401d59d0c08cf4620213647 99f9863a0c45f4e87cb99593015090fdc9f44398 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit allows bpftool to match BPF programs and maps by name instead of ID or tag.", + "keywords": "bpftool,programs,maps", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges a branch to enable bpftool to match BPF programs and maps by name.", + "keywords": "bpftool,programs,merge", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 890/6895 - Commit ID: 99f9863a0c45f4e87cb99593015090fdc9f44398 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 99f9863a0c45f4e87cb99593015090fdc9f44398 + Author Name: Paul Chaignon + Author Email: paul.chaignon@orange.com + Commit Date: 1576429398 + Commit Message: + bpftool: Match maps by name This patch implements lookup by name for maps and changes the behavior of lookups by tag to be consistent with prog subcommands. Similarly to program subcommands, the show and dump commands will return all maps with the given name (or tag), whereas other commands will error out if several maps have the same name (resp. tag). When a map has BTF info, it is dumped in JSON with available BTF info. This patch requires that all matched maps have BTF info before switching the output format to JSON. Signed-off-by: Paul Chaignon Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/8de1c9f273860b3ea1680502928f4da2336b853e.1576263640.git.paul.chaignon@gmail.com + Changed Files: tools/bpf/bpftool/Documentation/bpftool-map.rst | 10 +-; tools/bpf/bpftool/bash-completion/bpftool | 131 +++++++-; tools/bpf/bpftool/main.h | 2 +-; tools/bpf/bpftool/map.c | 384 +++++++++++++++++++-----; 4 files changed, 439 insertions(+), 88 deletions(-) + Parent Hashes: a7d22ca2a483d6c69c0791954447464297315ffa +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit implements name-based lookup for eBPF maps in bpftool and updates the behavior of tag-based lookups for consistency.", + "keywords": "bpftool, maps, lookup", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit implements name-based lookup for eBPF maps in bpftool and updates the behavior of tag-based lookups for consistency.", + "keywords": "bpftool, maps, lookup", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 891/6895 - Commit ID: a7d22ca2a483d6c69c0791954447464297315ffa +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: a7d22ca2a483d6c69c0791954447464297315ffa + Author Name: Paul Chaignon + Author Email: paul.chaignon@orange.com + Commit Date: 1576429398 + Commit Message: + bpftool: Match programs by name When working with frequently modified BPF programs, both the ID and the tag may change. bpftool currently doesn't provide a "stable" way to match such programs. This patch implements lookup by name for programs. The show and dump commands will return all programs with the given name, whereas other commands will error out if several programs have the same name. Signed-off-by: Paul Chaignon Signed-off-by: Alexei Starovoitov Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/b5fc1a5dcfaeb5f16fc80295cdaa606dd2d91534.1576263640.git.paul.chaignon@gmail.com + Changed Files: tools/bpf/bpftool/Documentation/bpftool-map.rst | 2 +-; tools/bpf/bpftool/Documentation/bpftool-prog.rst | 12 ++++++------; tools/bpf/bpftool/bash-completion/bpftool | 22 ++++++++++++++++------; tools/bpf/bpftool/main.h | 2 +-; tools/bpf/bpftool/prog.c | 22 ++++++++++++++++++----; 5 files changed, 42 insertions(+), 18 deletions(-) + Parent Hashes: ec2025095cf6acda3233a4301809596938b47da5 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit enables bpftool to match eBPF programs by name for better stability when IDs and tags change frequently.", + "keywords": "bpftool, match, programs", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit enables bpftool to match eBPF programs by name for better stability when IDs and tags change frequently.", + "keywords": "bpftool, match, programs", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 892/6895 - Commit ID: ec2025095cf6acda3233a4301809596938b47da5 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: ec2025095cf6acda3233a4301809596938b47da5 + Author Name: Paul Chaignon + Author Email: paul.chaignon@orange.com + Commit Date: 1576429398 + Commit Message: + bpftool: Match several programs with same tag When several BPF programs have the same tag, bpftool matches only the first (in ID order). This patch changes that behavior such that dump and show commands return all matched programs. Commands that require a single program (e.g., pin and attach) will error out if given a tag that matches several. bpftool prog dump will also error out if file or visual are given and several programs have the given tag. In the case of the dump command, a program header is added before each dump only if the tag matches several programs; this patch doesn't change the output if a single program matches. The output when several programs match thus looks as follows. $ ./bpftool prog dump xlated tag 6deef7357e7b4530 3: cgroup_skb tag 6deef7357e7b4530 gpl 0: (bf) r6 = r1 [...] 7: (95) exit 4: cgroup_skb tag 6deef7357e7b4530 gpl 0: (bf) r6 = r1 [...] 7: (95) exit Signed-off-by: Paul Chaignon Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/fb1fe943202659a69cd21dd5b907c205af1e1e22.1576263640.git.paul.chaignon@gmail.com + Changed Files: tools/bpf/bpftool/Documentation/bpftool-prog.rst | 16 +-; tools/bpf/bpftool/prog.c | 372 ++++++++++++++++-------; 2 files changed, 268 insertions(+), 120 deletions(-) + Parent Hashes: a06bf42f5a95ff462401d59d0c08cf4620213647 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit updates bpftool to handle multiple BPF programs with the same tag, improving dump and show command behavior.", + "keywords": "bpftool, multiple-programs, tag-matching", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit modifies bpftool to correctly handle multiple BPF programs sharing the same tag during dumps and shows.", + "keywords": "bpftool, multiple, tag", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 893/6895 - Commit ID: a06bf42f5a95ff462401d59d0c08cf4620213647 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: a06bf42f5a95ff462401d59d0c08cf4620213647 + Author Name: Stanislav Fomichev + Author Email: sdf@google.com + Commit Date: 1576279613 + Commit Message: + selftests/bpf: Test wire_len/gso_segs in BPF_PROG_TEST_RUN Make sure we can pass arbitrary data in wire_len/gso_segs. Signed-off-by: Stanislav Fomichev Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191213223028.161282-2-sdf@google.com + Changed Files: tools/testing/selftests/bpf/prog_tests/skb_ctx.c | 2 ++; tools/testing/selftests/bpf/progs/test_skb_ctx.c | 5 +++++; 2 files changed, 7 insertions(+) + Parent Hashes: 850a88cc4096fe1df407452ba2e4d28cf5b3eee9 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds test cases to validate passing arbitrary data in wire_len and gso_segs for BPF_PROG_TEST_RUN.", + "keywords": "selftests,bpf,wire_len", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds test cases to validate passing arbitrary data in wire_len and gso_segs for BPF_PROG_TEST_RUN.", + "keywords": "selftests,bpf,wire_len", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 894/6895 - Commit ID: 850a88cc4096fe1df407452ba2e4d28cf5b3eee9 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 850a88cc4096fe1df407452ba2e4d28cf5b3eee9 + Author Name: Stanislav Fomichev + Author Email: sdf@google.com + Commit Date: 1576279613 + Commit Message: + bpf: Expose __sk_buff wire_len/gso_segs to BPF_PROG_TEST_RUN wire_len should not be less than real len and is capped by GSO_MAX_SIZE. gso_segs is capped by GSO_MAX_SEGS. v2: * set wire_len to skb->len when passed wire_len is 0 (Alexei Starovoitov) Signed-off-by: Stanislav Fomichev Signed-off-by: Alexei Starovoitov Cc: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191213223028.161282-1-sdf@google.com + Changed Files: net/bpf/test_run.c | 19 ++++++++++++++++++-; 1 file changed, 18 insertions(+), 1 deletion(-) + Parent Hashes: 02620d9e629d217330a1e2a55f9c1e15a1af1519 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Expose wire_len and gso_segs to BPF_PROG_TEST_RUN for better testing capabilities.", + "keywords": "wire_len,gso_segs,BPF_PROG_TEST_RUN", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here." + ] +} +Rethinking... +new content: +{ + "summary": "Expose wire_len and gso_segs fields to BPF_PROG_TEST_RUN for improved testing coverage.", + "keywords": "wire_len,gso_segs,BPF_PROG_TEST_RUN", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 895/6895 - Commit ID: 5133498f4ad1123a5ffd4c08df6431dab882cc32 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 5133498f4ad1123a5ffd4c08df6431dab882cc32 + Author Name: Lorenz Bauer + Author Email: lmb@cloudflare.com + Commit Date: 1576279308 + Commit Message: + bpf: Clear skb->tstamp in bpf_redirect when necessary Redirecting a packet from ingress to egress by using bpf_redirect breaks if the egress interface has an fq qdisc installed. This is the same problem as fixed in 'commit 8203e2d844d3 ("net: clear skb->tstamp in forwarding paths") Clear skb->tstamp when redirecting into the egress path. Fixes: 80b14dee2bea ("net: Add a new socket option for a future transmit time.") Fixes: fb420d5d91c1 ("tcp/fq: move back to CLOCK_MONOTONIC") Signed-off-by: Lorenz Bauer Signed-off-by: Alexei Starovoitov Reviewed-by: Eric Dumazet Link: https://lore.kernel.org/bpf/20191213180817.2510-1-lmb@cloudflare.com + Changed Files: net/core/filter.c | 1 +; 1 file changed, 1 insertion(+) + Parent Hashes: 0af67e49b018e7280a4227bfe7b6005bc9d3e442 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit clears skb->tstamp when using bpf_redirect to prevent issues with egress interfaces having fq qdisc installed.", + "keywords": "bpf_redirect, skb->tstamp, egress", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "tc related type programs. It affects programs managing traffic control (tc) for queuing or prioritizing network traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +Rethinking... +new content: +{ + "summary": "This commit clears skb->tstamp during bpf_redirect to resolve queuing issues with fq qdisc on egress interfaces.", + "keywords": "bpf_redirect, skb_tstamp, egress", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "tc related type programs. It affects programs managing traffic control (tc) for queuing or prioritizing network traffic.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 896/6895 - Commit ID: 02620d9e629d217330a1e2a55f9c1e15a1af1519 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 02620d9e629d217330a1e2a55f9c1e15a1af1519 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1576271740 + Commit Message: + Merge branch 'bpf-dispatcher' Björn Töpel says: ==================== Overview ======== This is the 6th iteration of the series that introduces the BPF dispatcher, which is a mechanism to avoid indirect calls. The BPF dispatcher is a multi-way branch code generator, targeted for BPF programs. E.g. when an XDP program is executed via the bpf_prog_run_xdp(), it is invoked via an indirect call. With retpolines enabled, the indirect call has a substantial performance impact. The dispatcher is a mechanism that transform indirect calls to direct calls, and therefore avoids the retpoline. The dispatcher is generated using the BPF JIT, and relies on text poking provided by bpf_arch_text_poke(). The dispatcher hijacks a trampoline function it via the __fentry__ nop of the trampoline. One dispatcher instance currently supports up to 48 dispatch points. This can be extended in the future. In this series, only one dispatcher instance is supported, and the only user is XDP. The dispatcher is updated when an XDP program is attached/detached to/from a netdev. An alternative to this could have been to update the dispatcher at program load point, but as there are usually more XDP programs loaded than attached, so the latter was picked. The XDP dispatcher is always enabled, if available, because it helps even when retpolines are disabled. Please refer to the "Performance" section below. The first patch refactors the image allocation from the BPF trampoline code. Patch two introduces the dispatcher, and patch three adds a dispatcher for XDP, and wires up the XDP control-/ fast-path. Patch four adds the dispatcher to BPF_TEST_RUN. Patch five adds a simple selftest, and the last adds alignment to jump targets. I have rebased the series on commit 679152d3a32e ("libbpf: Fix printf compilation warnings on ppc64le arch"). Generated code, x86-64 ====================== The dispatcher currently has a maximum of 48 entries, where one entry is a unique BPF program. Multiple users of a dispatcher instance using the same BPF program will share that entry. The program/slot lookup is performed by a binary search, O(log n). Let's have a look at the generated code. The trampoline function has the following signature: unsigned int tramp(const void *ctx, const struct bpf_insn *insnsi, unsigned int (*bpf_func)(const void *, const struct bpf_insn *)) On Intel x86-64 this means that rdx will contain the bpf_func. To, make it easier to read, I've let the BPF programs have the following range: 0xffffffffffffffff (-1) to 0xfffffffffffffff0 (-16). 0xffffffff81c00f10 is the retpoline thunk, in this case __x86_indirect_thunk_rdx. If retpolines are disabled the thunk will be a regular indirect call. The minimal dispatcher will then look like this: ffffffffc0002000: cmp rdx,0xffffffffffffffff ffffffffc0002007: je 0xffffffffffffffff ; -1 ffffffffc000200d: jmp 0xffffffff81c00f10 A 16 entry dispatcher looks like this: ffffffffc0020000: cmp rdx,0xfffffffffffffff7 ; -9 ffffffffc0020007: jg 0xffffffffc0020130 ffffffffc002000d: cmp rdx,0xfffffffffffffff3 ; -13 ffffffffc0020014: jg 0xffffffffc00200a0 ffffffffc002001a: cmp rdx,0xfffffffffffffff1 ; -15 ffffffffc0020021: jg 0xffffffffc0020060 ffffffffc0020023: cmp rdx,0xfffffffffffffff0 ; -16 ffffffffc002002a: jg 0xffffffffc0020040 ffffffffc002002c: cmp rdx,0xfffffffffffffff0 ; -16 ffffffffc0020033: je 0xfffffffffffffff0 ; -16 ffffffffc0020039: jmp 0xffffffff81c00f10 ffffffffc002003e: xchg ax,ax ffffffffc0020040: cmp rdx,0xfffffffffffffff1 ; -15 ffffffffc0020047: je 0xfffffffffffffff1 ; -15 ffffffffc002004d: jmp 0xffffffff81c00f10 ffffffffc0020052: nop DWORD PTR [rax+rax*1+0x0] ffffffffc002005a: nop WORD PTR [rax+rax*1+0x0] ffffffffc0020060: cmp rdx,0xfffffffffffffff2 ; -14 ffffffffc0020067: jg 0xffffffffc0020080 ffffffffc0020069: cmp rdx,0xfffffffffffffff2 ; -14 ffffffffc0020070: je 0xfffffffffffffff2 ; -14 ffffffffc0020076: jmp 0xffffffff81c00f10 ffffffffc002007b: nop DWORD PTR [rax+rax*1+0x0] ffffffffc0020080: cmp rdx,0xfffffffffffffff3 ; -13 ffffffffc0020087: je 0xfffffffffffffff3 ; -13 ffffffffc002008d: jmp 0xffffffff81c00f10 ffffffffc0020092: nop DWORD PTR [rax+rax*1+0x0] ffffffffc002009a: nop WORD PTR [rax+rax*1+0x0] ffffffffc00200a0: cmp rdx,0xfffffffffffffff5 ; -11 ffffffffc00200a7: jg 0xffffffffc00200f0 ffffffffc00200a9: cmp rdx,0xfffffffffffffff4 ; -12 ffffffffc00200b0: jg 0xffffffffc00200d0 ffffffffc00200b2: cmp rdx,0xfffffffffffffff4 ; -12 ffffffffc00200b9: je 0xfffffffffffffff4 ; -12 ffffffffc00200bf: jmp 0xffffffff81c00f10 ffffffffc00200c4: nop DWORD PTR [rax+rax*1+0x0] ffffffffc00200cc: nop DWORD PTR [rax+0x0] ffffffffc00200d0: cmp rdx,0xfffffffffffffff5 ; -11 ffffffffc00200d7: je 0xfffffffffffffff5 ; -11 ffffffffc00200dd: jmp 0xffffffff81c00f10 ffffffffc00200e2: nop DWORD PTR [rax+rax*1+0x0] ffffffffc00200ea: nop WORD PTR [rax+rax*1+0x0] ffffffffc00200f0: cmp rdx,0xfffffffffffffff6 ; -10 ffffffffc00200f7: jg 0xffffffffc0020110 ffffffffc00200f9: cmp rdx,0xfffffffffffffff6 ; -10 ffffffffc0020100: je 0xfffffffffffffff6 ; -10 ffffffffc0020106: jmp 0xffffffff81c00f10 ffffffffc002010b: nop DWORD PTR [rax+rax*1+0x0] ffffffffc0020110: cmp rdx,0xfffffffffffffff7 ; -9 ffffffffc0020117: je 0xfffffffffffffff7 ; -9 ffffffffc002011d: jmp 0xffffffff81c00f10 ffffffffc0020122: nop DWORD PTR [rax+rax*1+0x0] ffffffffc002012a: nop WORD PTR [rax+rax*1+0x0] ffffffffc0020130: cmp rdx,0xfffffffffffffffb ; -5 ffffffffc0020137: jg 0xffffffffc00201d0 ffffffffc002013d: cmp rdx,0xfffffffffffffff9 ; -7 ffffffffc0020144: jg 0xffffffffc0020190 ffffffffc0020146: cmp rdx,0xfffffffffffffff8 ; -8 ffffffffc002014d: jg 0xffffffffc0020170 ffffffffc002014f: cmp rdx,0xfffffffffffffff8 ; -8 ffffffffc0020156: je 0xfffffffffffffff8 ; -8 ffffffffc002015c: jmp 0xffffffff81c00f10 ffffffffc0020161: nop DWORD PTR [rax+rax*1+0x0] ffffffffc0020169: nop DWORD PTR [rax+0x0] ffffffffc0020170: cmp rdx,0xfffffffffffffff9 ; -7 ffffffffc0020177: je 0xfffffffffffffff9 ; -7 ffffffffc002017d: jmp 0xffffffff81c00f10 ffffffffc0020182: nop DWORD PTR [rax+rax*1+0x0] ffffffffc002018a: nop WORD PTR [rax+rax*1+0x0] ffffffffc0020190: cmp rdx,0xfffffffffffffffa ; -6 ffffffffc0020197: jg 0xffffffffc00201b0 ffffffffc0020199: cmp rdx,0xfffffffffffffffa ; -6 ffffffffc00201a0: je 0xfffffffffffffffa ; -6 ffffffffc00201a6: jmp 0xffffffff81c00f10 ffffffffc00201ab: nop DWORD PTR [rax+rax*1+0x0] ffffffffc00201b0: cmp rdx,0xfffffffffffffffb ; -5 ffffffffc00201b7: je 0xfffffffffffffffb ; -5 ffffffffc00201bd: jmp 0xffffffff81c00f10 ffffffffc00201c2: nop DWORD PTR [rax+rax*1+0x0] ffffffffc00201ca: nop WORD PTR [rax+rax*1+0x0] ffffffffc00201d0: cmp rdx,0xfffffffffffffffd ; -3 ffffffffc00201d7: jg 0xffffffffc0020220 ffffffffc00201d9: cmp rdx,0xfffffffffffffffc ; -4 ffffffffc00201e0: jg 0xffffffffc0020200 ffffffffc00201e2: cmp rdx,0xfffffffffffffffc ; -4 ffffffffc00201e9: je 0xfffffffffffffffc ; -4 ffffffffc00201ef: jmp 0xffffffff81c00f10 ffffffffc00201f4: nop DWORD PTR [rax+rax*1+0x0] ffffffffc00201fc: nop DWORD PTR [rax+0x0] ffffffffc0020200: cmp rdx,0xfffffffffffffffd ; -3 ffffffffc0020207: je 0xfffffffffffffffd ; -3 ffffffffc002020d: jmp 0xffffffff81c00f10 ffffffffc0020212: nop DWORD PTR [rax+rax*1+0x0] ffffffffc002021a: nop WORD PTR [rax+rax*1+0x0] ffffffffc0020220: cmp rdx,0xfffffffffffffffe ; -2 ffffffffc0020227: jg 0xffffffffc0020240 ffffffffc0020229: cmp rdx,0xfffffffffffffffe ; -2 ffffffffc0020230: je 0xfffffffffffffffe ; -2 ffffffffc0020236: jmp 0xffffffff81c00f10 ffffffffc002023b: nop DWORD PTR [rax+rax*1+0x0] ffffffffc0020240: cmp rdx,0xffffffffffffffff ; -1 ffffffffc0020247: je 0xffffffffffffffff ; -1 ffffffffc002024d: jmp 0xffffffff81c00f10 The nops are there to align jump targets to 16 B. Performance =========== The tests were performed using the xdp_rxq_info sample program with the following command-line: 1. XDP_DRV: # xdp_rxq_info --dev eth0 --action XDP_DROP 2. XDP_SKB: # xdp_rxq_info --dev eth0 -S --action XDP_DROP 3. xdp-perf, from selftests/bpf: # test_progs -v -t xdp_perf Run with mitigations=auto ------------------------- Baseline: 1. 21.7 Mpps (21736190) 2. 3.8 Mpps (3837582) 3. 15 ns Dispatcher: 1. 30.2 Mpps (30176320) 2. 4.0 Mpps (4015579) 3. 5 ns Dispatcher (full; walk all entries, and fallback): 1. 22.0 Mpps (21986704) 2. 3.8 Mpps (3831298) 3. 17 ns Run with mitigations=off ------------------------ Baseline: 1. 29.9 Mpps (29875135) 2. 4.1 Mpps (4100179) 3. 4 ns Dispatcher: 1. 30.4 Mpps (30439241) 2. 4.1 Mpps (4109350) 1. 4 ns Dispatcher (full; walk all entries, and fallback): 1. 28.9 Mpps (28903269) 2. 4.1 Mpps (4080078) 3. 5 ns xdp-perf runs, aliged vs non-aligned jump targets ------------------------------------------------- In this test dispatchers of different sizes, with and without jump target alignment, were exercised. As outlined above the function lookup is performed via binary search. This means that depending on the pointer value of the function, it can reside in the upper or lower part of the search table. The performed tests were: 1. aligned, mititations=auto, function entry < other entries 2. aligned, mititations=auto, function entry > other entries 3. non-aligned, mititations=auto, function entry < other entries 4. non-aligned, mititations=auto, function entry > other entries 5. aligned, mititations=off, function entry < other entries 6. aligned, mititations=off, function entry > other entries 7. non-aligned, mititations=off, function entry < other entries 8. non-aligned, mititations=off, function entry > other entries The micro benchmarks showed that alignment of jump target has some positive impact. A reply to this cover letter will contain complete data for all runs. Multiple xdp-perf baseline with mitigations=auto ------------------------------------------------ Performance counter stats for './test_progs -v -t xdp_perf' (1024 runs): 16.69 msec task-clock # 0.984 CPUs utilized ( +- 0.08% ) 2 context-switches # 0.123 K/sec ( +- 1.11% ) 0 cpu-migrations # 0.000 K/sec ( +- 70.68% ) 97 page-faults # 0.006 M/sec ( +- 0.05% ) 49,254,635 cycles # 2.951 GHz ( +- 0.09% ) (12.28%) 42,138,558 instructions # 0.86 insn per cycle ( +- 0.02% ) (36.15%) 7,315,291 branches # 438.300 M/sec ( +- 0.01% ) (59.43%) 1,011,201 branch-misses # 13.82% of all branches ( +- 0.01% ) (83.31%) 15,440,788 L1-dcache-loads # 925.143 M/sec ( +- 0.00% ) (99.40%) 39,067 L1-dcache-load-misses # 0.25% of all L1-dcache hits ( +- 0.04% ) 6,531 LLC-loads # 0.391 M/sec ( +- 0.05% ) 442 LLC-load-misses # 6.76% of all LL-cache hits ( +- 0.77% ) L1-icache-loads 57,964 L1-icache-load-misses ( +- 0.06% ) 15,442,496 dTLB-loads # 925.246 M/sec ( +- 0.00% ) 514 dTLB-load-misses # 0.00% of all dTLB cache hits ( +- 0.73% ) (40.57%) 130 iTLB-loads # 0.008 M/sec ( +- 2.75% ) (16.69%) iTLB-load-misses ( +- 8.71% ) (0.60%) L1-dcache-prefetches L1-dcache-prefetch-misses 0.0169558 +- 0.0000127 seconds time elapsed ( +- 0.07% ) Multiple xdp-perf dispatcher with mitigations=auto -------------------------------------------------- Note that this includes generating the dispatcher. Performance counter stats for './test_progs -v -t xdp_perf' (1024 runs): 4.80 msec task-clock # 0.953 CPUs utilized ( +- 0.06% ) 1 context-switches # 0.258 K/sec ( +- 1.57% ) 0 cpu-migrations # 0.000 K/sec 97 page-faults # 0.020 M/sec ( +- 0.05% ) 14,185,861 cycles # 2.955 GHz ( +- 0.17% ) (50.49%) 45,691,935 instructions # 3.22 insn per cycle ( +- 0.01% ) (99.19%) 8,346,008 branches # 1738.709 M/sec ( +- 0.00% ) 13,046 branch-misses # 0.16% of all branches ( +- 0.10% ) 15,443,735 L1-dcache-loads # 3217.365 M/sec ( +- 0.00% ) 39,585 L1-dcache-load-misses # 0.26% of all L1-dcache hits ( +- 0.05% ) 7,138 LLC-loads # 1.487 M/sec ( +- 0.06% ) 671 LLC-load-misses # 9.40% of all LL-cache hits ( +- 0.73% ) L1-icache-loads 56,213 L1-icache-load-misses ( +- 0.08% ) 15,443,735 dTLB-loads # 3217.365 M/sec ( +- 0.00% ) dTLB-load-misses (0.00%) iTLB-loads (0.00%) iTLB-load-misses (0.00%) L1-dcache-prefetches L1-dcache-prefetch-misses 0.00503705 +- 0.00000546 seconds time elapsed ( +- 0.11% ) Revisions ========= v4->v5: [1] * Fixed s/xdp_ctx/ctx/ type-o (Toke) * Marked dispatcher trampoline with noinline attribute (Alexei) v3->v4: [2] * Moved away from doing dispatcher lookup based on the trampoline function, to a model where the dispatcher instance is explicitly passed to the bpf_dispatcher_change_prog() (Alexei) v2->v3: [3] * Removed xdp_call, and instead make the dispatcher available to all XDP users via bpf_prog_run_xdp() and dev_xdp_install(). (Toke) * Always enable the dispatcher, if available (Alexei) * Reuse BPF trampoline image allocator (Alexei) * Make sure the dispatcher is exercised in selftests (Alexei) * Only allow one dispatcher, and wire it to XDP v1->v2: [4] * Fixed i386 build warning (kbuild robot) * Made bpf_dispatcher_lookup() static (kbuild robot) * Make sure xdp_call.h is only enabled for builtins * Add xdp_call() to ixgbe, mlx4, and mlx5 RFC->v1: [5] * Improved error handling (Edward and Andrii) * Explicit cleanup (Andrii) * Use 32B with sext cmp (Alexei) * Align jump targets to 16B (Alexei) * 4 to 16 entries (Toke) * Added stats to xdp_call_run() [1] https://lore.kernel.org/bpf/20191211123017.13212-1-bjorn.topel@gmail.com/ [2] https://lore.kernel.org/bpf/20191209135522.16576-1-bjorn.topel@gmail.com/ [3] https://lore.kernel.org/bpf/20191123071226.6501-1-bjorn.topel@gmail.com/ [4] https://lore.kernel.org/bpf/20191119160757.27714-1-bjorn.topel@gmail.com/ [5] https://lore.kernel.org/bpf/20191113204737.31623-1-bjorn.topel@gmail.com/ ==================== Signed-off-by: Alexei Starovoitov + Changed Files: nan + Parent Hashes: 91cbdf740a476cf2c744169bf407de2e3ac1f3cf 116eb788f57c9c35c40b29cfaa2607020de99a84 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit merges the 'bpf-dispatcher' branch, introducing a mechanism to optimize XDP program execution by transforming indirect calls to direct calls using a BPF dispatcher.", + "keywords": "dispatcher,XDP,performance", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "The commit merges the 'bpf-dispatcher' branch, optimizing XDP program execution by converting indirect calls to direct calls using a BPF dispatcher mechanism.", + "keywords": "dispatcher,XDP,merge", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 897/6895 - Commit ID: 116eb788f57c9c35c40b29cfaa2607020de99a84 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 116eb788f57c9c35c40b29cfaa2607020de99a84 + Author Name: Björn Töpel + Author Email: bjorn.topel@intel.com + Commit Date: 1576271372 + Commit Message: + bpf, x86: Align dispatcher branch targets to 16B >From Intel 64 and IA-32 Architectures Optimization Reference Manual, 3.4.1.4 Code Alignment, Assembly/Compiler Coding Rule 11: All branch targets should be 16-byte aligned. This commits aligns branch targets according to the Intel manual. The nops used to align branch targets make the dispatcher larger, and therefore the number of supported dispatch points/programs are descreased from 64 to 48. Signed-off-by: Björn Töpel Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191213175112.30208-7-bjorn.topel@gmail.com + Changed Files: arch/x86/net/bpf_jit_comp.c | 30 +++++++++++++++++++++++++++++-; include/linux/bpf.h | 2 +-; 2 files changed, 30 insertions(+), 2 deletions(-) + Parent Hashes: e754f5a6e36b63d6732f52adcbe4c447fd66896f +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit aligns dispatcher branch targets to 16-byte to optimize performance according to the Intel manual, but reduces the number of supported dispatch points.", + "keywords": "dispatcher,alignment,Intel", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit aligns x86 dispatcher branch targets to 16 bytes to optimize performance based on Intel's architecture manual, reducing dispatch points.", + "keywords": "alignment,dispatcher,Intel", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 898/6895 - Commit ID: e754f5a6e36b63d6732f52adcbe4c447fd66896f +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: e754f5a6e36b63d6732f52adcbe4c447fd66896f + Author Name: Björn Töpel + Author Email: bjorn.topel@intel.com + Commit Date: 1576271372 + Commit Message: + selftests: bpf: Add xdp_perf test The xdp_perf is a dummy XDP test, only used to measure the the cost of jumping into a naive XDP program one million times. To build and run the program: $ cd tools/testing/selftests/bpf $ make $ ./test_progs -v -t xdp_perf Signed-off-by: Björn Töpel Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191213175112.30208-6-bjorn.topel@gmail.com + Changed Files: tools/testing/selftests/bpf/prog_tests/xdp_perf.c | 25 +++++++++++++++++++++++; 1 file changed, 25 insertions(+) + Parent Hashes: f23c4b3924d2e9382820ee677b68d42d5dd7b08b +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds a self-test for measuring the execution cost of a simple XDP program in the eBPF subsystem.", + "keywords": "xdp_perf,selftests,xdp", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +Rethinking... +new content: +{ + "summary": "The commit introduces a test to measure the cost of repeatedly executing a basic XDP program.", + "keywords": "xdp_perf,selftests,XDP", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +-------------------- +-------------------- +Processing Commit 899/6895 - Commit ID: f23c4b3924d2e9382820ee677b68d42d5dd7b08b +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: f23c4b3924d2e9382820ee677b68d42d5dd7b08b + Author Name: Björn Töpel + Author Email: bjorn.topel@intel.com + Commit Date: 1576271372 + Commit Message: + bpf: Start using the BPF dispatcher in BPF_TEST_RUN In order to properly exercise the BPF dispatcher, this commit adds BPF dispatcher usage to BPF_TEST_RUN when executing XDP programs. Signed-off-by: Björn Töpel Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191213175112.30208-5-bjorn.topel@gmail.com + Changed Files: net/bpf/test_run.c | 15 ++++++++++-----; 1 file changed, 10 insertions(+), 5 deletions(-) + Parent Hashes: 7e6897f95935973c3253fd756135b5ea58043dc8 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit incorporates BPF dispatcher usage in BPF_TEST_RUN for executing XDP programs.", + "keywords": "BPF dispatcher,XDP programs,BPF_TEST_RUN", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit incorporates BPF dispatcher usage in BPF_TEST_RUN for executing XDP programs.", + "keywords": "BPF dispatcher,XDP programs,BPF_TEST_RUN", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 900/6895 - Commit ID: 7e6897f95935973c3253fd756135b5ea58043dc8 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 7e6897f95935973c3253fd756135b5ea58043dc8 + Author Name: Björn Töpel + Author Email: bjorn.topel@intel.com + Commit Date: 1576271372 + Commit Message: + bpf, xdp: Start using the BPF dispatcher for XDP This commit adds a BPF dispatcher for XDP. The dispatcher is updated from the XDP control-path, dev_xdp_install(), and used when an XDP program is run via bpf_prog_run_xdp(). Signed-off-by: Björn Töpel Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191213175112.30208-4-bjorn.topel@gmail.com + Changed Files: include/linux/bpf.h | 15 +++++++++++++++; include/linux/filter.h | 40 ++++++++++++++++++++++++----------------; kernel/bpf/syscall.c | 26 ++++++++++++++++++--------; net/core/dev.c | 19 ++++++++++++++++++-; net/core/filter.c | 8 ++++++++; 5 files changed, 83 insertions(+), 25 deletions(-) + Parent Hashes: 75ccbef6369e94ecac696a152a998a978d41376b +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit implements a BPF dispatcher for XDP to optimize program execution via the control path in the Linux networking stack.", + "keywords": "BPF dispatcher, XDP, networking", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +Rethinking... +new content: +{ + "summary": "This commit implements a BPF dispatcher for XDP to optimize program execution via the control path in the Linux networking stack.", + "keywords": "BPF dispatcher XDP", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +-------------------- +-------------------- +Processing Commit 901/6895 - Commit ID: 75ccbef6369e94ecac696a152a998a978d41376b +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 75ccbef6369e94ecac696a152a998a978d41376b + Author Name: Björn Töpel + Author Email: bjorn.topel@intel.com + Commit Date: 1576271372 + Commit Message: + bpf: Introduce BPF dispatcher The BPF dispatcher is a multi-way branch code generator, mainly targeted for XDP programs. When an XDP program is executed via the bpf_prog_run_xdp(), it is invoked via an indirect call. The indirect call has a substantial performance impact, when retpolines are enabled. The dispatcher transform indirect calls to direct calls, and therefore avoids the retpoline. The dispatcher is generated using the BPF JIT, and relies on text poking provided by bpf_arch_text_poke(). The dispatcher hijacks a trampoline function it via the __fentry__ nop of the trampoline. One dispatcher instance currently supports up to 64 dispatch points. A user creates a dispatcher with its corresponding trampoline with the DEFINE_BPF_DISPATCHER macro. Signed-off-by: Björn Töpel Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191213175112.30208-3-bjorn.topel@gmail.com + Changed Files: arch/x86/net/bpf_jit_comp.c | 122 ++++++++++++++++++++++++++++++++++; include/linux/bpf.h | 56 ++++++++++++++++; kernel/bpf/Makefile | 1 +; kernel/bpf/dispatcher.c | 158 ++++++++++++++++++++++++++++++++++++++++++++; 4 files changed, 337 insertions(+) + Parent Hashes: 98e8627efcada18ac043a77b9101b4b4c768090b +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit introduces a BPF dispatcher to optimize performance by converting indirect calls to direct calls, primarily for XDP programs.", + "keywords": "BPF,dispatcher,XDP", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit introduces a BPF dispatcher to enhance performance by converting indirect to direct calls for XDP programs.", + "keywords": "BPF,dispatcher,XDP", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 902/6895 - Commit ID: 98e8627efcada18ac043a77b9101b4b4c768090b +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 98e8627efcada18ac043a77b9101b4b4c768090b + Author Name: Björn Töpel + Author Email: bjorn.topel@intel.com + Commit Date: 1576271372 + Commit Message: + bpf: Move trampoline JIT image allocation to a function Refactor the image allocation in the BPF trampoline code into a separate function, so it can be shared with the BPF dispatcher in upcoming commits. Signed-off-by: Björn Töpel Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191213175112.30208-2-bjorn.topel@gmail.com + Changed Files: include/linux/bpf.h | 1 +; kernel/bpf/trampoline.c | 24 +++++++++++++++++-------; 2 files changed, 18 insertions(+), 7 deletions(-) + Parent Hashes: 91cbdf740a476cf2c744169bf407de2e3ac1f3cf +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Refactor trampoline JIT image allocation into a separate function for shared usage with the BPF dispatcher.", + "keywords": "trampoline,JIT,allocation", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Refactor BPF trampoline image allocation into a function for use in the dispatcher.", + "keywords": "trampoline,image,allocation", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 903/6895 - Commit ID: 91cbdf740a476cf2c744169bf407de2e3ac1f3cf +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 91cbdf740a476cf2c744169bf407de2e3ac1f3cf + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576270825 + Commit Message: + selftests/bpf: Fix perf_buffer test on systems w/ offline CPUs Fix up perf_buffer.c selftest to take into account offline/missing CPUs. Fixes: ee5cf82ce04a ("selftests/bpf: test perf buffer API") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191212013621.1691858-1-andriin@fb.com + Changed Files: .../testing/selftests/bpf/prog_tests/perf_buffer.c | 29 ++++++++++++++++++----; 1 file changed, 24 insertions(+), 5 deletions(-) + Parent Hashes: 783b8f01f5942a786998f5577bd9ff3992f22a1a +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes a test for the perf_buffer API to handle offline CPUs appropriately.", + "keywords": "selftests,perf_buffer,test", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes the perf_buffer selftest to handle offline CPUs in the BPF subsystem.", + "keywords": "selftests,perf_buffer,CPUs", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events." + ] +} +-------------------- +-------------------- +Processing Commit 904/6895 - Commit ID: 783b8f01f5942a786998f5577bd9ff3992f22a1a +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 783b8f01f5942a786998f5577bd9ff3992f22a1a + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576270809 + Commit Message: + libbpf: Don't attach perf_buffer to offline/missing CPUs It's quite common on some systems to have more CPUs enlisted as "possible", than there are (and could ever be) present/online CPUs. In such cases, perf_buffer creationg will fail due to inability to create perf event on missing CPU with error like this: libbpf: failed to open perf buffer event on cpu #16: No such device This patch fixes the logic of perf_buffer__new() to ignore CPUs that are missing or currently offline. In rare cases where user explicitly listed specific CPUs to connect to, behavior is unchanged: libbpf will try to open perf event buffer on specified CPU(s) anyways. Fixes: fb84b8224655 ("libbpf: add perf buffer API") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191212013609.1691168-1-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.c | 32 +++++++++++++++++++++++++-------; 1 file changed, 25 insertions(+), 7 deletions(-) + Parent Hashes: 65bc4c4063ae36223375a920b7d116e54d7def34 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes libbpf to avoid attaching perf_buffer to CPUs that are offline or missing.", + "keywords": "libbpf,perf_buffer,CPUs", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes libbpf to avoid attaching perf_buffer to offline or missing CPUs.", + "keywords": "libbpf, perf_buffer, CPUs", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events." + ] +} +-------------------- +-------------------- +Processing Commit 905/6895 - Commit ID: 65bc4c4063ae36223375a920b7d116e54d7def34 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 65bc4c4063ae36223375a920b7d116e54d7def34 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576270795 + Commit Message: + selftests/bpf: Add CPU mask parsing tests Add a bunch of test validating CPU mask parsing logic and error handling. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191212013559.1690898-1-andriin@fb.com + Changed Files: tools/testing/selftests/bpf/prog_tests/cpu_mask.c | 78 +++++++++++++++++++++++; 1 file changed, 78 insertions(+) + Parent Hashes: 6803ee25f0ead1e836808acb14396bb9a9849113 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds tests to validate CPU mask parsing logic and error handling in the eBPF selftests.", + "keywords": "selftests, CPU mask, parsing", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds tests to validate CPU mask parsing logic and error handling in the eBPF selftests.", + "keywords": "selftests, CPU mask, parsing", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 906/6895 - Commit ID: 6803ee25f0ead1e836808acb14396bb9a9849113 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 6803ee25f0ead1e836808acb14396bb9a9849113 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576270731 + Commit Message: + libbpf: Extract and generalize CPU mask parsing logic This logic is re-used for parsing a set of online CPUs. Having it as an isolated piece of code working with input string makes it conveninent to test this logic as well. While refactoring, also improve the robustness of original implementation. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191212013548.1690564-1-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.c | 125 +++++++++++++++++++++++++++-------------; tools/lib/bpf/libbpf_internal.h | 2 +; 2 files changed, 86 insertions(+), 41 deletions(-) + Parent Hashes: 7708bd430d88309333b0d0eb7783cddd0874dd14 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit refactors and improves the robustness of CPU mask parsing logic in libbpf for better reusability and testing.", + "keywords": "CPU mask,libbpf,refactoring", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit refactors CPU mask parsing logic in libbpf for enhanced reusability and robustness.", + "keywords": "CPU mask,libbpf,robustness", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 907/6895 - Commit ID: 7708bd430d88309333b0d0eb7783cddd0874dd14 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 7708bd430d88309333b0d0eb7783cddd0874dd14 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1576269484 + Commit Message: + Merge branch 'reuseport_to_test_progs' Jakub Sitnicki says: ==================== This change has been suggested by Martin Lau [0] during a review of a related patch set that extends reuseport tests [1]. Patches 1 & 2 address a warning due to unrecognized section name from libbpf when running reuseport tests. We don't want to carry this warning into test_progs. Patches 3-8 massage the reuseport tests to ease the switch to test_progs framework. The intention here is to show the work. Happy to squash these, if needed. Patches 9-10 do the actual move and conversion to test_progs. Output from a test_progs run after changes pasted below. Thanks, Jakub [0] https://lore.kernel.org/bpf/20191123110751.6729-1-jakub@cloudflare.com/T/#m607d822caeb1eb5db101172821a78cc3896ff1c3 [1] https://lore.kernel.org/bpf/20191123110751.6729-1-jakub@cloudflare.com/T/#m55881bae9fb6e34837d07a0c0a7ffbc138f8d06f ==================== Acked-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov + Changed Files: nan + Parent Hashes: 679152d3a32e305c213f83160c328c37566ae8bc 7ee0d4e97b889c0478af9c1a6e5af658b181423f +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges reuseport tests into the test_progs framework to address a section name warning and improve test integration.", + "keywords": "reuseport,test_progs,libbpf", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges reuseport tests into the test_progs framework addressing warnings and enhancing test integration.", + "keywords": "reuseport,test,framework", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 908/6895 - Commit ID: 7ee0d4e97b889c0478af9c1a6e5af658b181423f +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 7ee0d4e97b889c0478af9c1a6e5af658b181423f + Author Name: Jakub Sitnicki + Author Email: jakub@cloudflare.com + Commit Date: 1576269480 + Commit Message: + selftests/bpf: Switch reuseport tests for test_progs framework The tests were originally written in abort-on-error style. With the switch to test_progs we can no longer do that. So at the risk of not cleaning up some resource on failure, we now return to the caller on error. That said, failure inside one test should not affect others because we run setup/cleanup before/after every test. Signed-off-by: Jakub Sitnicki Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191212102259.418536-11-jakub@cloudflare.com + Changed Files: .../selftests/bpf/prog_tests/select_reuseport.c | 267 ++++++++++-----------; 1 file changed, 131 insertions(+), 136 deletions(-) + Parent Hashes: 415bb4e125b68a3aaccb8381baaa4a06dd1dcb27 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit updates reuseport tests to use the test_progs framework instead of an abort-on-error style.", + "keywords": "reuseport,test_progs,selftests", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here." + ] +} +Rethinking... +new content: +{ + "summary": "The commit updates selftests for reuseport to use the test_progs framework instead of abort-on-error style.", + "keywords": "reuseport,test_progs,selftests", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here." + ] +} +-------------------- +-------------------- +Processing Commit 909/6895 - Commit ID: 415bb4e125b68a3aaccb8381baaa4a06dd1dcb27 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 415bb4e125b68a3aaccb8381baaa4a06dd1dcb27 + Author Name: Jakub Sitnicki + Author Email: jakub@cloudflare.com + Commit Date: 1576269480 + Commit Message: + selftests/bpf: Move reuseport tests under prog_tests/ Do a pure move the show the actual work needed to adapt the tests in subsequent patch at the cost of breaking test_progs build for the moment. Signed-off-by: Jakub Sitnicki Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191212102259.418536-10-jakub@cloudflare.com + Changed Files: tools/testing/selftests/bpf/Makefile | 2 +-; .../selftests/bpf/prog_tests/select_reuseport.c | 811 +++++++++++++++++++++; .../testing/selftests/bpf/test_select_reuseport.c | 811 ---------------------; 3 files changed, 812 insertions(+), 812 deletions(-) + Parent Hashes: 250a91d48ae7616672a34b58388620a554a00180 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Moved reuseport tests to prog_tests directory for better organization, causing temporary build issues.", + "keywords": "selftests,bpf,reuseport", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's likely a merge commit. It involves changes across multiple use cases or events.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Moved reuseport tests to the prog_tests directory to organize tests, temporarily breaking build.", + "keywords": "selftests,bpf,reuseport", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here." + ] +} +-------------------- +-------------------- +Processing Commit 910/6895 - Commit ID: 250a91d48ae7616672a34b58388620a554a00180 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 250a91d48ae7616672a34b58388620a554a00180 + Author Name: Jakub Sitnicki + Author Email: jakub@cloudflare.com + Commit Date: 1576269480 + Commit Message: + selftests/bpf: Pull up printing the test name into test runner Again, prepare for switching reuseport tests to test_progs framework. test_progs framework will print the subtest name for us if we set it. Signed-off-by: Jakub Sitnicki Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191212102259.418536-9-jakub@cloudflare.com + Changed Files: .../testing/selftests/bpf/test_select_reuseport.c | 27 ++++++++++------------; 1 file changed, 12 insertions(+), 15 deletions(-) + Parent Hashes: 9af6c84435d0252e532c7f8bb70f1ed64a22ae2a +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit refactors selftests to print test names using the test_progs framework", + "keywords": "selftests,runner,test_progs", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit updates test code to use the test_progs framework for printing test names in BPF selftests.", + "keywords": "selftests,printing,test_progs", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 911/6895 - Commit ID: 9af6c84435d0252e532c7f8bb70f1ed64a22ae2a +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 9af6c84435d0252e532c7f8bb70f1ed64a22ae2a + Author Name: Jakub Sitnicki + Author Email: jakub@cloudflare.com + Commit Date: 1576269480 + Commit Message: + selftests/bpf: Propagate errors during setup for reuseport tests Prepare for switching reuseport tests to test_progs framework, where we don't have the luxury to terminate the process on failure. Modify setup helpers to signal failure via the return value with the help of a macro similar to the one currently in use by the tests. Signed-off-by: Jakub Sitnicki Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191212102259.418536-8-jakub@cloudflare.com + Changed Files: .../testing/selftests/bpf/test_select_reuseport.c | 136 +++++++++++++--------; 1 file changed, 85 insertions(+), 51 deletions(-) + Parent Hashes: ce7cb5f3921cdf0f65ab877764265c6c0be34c3c +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit enhances error propagation in reuseport test setup for its integration into the test_progs framework.", + "keywords": "selftests,bpf,errors", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit modifies reuseport test setup to propagate errors through return values for integration with the test_progs framework.", + "keywords": "selftests,reuseport,errors", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 912/6895 - Commit ID: ce7cb5f3921cdf0f65ab877764265c6c0be34c3c +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: ce7cb5f3921cdf0f65ab877764265c6c0be34c3c + Author Name: Jakub Sitnicki + Author Email: jakub@cloudflare.com + Commit Date: 1576269480 + Commit Message: + selftests/bpf: Run reuseport tests in a loop Prepare for switching reuseport tests to test_progs framework. Loop over the tests and perform setup/cleanup for each test separately, remembering that with test_progs we can select tests to run. Signed-off-by: Jakub Sitnicki Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191212102259.418536-7-jakub@cloudflare.com + Changed Files: .../testing/selftests/bpf/test_select_reuseport.c | 55 +++++++++++++---------; 1 file changed, 34 insertions(+), 21 deletions(-) + Parent Hashes: 9936338258308aa008387dc4f9fd3f5fec6c046a +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit refactors reuseport tests to run in a loop preparing them for the test_progs framework.", + "keywords": "reuseport,tests,test_progs", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit updates reuseport tests to run in loops for preparing integration into the test_progs framework.", + "keywords": "reuseport,loop,tests", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 913/6895 - Commit ID: 9936338258308aa008387dc4f9fd3f5fec6c046a +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 9936338258308aa008387dc4f9fd3f5fec6c046a + Author Name: Jakub Sitnicki + Author Email: jakub@cloudflare.com + Commit Date: 1576269480 + Commit Message: + selftests/bpf: Unroll the main loop in reuseport test Prepare for iterating over individual tests without introducing another nested loop in the main test function. Signed-off-by: Jakub Sitnicki Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191212102259.418536-6-jakub@cloudflare.com + Changed Files: .../testing/selftests/bpf/test_select_reuseport.c | 73 ++++++++++++----------; 1 file changed, 41 insertions(+), 32 deletions(-) + Parent Hashes: a9ce4cf4e47c55ab40641b92551bc9e1de4bfa61 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit unrolls the main loop in the reuseport test for more effective iteration over individual tests.", + "keywords": "unroll,reuseport,test", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit refactors the reuseport test by unrolling the main loop to facilitate individual test iterations.", + "keywords": "unroll,reuseport,iteration", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 914/6895 - Commit ID: a9ce4cf4e47c55ab40641b92551bc9e1de4bfa61 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: a9ce4cf4e47c55ab40641b92551bc9e1de4bfa61 + Author Name: Jakub Sitnicki + Author Email: jakub@cloudflare.com + Commit Date: 1576269480 + Commit Message: + selftests/bpf: Add helpers for getting socket family & type name Having string arrays to map socket family & type to a name prevents us from unrolling the test runner loop in the subsequent patch. Introduce helpers that do the same thing. Signed-off-by: Jakub Sitnicki Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191212102259.418536-5-jakub@cloudflare.com + Changed Files: .../testing/selftests/bpf/test_select_reuseport.c | 28 +++++++++++++++++++---; 1 file changed, 25 insertions(+), 3 deletions(-) + Parent Hashes: 11f80355d4d27c7c798fc9890b4056c5d98af992 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Introduce helpers for socket family and type name mapping in selftests.", + "keywords": "helpers,socket,selftests", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Introduce helpers for mapping socket family and type names in selftests to prevent loop unrolling issues.", + "keywords": "helpers,socket,selftests", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 915/6895 - Commit ID: 11f80355d4d27c7c798fc9890b4056c5d98af992 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 11f80355d4d27c7c798fc9890b4056c5d98af992 + Author Name: Jakub Sitnicki + Author Email: jakub@cloudflare.com + Commit Date: 1576269480 + Commit Message: + selftests/bpf: Use sa_family_t everywhere in reuseport tests Update the only function that is not using sa_family_t in this source file. Signed-off-by: Jakub Sitnicki Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191212102259.418536-4-jakub@cloudflare.com + Changed Files: tools/testing/selftests/bpf/test_select_reuseport.c | 6 +++---; 1 file changed, 3 insertions(+), 3 deletions(-) + Parent Hashes: 1fbcef929d7d71321745e61e8c20b0a02bd38cf1 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Updated reuseport tests to consistently use sa_family_t type across all functions.", + "keywords": "selftests,bpf,reuseport", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Updated reuseport tests to consistently use sa_family_t type across all functions.", + "keywords": "selftests,bpf,reuseport", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 916/6895 - Commit ID: 1fbcef929d7d71321745e61e8c20b0a02bd38cf1 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 1fbcef929d7d71321745e61e8c20b0a02bd38cf1 + Author Name: Jakub Sitnicki + Author Email: jakub@cloudflare.com + Commit Date: 1576269480 + Commit Message: + selftests/bpf: Let libbpf determine program type from section name Now that libbpf can recognize SK_REUSEPORT programs, we no longer have to pass a prog_type hint before loading the object file. Signed-off-by: Jakub Sitnicki Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191212102259.418536-3-jakub@cloudflare.com + Changed Files: .../testing/selftests/bpf/progs/test_select_reuseport_kern.c | 2 +-; tools/testing/selftests/bpf/test_select_reuseport.c | 12 +++---------; 2 files changed, 4 insertions(+), 10 deletions(-) + Parent Hashes: 67d69ccdf389f3b7fabb00e2d81473a915b3b64d +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit updates selftests to use libbpf's capability to auto-detect SK_REUSEPORT program types from section names.", + "keywords": "libbpf,SK_REUSEPORT,selftests", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +Rethinking... +new content: +{ + "summary": "This commit updates selftests to use libbpf's capability to auto-detect SK_REUSEPORT program types from section names.", + "keywords": "libbpf,SK_REUSEPORT,selftests", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +-------------------- +-------------------- +Processing Commit 917/6895 - Commit ID: 67d69ccdf389f3b7fabb00e2d81473a915b3b64d +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 67d69ccdf389f3b7fabb00e2d81473a915b3b64d + Author Name: Jakub Sitnicki + Author Email: jakub@cloudflare.com + Commit Date: 1576269480 + Commit Message: + libbpf: Recognize SK_REUSEPORT programs from section name Allow loading BPF object files that contain SK_REUSEPORT programs without having to manually set the program type before load if the the section name is set to "sk_reuseport". Makes user-space code needed to load SK_REUSEPORT BPF program more concise. Signed-off-by: Jakub Sitnicki Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191212102259.418536-2-jakub@cloudflare.com + Changed Files: tools/lib/bpf/libbpf.c | 1 +; 1 file changed, 1 insertion(+) + Parent Hashes: 679152d3a32e305c213f83160c328c37566ae8bc +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit enables automatic recognition of SK_REUSEPORT programs from section names in libbpf for easier loading.", + "keywords": "SK_REUSEPORT,libbpf,section", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit enables automatic recognition of SK_REUSEPORT programs from section names in libbpf for easier loading.", + "keywords": "SK_REUSEPORT,libbpf,section", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 918/6895 - Commit ID: 679152d3a32e305c213f83160c328c37566ae8bc +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 679152d3a32e305c213f83160c328c37566ae8bc + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576187244 + Commit Message: + libbpf: Fix printf compilation warnings on ppc64le arch On ppc64le __u64 and __s64 are defined as long int and unsigned long int, respectively. This causes compiler to emit warning when %lld/%llu are used to printf 64-bit numbers. Fix this by casting to size_t/ssize_t with %zu and %zd format specifiers, respectively. v1->v2: - use size_t/ssize_t instead of custom typedefs (Martin). Fixes: 1f8e2bcb2cd5 ("libbpf: Refactor relocation handling") Fixes: abd29c931459 ("libbpf: allow specifying map definitions using BTF") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191212171918.638010-1-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.c | 37 +++++++++++++++++++------------------; 1 file changed, 19 insertions(+), 18 deletions(-) + Parent Hashes: 81c22041d9f19df07b9cba95e3cd02e0f41bc1e1 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes printf compilation warnings for 64-bit numbers in libbpf on ppc64le architecture by adjusting format specifiers.", + "keywords": "libbpf,printf,ppc64le", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes printf compilation warnings for 64-bit numbers in libbpf on ppc64le architecture by adjusting format specifiers.", + "keywords": "libbpf,printf,ppc64le", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 919/6895 - Commit ID: 148709bc278a2e49ff7b10cee2d8cdc33b894598 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 148709bc278a2e49ff7b10cee2d8cdc33b894598 + Author Name: David S. Miller + Author Email: davem@davemloft.net + Commit Date: 1576124025 + Commit Message: + Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf Alexei Starovoitov says: ==================== pull-request: bpf 2019-12-11 The following pull-request contains BPF updates for your *net* tree. We've added 8 non-merge commits during the last 1 day(s) which contain a total of 10 files changed, 126 insertions(+), 18 deletions(-). The main changes are: 1) Make BPF trampoline co-exist with ftrace-based tracers, from Alexei. 2) Fix build in minimal configurations, from Arnd. 3) Fix mips, riscv bpf_tail_call limit, from Paul. 4) Fix bpftool segfault, from Toke. 5) Fix samples/bpf, from Daniel. ==================== Signed-off-by: David S. Miller + Changed Files: nan + Parent Hashes: 24dee0c7478d1a1e00abdf5625b7f921467325dc fe3300897cbfd76c6cb825776e5ac0ca50a91ca4 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges BPF updates including fixes and improvements for compatibility and configuration.", + "keywords": "merge,BPF,updates", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges multiple BPF updates including fixes for trampolines, build configurations, and bpftool segfault.", + "keywords": "merge,BPF,fixes", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 920/6895 - Commit ID: 81c22041d9f19df07b9cba95e3cd02e0f41bc1e1 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 81c22041d9f19df07b9cba95e3cd02e0f41bc1e1 + Author Name: Daniel Borkmann + Author Email: daniel@iogearbox.net + Commit Date: 1576109761 + Commit Message: + bpf, x86, arm64: Enable jit by default when not built as always-on After Spectre 2 fix via 290af86629b2 ("bpf: introduce BPF_JIT_ALWAYS_ON config") most major distros use BPF_JIT_ALWAYS_ON configuration these days which compiles out the BPF interpreter entirely and always enables the JIT. Also given recent fix in e1608f3fa857 ("bpf: Avoid setting bpf insns pages read-only when prog is jited"), we additionally avoid fragmenting the direct map for the BPF insns pages sitting in the general data heap since they are not used during execution. Latter is only needed when run through the interpreter. Since both x86 and arm64 JITs have seen a lot of exposure over the years, are generally most up to date and maintained, there is more downside in !BPF_JIT_ALWAYS_ON configurations to have the interpreter enabled by default rather than the JIT. Add a ARCH_WANT_DEFAULT_BPF_JIT config which archs can use to set the bpf_jit_{enable,kallsyms} to 1. Back in the days the bpf_jit_kallsyms knob was set to 0 by default since major distros still had /proc/kallsyms addresses exposed to unprivileged user space which is not the case anymore. Hence both knobs are set via BPF_JIT_DEFAULT_ON which is set to 'y' in case of BPF_JIT_ALWAYS_ON or ARCH_WANT_DEFAULT_BPF_JIT. Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Acked-by: Will Deacon Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/f78ad24795c2966efcc2ee19025fa3459f622185.1575903816.git.daniel@iogearbox.net + Changed Files: arch/arm64/Kconfig | 1 +; arch/x86/Kconfig | 1 +; init/Kconfig | 7 +++++++; kernel/bpf/core.c | 4 ++--; 4 files changed, 11 insertions(+), 2 deletions(-) + Parent Hashes: bae141f54be83b06652c1d47e50e4e75ed4e9c7e +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit enables JIT by default on x86 and arm64 architectures when not built as always-on, optimizing execution performance.", + "keywords": "JIT, x86, arm64", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit enables JIT by default on x86 and arm64 architectures when not built as always-on, optimizing execution performance.", + "keywords": "JIT, x86, arm64", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 921/6895 - Commit ID: fe3300897cbfd76c6cb825776e5ac0ca50a91ca4 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: fe3300897cbfd76c6cb825776e5ac0ca50a91ca4 + Author Name: Daniel T. Lee + Author Email: danieltimlee@gmail.com + Commit Date: 1576106886 + Commit Message: + samples: bpf: fix syscall_tp due to unused syscall Currently, open() is called from the user program and it calls the syscall 'sys_openat', not the 'sys_open'. This leads to an error of the program of user side, due to the fact that the counter maps are zero since no function such 'sys_open' is called. This commit adds the kernel bpf program which are attached to the tracepoint 'sys_enter_openat' and 'sys_enter_openat'. Fixes: 1da236b6be963 ("bpf: add a test case for syscalls/sys_{enter|exit}_* tracepoints") Signed-off-by: Daniel T. Lee Signed-off-by: Alexei Starovoitov + Changed Files: samples/bpf/syscall_tp_kern.c | 18 ++++++++++++++++--; 1 file changed, 16 insertions(+), 2 deletions(-) + Parent Hashes: bba1b2a890253528c45aa66cf856f289a215bfbc +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit fixes an issue by attaching a kernel BPF program to tracepoints 'sys_enter_openat'.", + "keywords": "syscall,tracepoint,fix", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit fixes the user program error by attaching a kernel BPF program to the correct tracepoint 'sys_enter_openat'.", + "keywords": "syscall,tracepoint,fix", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing." + ] +} +-------------------- +-------------------- +Processing Commit 922/6895 - Commit ID: bba1b2a890253528c45aa66cf856f289a215bfbc +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: bba1b2a890253528c45aa66cf856f289a215bfbc + Author Name: Daniel T. Lee + Author Email: danieltimlee@gmail.com + Commit Date: 1576106848 + Commit Message: + samples: bpf: Replace symbol compare of trace_event Previously, when this sample is added, commit 1c47910ef8013 ("samples/bpf: add perf_event+bpf example"), a symbol 'sys_read' and 'sys_write' has been used without no prefixes. But currently there are no exact symbols with these under kallsyms and this leads to failure. This commit changes exact compare to substring compare to keep compatible with exact symbol or prefixed symbol. Fixes: 1c47910ef8013 ("samples/bpf: add perf_event+bpf example") Signed-off-by: Daniel T. Lee Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191205080114.19766-2-danieltimlee@gmail.com + Changed Files: samples/bpf/trace_event_user.c | 4 ++--; 1 file changed, 2 insertions(+), 2 deletions(-) + Parent Hashes: 7f193c2519a3dcfd61cd5e676b2959370f4b15be +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit changes symbol comparison to substring comparison in bpf samples for better compatibility with kallsyms.", + "keywords": "substring, compatibility, kallsyms", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events." + ] +} +Rethinking... +new content: +{ + "summary": "The commit updates the symbol comparison method in bpf samples for improved compatibility with current kallsyms symbols.", + "keywords": "symbol, comparison, kallsyms", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 923/6895 - Commit ID: 7f193c2519a3dcfd61cd5e676b2959370f4b15be +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 7f193c2519a3dcfd61cd5e676b2959370f4b15be + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1576106369 + Commit Message: + selftests/bpf: Test function_graph tracer and bpf trampoline together Add simple test script to execute funciton graph tracer while BPF trampoline attaches and detaches from the functions being graph traced. Signed-off-by: Alexei Starovoitov Acked-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191209000114.1876138-4-ast@kernel.org + Changed Files: tools/testing/selftests/bpf/test_ftrace.sh | 39 ++++++++++++++++++++++++++++++; 1 file changed, 39 insertions(+) + Parent Hashes: b91e014f078e2e4f24778680e28dbbdecc7f0eb9 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Adds a test script to run function graph tracer with BPF trampoline.", + "keywords": "selftests tracer trampoline", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Adds a test script to run function graph tracer with BPF trampoline.", + "keywords": "selftests tracer trampoline", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 924/6895 - Commit ID: b91e014f078e2e4f24778680e28dbbdecc7f0eb9 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: b91e014f078e2e4f24778680e28dbbdecc7f0eb9 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1576106288 + Commit Message: + bpf: Make BPF trampoline use register_ftrace_direct() API Make BPF trampoline attach its generated assembly code to kernel functions via register_ftrace_direct() API. It helps ftrace-based tracers co-exist with BPF trampoline on the same kernel function. It also switches attaching logic from arch specific text_poke to generic ftrace that is available on many architectures. text_poke is still necessary for bpf-to-bpf attach and for bpf_tail_call optimization. Signed-off-by: Alexei Starovoitov Acked-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191209000114.1876138-3-ast@kernel.org + Changed Files: include/linux/bpf.h | 1 +; kernel/bpf/trampoline.c | 64 ++++++++++++++++++++++++++++++++++++++++++++-----; 2 files changed, 59 insertions(+), 6 deletions(-) + Parent Hashes: 5b79bcdf03628a3a9ee04d9cd5fabcf61a8e20be +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit modifies the BPF trampoline to use the register_ftrace_direct() API for attaching assembly code to kernel functions, improving compatibility with ftrace-based tracers.", + "keywords": "BPF, trampoline, ftrace", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit changes BPF trampoline to use register_ftrace_direct() API for attaching to kernel functions, enhancing compatibility with ftrace-based tracers.", + "keywords": "BPF, trampoline, ftrace", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 925/6895 - Commit ID: bae141f54be83b06652c1d47e50e4e75ed4e9c7e +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: bae141f54be83b06652c1d47e50e4e75ed4e9c7e + Author Name: Daniel Borkmann + Author Email: daniel@iogearbox.net + Commit Date: 1576082469 + Commit Message: + bpf: Emit audit messages upon successful prog load and unload Allow for audit messages to be emitted upon BPF program load and unload for having a timeline of events. The load itself is in syscall context, so additional info about the process initiating the BPF prog creation can be logged and later directly correlated to the unload event. The only info really needed from BPF side is the globally unique prog ID where then audit user space tooling can query / dump all info needed about the specific BPF program right upon load event and enrich the record, thus these changes needed here can be kept small and non-intrusive to the core. Raw example output: # auditctl -D # auditctl -a always,exit -F arch=x86_64 -S bpf # ausearch --start recent -m 1334 ... ---- time->Wed Nov 27 16:04:13 2019 type=PROCTITLE msg=audit(1574867053.120:84664): proctitle="./bpf" type=SYSCALL msg=audit(1574867053.120:84664): arch=c000003e syscall=321 \ success=yes exit=3 a0=5 a1=7ffea484fbe0 a2=70 a3=0 items=0 ppid=7477 \ pid=12698 auid=1001 uid=1001 gid=1001 euid=1001 suid=1001 fsuid=1001 \ egid=1001 sgid=1001 fsgid=1001 tty=pts2 ses=4 comm="bpf" \ exe="/home/jolsa/auditd/audit-testsuite/tests/bpf/bpf" \ subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) type=UNKNOWN[1334] msg=audit(1574867053.120:84664): prog-id=76 op=LOAD ---- time->Wed Nov 27 16:04:13 2019 type=UNKNOWN[1334] msg=audit(1574867053.120:84665): prog-id=76 op=UNLOAD ... Signed-off-by: Daniel Borkmann Co-developed-by: Jiri Olsa Signed-off-by: Jiri Olsa Acked-by: Paul Moore Link: https://lore.kernel.org/bpf/20191206214934.11319-1-jolsa@kernel.org + Changed Files: include/uapi/linux/audit.h | 1 +; kernel/bpf/syscall.c | 33 +++++++++++++++++++++++++++++++++; 2 files changed, 34 insertions(+) + Parent Hashes: b590cb5f802dc20c72f507f7fbe6737222d0afba +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds audit message emission capability for BPF program load and unload events.", + "keywords": "audit,load,unload", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit implements audit message generation for BPF program load and unload to provide event history.", + "keywords": "audit,program,events", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The syscall interface. It changes the system calls through which user-space programs interact with eBPF.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 926/6895 - Commit ID: b590cb5f802dc20c72f507f7fbe6737222d0afba +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: b590cb5f802dc20c72f507f7fbe6737222d0afba + Author Name: Stanislav Fomichev + Author Email: sdf@google.com + Commit Date: 1576072338 + Commit Message: + bpf: Switch to offsetofend in BPF_PROG_TEST_RUN Switch existing pattern of "offsetof(..., member) + FIELD_SIZEOF(..., member)' to "offsetofend(..., member)" which does exactly what we need without all the copy-paste. Suggested-by: Andrii Nakryiko Signed-off-by: Stanislav Fomichev Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20191210191933.105321-1-sdf@google.com + Changed Files: net/bpf/test_run.c | 12 ++++--------; 1 file changed, 4 insertions(+), 8 deletions(-) + Parent Hashes: 09c4708d3cf42b2b2211b1aee82e7baf446a24e8 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Switches BPF_PROG_TEST_RUN to use offsetofend for cleaner code.", + "keywords": "offsetofend, BPF_PROG_TEST_RUN, refactoring", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Switches BPF_PROG_TEST_RUN to use offsetofend for cleaner code.", + "keywords": "offsetofend, BPF_PROG_TEST_RUN, refactoring", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 927/6895 - Commit ID: 09c4708d3cf42b2b2211b1aee82e7baf446a24e8 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 09c4708d3cf42b2b2211b1aee82e7baf446a24e8 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1576072237 + Commit Message: + libbpf: Bump libpf current version to v0.0.7 New development cycles starts, bump to v0.0.7 proactively. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191209224022.3544519-1-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.map | 3 +++; 1 file changed, 3 insertions(+) + Parent Hashes: c453312857ba41129db3558f5428405bbbb8f1a4 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit bumps the libbpf version to v0.0.7 indicating the start of a new development cycle.", + "keywords": "libbpf,version,bump", + "commit_classification": "It's other type of commit. It does not fit into any of the categories listed above.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit bumps the libbpf version to v0.0.7 indicating the start of a new development cycle.", + "keywords": "libbpf,version,bump", + "commit_classification": "It's other type of commit. It does not fit into any of the categories listed above.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 928/6895 - Commit ID: c453312857ba41129db3558f5428405bbbb8f1a4 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: c453312857ba41129db3558f5428405bbbb8f1a4 + Author Name: Russell King + Author Email: rmk+kernel@armlinux.org.uk + Commit Date: 1576071266 + Commit Message: + ARM: net: bpf: Improve prologue code sequence Improve the prologue code sequence to be able to take advantage of 64-bit stores, changing the code from: push {r4, r5, r6, r7, r8, r9, fp, lr} mov fp, sp sub ip, sp, #80 ; 0x50 sub sp, sp, #600 ; 0x258 str ip, [fp, #-100] ; 0xffffff9c mov r6, #0 str r6, [fp, #-96] ; 0xffffffa0 mov r4, #0 mov r3, r4 mov r2, r0 str r4, [fp, #-104] ; 0xffffff98 str r4, [fp, #-108] ; 0xffffff94 to the tighter: push {r4, r5, r6, r7, r8, r9, fp, lr} mov fp, sp mov r3, #0 sub r2, sp, #80 ; 0x50 sub sp, sp, #600 ; 0x258 strd r2, [fp, #-100] ; 0xffffff9c mov r2, #0 strd r2, [fp, #-108] ; 0xffffff94 mov r2, r0 resulting in a saving of three instructions. Signed-off-by: Russell King Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/E1ieH2g-0004ih-Rb@rmk-PC.armlinux.org.uk + Changed Files: arch/arm/net/bpf_jit_32.c | 30 +++++++++++++-----------------; 1 file changed, 13 insertions(+), 17 deletions(-) + Parent Hashes: c21939998802b48e7afd0c0568193f6e4e4954f8 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit optimizes the ARM BPF JIT prologue code by utilizing 64-bit stores, improving efficiency and reducing instruction count.", + "keywords": "ARM,JIT,optimization", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit optimizes the ARM BPF JIT prologue code by utilizing 64-bit stores, improving efficiency and reducing instruction count.", + "keywords": "ARM,JIT,optimization", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 929/6895 - Commit ID: 761bfc33dd7504de951aa7b9db27a3cc5df1fde6 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 761bfc33dd7504de951aa7b9db27a3cc5df1fde6 + Author Name: Arnaldo Carvalho de Melo + Author Email: acme@redhat.com + Commit Date: 1576069096 + Commit Message: + Merge remote-tracking branch 'torvalds/master' into perf/urgent To pick up BPF fixes to allow a clean 'make -C tools/perf build-test': 7c3977d1e804 libbpf: Fix sym->st_value print on 32-bit arches 1fd450f99272 libbpf: Fix up generation of bpf_helper_defs.h Signed-off-by: Arnaldo Carvalho de Melo + Changed Files: nan + Parent Hashes: 0f60a0bcc1b96d531fa623ab520f863f1292c75b 6794862a16ef41f753abd75c03a152836e4c8028 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges changes from the 'torvalds/master' branch into 'perf/urgent' for BPF fixes to enable tools/perf build-test.", + "keywords": "merge, BPF, fixes", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges changes from the 'torvalds/master' branch into 'perf/urgent' focusing on BPF fixes for build compatibility.", + "keywords": "merge, BPF, fixes", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 930/6895 - Commit ID: 5b79bcdf03628a3a9ee04d9cd5fabcf61a8e20be +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 5b79bcdf03628a3a9ee04d9cd5fabcf61a8e20be + Author Name: Toke Høiland-Jørgensen + Author Email: toke@redhat.com + Commit Date: 1576069046 + Commit Message: + bpftool: Don't crash on missing jited insns or ksyms When the kptr_restrict sysctl is set, the kernel can fail to return jited_ksyms or jited_prog_insns, but still have positive values in nr_jited_ksyms and jited_prog_len. This causes bpftool to crash when trying to dump the program because it only checks the len fields not the actual pointers to the instructions and ksyms. Fix this by adding the missing checks. Fixes: 71bb428fe2c1 ("tools: bpf: add bpftool") Fixes: f84192ee00b7 ("tools: bpftool: resolve calls without using imm field") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191210181412.151226-1-toke@redhat.com + Changed Files: tools/bpf/bpftool/prog.c | 2 +-; tools/bpf/bpftool/xlated_dumper.c | 2 +-; 2 files changed, 2 insertions(+), 2 deletions(-) + Parent Hashes: 4c80c7bc583a87ded5f61906f81256b57c795806 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes a crash in bpftool when handling missing jited instructions or ksyms by adding checks.", + "keywords": "bpftool,crash,checks", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes a crash in bpftool by adding checks for missing jited instructions or ksyms.", + "keywords": "bpftool,crash,checks", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 931/6895 - Commit ID: 4c80c7bc583a87ded5f61906f81256b57c795806 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 4c80c7bc583a87ded5f61906f81256b57c795806 + Author Name: Arnd Bergmann + Author Email: arnd@arndb.de + Commit Date: 1576069046 + Commit Message: + bpf: Fix build in minimal configurations, again Building with -Werror showed another failure: kernel/bpf/btf.c: In function 'btf_get_prog_ctx_type.isra.31': kernel/bpf/btf.c:3508:63: error: array subscript 0 is above array bounds of 'u8[0]' {aka 'unsigned char[0]'} [-Werror=array-bounds] ctx_type = btf_type_member(conv_struct) + bpf_ctx_convert_map[prog_type] * 2; I don't actually understand why the array is empty, but a similar fix has addressed a related problem, so I suppose we can do the same thing here. Fixes: ce27709b8162 ("bpf: Fix build in minimal configurations") Signed-off-by: Arnd Bergmann Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191210203553.2941035-1-arnd@arndb.de + Changed Files: kernel/bpf/btf.c | 1 +; 1 file changed, 1 insertion(+) + Parent Hashes: e49e6f6db04e915dccb494ae10fa14888fea6f89 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes a build error in btf.c related to array bounds in minimal configuration builds.", + "keywords": "build,error,array", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes a build error in btf.c related to array bounds in minimal configuration builds.", + "keywords": "build,error,array", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 932/6895 - Commit ID: e49e6f6db04e915dccb494ae10fa14888fea6f89 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: e49e6f6db04e915dccb494ae10fa14888fea6f89 + Author Name: Paul Chaignon + Author Email: paul.chaignon@orange.com + Commit Date: 1576069042 + Commit Message: + bpf, mips: Limit to 33 tail calls All BPF JIT compilers except RISC-V's and MIPS' enforce a 33-tail calls limit at runtime. In addition, a test was recently added, in tailcalls2, to check this limit. This patch updates the tail call limit in MIPS' JIT compiler to allow 33 tail calls. Fixes: b6bd53f9c4e8 ("MIPS: Add missing file for eBPF JIT.") Reported-by: Mahshid Khezri Signed-off-by: Paul Chaignon Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/b8eb2caac1c25453c539248e56ca22f74b5316af.1575916815.git.paul.chaignon@gmail.com + Changed Files: arch/mips/net/ebpf_jit.c | 9 +++++----; 1 file changed, 5 insertions(+), 4 deletions(-) + Parent Hashes: 96bc4432f5ade1045521f3b247f516b1478166bd +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit updates the MIPS eBPF JIT compiler to enforce a limit of 33 tail calls.", + "keywords": "MIPS,JIT,tail", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "The commit updates the MIPS eBPF JIT compiler to enforce a limit of 33 tail calls.", + "keywords": "MIPS,JIT,tail", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 933/6895 - Commit ID: 96bc4432f5ade1045521f3b247f516b1478166bd +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 96bc4432f5ade1045521f3b247f516b1478166bd + Author Name: Paul Chaignon + Author Email: paul.chaignon@orange.com + Commit Date: 1576069037 + Commit Message: + bpf, riscv: Limit to 33 tail calls All BPF JIT compilers except RISC-V's and MIPS' enforce a 33-tail calls limit at runtime. In addition, a test was recently added, in tailcalls2, to check this limit. This patch updates the tail call limit in RISC-V's JIT compiler to allow 33 tail calls. I tested it using the above selftest on an emulated RISCV64. Fixes: 2353ecc6f91f ("bpf, riscv: add BPF JIT for RV64G") Reported-by: Mahshid Khezri Signed-off-by: Paul Chaignon Signed-off-by: Daniel Borkmann Acked-by: Björn Töpel Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/966fe384383bf23a0ee1efe8d7291c78a3fb832b.1575916815.git.paul.chaignon@gmail.com + Changed Files: arch/riscv/net/bpf_jit_comp.c | 4 ++--; 1 file changed, 2 insertions(+), 2 deletions(-) + Parent Hashes: 24dee0c7478d1a1e00abdf5625b7f921467325dc +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit updates RISC-V's BPF JIT compiler to enforce a 33-tail calls limit.", + "keywords": "RISC-V, JIT, tail-calls", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit updates RISC-V's BPF JIT compiler to enforce a 33-tail calls limit.", + "keywords": "RISC-V, JIT, tail-calls", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 934/6895 - Commit ID: 95e6ba5133163f8241c9ea2439369cec0452fec6 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 95e6ba5133163f8241c9ea2439369cec0452fec6 + Author Name: Linus Torvalds + Author Email: torvalds@linux-foundation.org + Commit Date: 1575840491 + Commit Message: + Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from David Miller: 1) More jumbo frame fixes in r8169, from Heiner Kallweit. 2) Fix bpf build in minimal configuration, from Alexei Starovoitov. 3) Use after free in slcan driver, from Jouni Hogander. 4) Flower classifier port ranges don't work properly in the HW offload case, from Yoshiki Komachi. 5) Use after free in hns3_nic_maybe_stop_tx(), from Yunsheng Lin. 6) Out of bounds access in mqprio_dump(), from Vladyslav Tarasiuk. 7) Fix flow dissection in dsa TX path, from Alexander Lobakin. 8) Stale syncookie timestampe fixes from Guillaume Nault. [ Did an evil merge to silence a warning introduced by this pull - Linus ] * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (84 commits) r8169: fix rtl_hw_jumbo_disable for RTL8168evl net_sched: validate TCA_KIND attribute in tc_chain_tmplt_add() r8169: add missing RX enabling for WoL on RTL8125 vhost/vsock: accept only packets with the right dst_cid net: phy: dp83867: fix hfs boot in rgmii mode net: ethernet: ti: cpsw: fix extra rx interrupt inet: protect against too small mtu values. gre: refetch erspan header from skb->data after pskb_may_pull() pppoe: remove redundant BUG_ON() check in pppoe_pernet tcp: Protect accesses to .ts_recent_stamp with {READ,WRITE}_ONCE() tcp: tighten acceptance of ACKs not matching a child socket tcp: fix rejected syncookies due to stale timestamps lpc_eth: kernel BUG on remove tcp: md5: fix potential overestimation of TCP option space net: sched: allow indirect blocks to bind to clsact in TC net: core: rename indirect block ingress cb function net-sysfs: Call dev_hold always in netdev_queue_add_kobject net: dsa: fix flow dissection on Tx path net/tls: Fix return values to avoid ENOTSUPP net: avoid an indirect call in ____sys_recvmsg() ... + Changed Files: nan + Parent Hashes: 138f371ddf4ff50207dbe33ebfc237e756cd6222 0fc75219fe9a3c90631453e9870e4f6d956f0ebc +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit merges networking fixes including bpf build and multiple driver bugs from the netdev repository by David Miller.", + "keywords": "networking,fixes,merge", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "The commit merges networking fixes including bpf build and multiple driver bugs from the netdev repository by David Miller.", + "keywords": "networking,fixes,merge", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 935/6895 - Commit ID: ae72555b410410568b493f8735324f8e9bd7c051 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: ae72555b410410568b493f8735324f8e9bd7c051 + Author Name: David S. Miller + Author Email: davem@davemloft.net + Commit Date: 1575619455 + Commit Message: + Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf Alexei Starovoitov says: ==================== pull-request: bpf 2019-12-05 The following pull-request contains BPF updates for your *net* tree. We've added 6 non-merge commits during the last 1 day(s) which contain a total of 14 files changed, 116 insertions(+), 37 deletions(-). The main changes are: 1) three selftests fixes, from Stanislav. 2) one samples fix, from Jesper. 3) one verifier fix, from Yonghong. ==================== Signed-off-by: David S. Miller + Changed Files: nan + Parent Hashes: 0033b34a03ec5cf747cdaf9b1f9dceb91c020f17 8f9081c92523328aa569d09051add79a6c0ae9ff +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Merge commit integrating BPF updates into the net tree, with fixes in selftests, samples, and verifier.", + "keywords": "BPF, merge, updates", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "Merge commit integrating BPF updates into the net tree, including fixes for selftests, samples, and verifier.", + "keywords": "BPF, merge, updates", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 936/6895 - Commit ID: 0033b34a03ec5cf747cdaf9b1f9dceb91c020f17 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 0033b34a03ec5cf747cdaf9b1f9dceb91c020f17 + Author Name: Eric Biggers + Author Email: ebiggers@google.com + Commit Date: 1575585919 + Commit Message: + ppp: fix out-of-bounds access in bpf_prog_create() sock_fprog_kern::len is in units of struct sock_filter, not bytes. Fixes: 3e859adf3643 ("compat_ioctl: unify copy-in of ppp filters") Reported-by: syzbot+eb853b51b10f1befa0b7@syzkaller.appspotmail.com Signed-off-by: Eric Biggers Reviewed-by: Arnd Bergmann Signed-off-by: David S. Miller + Changed Files: drivers/net/ppp/ppp_generic.c | 5 +++--; 1 file changed, 3 insertions(+), 2 deletions(-) + Parent Hashes: a116f4e238cc20dfbac30c65949752798f5b6efa +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes an out-of-bounds access issue in bpf_prog_create with sock_fprog_kern::len.", + "keywords": "ppp out-of-bounds sock_fprog_kern", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes an out-of-bounds access issue in bpf_prog_create with sock_fprog_kern::len.", + "keywords": "ppp out-of-bounds sock_fprog_kern", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "It's not related to any above. E.g. It affects a logic component in eBPF that is not listed here and not related to other events.", + "usecases_or_submodule_events": [ + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here." + ] +} +-------------------- +-------------------- +Processing Commit 937/6895 - Commit ID: 8f9081c92523328aa569d09051add79a6c0ae9ff +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 8f9081c92523328aa569d09051add79a6c0ae9ff + Author Name: Yonghong Song + Author Email: yhs@fb.com + Commit Date: 1575524082 + Commit Message: + selftests/bpf: Add a fexit/bpf2bpf test with target bpf prog no callees The existing fexit_bpf2bpf test covers the target progrm with callees. This patch added a test for the target program without callees. Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191205010607.177904-1-yhs@fb.com + Changed Files: .../selftests/bpf/prog_tests/fexit_bpf2bpf.c | 70 ++++++++++++++++------; .../selftests/bpf/progs/fexit_bpf2bpf_simple.c | 26 ++++++++; .../selftests/bpf/progs/test_pkt_md_access.c | 4 +-; 3 files changed, 81 insertions(+), 19 deletions(-) + Parent Hashes: e9eeec58c992c47b394e4f829e4f81b923b0a322 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds a new test for an eBPF program without callees in the selftests/bpf suite.", + "keywords": "fexit,bpf2bpf,selftests", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds a selftest for an eBPF program without callees in the fexit_bpf2bpf test suite.", + "keywords": "test,fexit,bpf2bpf", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 938/6895 - Commit ID: e9eeec58c992c47b394e4f829e4f81b923b0a322 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: e9eeec58c992c47b394e4f829e4f81b923b0a322 + Author Name: Yonghong Song + Author Email: yhs@fb.com + Commit Date: 1575523207 + Commit Message: + bpf: Fix a bug when getting subprog 0 jited image in check_attach_btf_id For jited bpf program, if the subprogram count is 1, i.e., there is no callees in the program, prog->aux->func will be NULL and prog->bpf_func points to image address of the program. If there is more than one subprogram, prog->aux->func is populated, and subprogram 0 can be accessed through either prog->bpf_func or prog->aux->func[0]. Other subprograms should be accessed through prog->aux->func[subprog_id]. This patch fixed a bug in check_attach_btf_id(), where prog->aux->func[subprog_id] is used to access any subprogram which caused a segfault like below: [79162.619208] BUG: kernel NULL pointer dereference, address: 0000000000000000 ...... [79162.634255] Call Trace: [79162.634974] ? _cond_resched+0x15/0x30 [79162.635686] ? kmem_cache_alloc_trace+0x162/0x220 [79162.636398] ? selinux_bpf_prog_alloc+0x1f/0x60 [79162.637111] bpf_prog_load+0x3de/0x690 [79162.637809] __do_sys_bpf+0x105/0x1740 [79162.638488] do_syscall_64+0x5b/0x180 [79162.639147] entry_SYSCALL_64_after_hwframe+0x44/0xa9 ...... Fixes: 5b92a28aae4d ("bpf: Support attaching tracing BPF program to other BPF programs") Reported-by: Eelco Chaudron Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191205010606.177774-1-yhs@fb.com + Changed Files: kernel/bpf/verifier.c | 5 ++++-; 1 file changed, 4 insertions(+), 1 deletion(-) + Parent Hashes: ef8c84effce3c7a0b8196fcda8f430c815ab511c +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit fixes a segfault in check_attach_btf_id by addressing incorrect subprogram access in jited BPF programs.", + "keywords": "bug,subprog,segfault", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes a bug causing a segfault in check_attach_btf_id by correcting subprogram access in jited BPF programs.", + "keywords": "bug,segfault,subprogram", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 939/6895 - Commit ID: ef8c84effce3c7a0b8196fcda8f430c815ab511c +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: ef8c84effce3c7a0b8196fcda8f430c815ab511c + Author Name: Stanislav Fomichev + Author Email: sdf@google.com + Commit Date: 1575511265 + Commit Message: + selftests/bpf: De-flake test_tcpbpf It looks like BPF program that handles BPF_SOCK_OPS_STATE_CB state can race with the bpf_map_lookup_elem("global_map"); I sometimes see the failures in this test and re-running helps. Since we know that we expect the callback to be called 3 times (one time for listener socket, two times for both ends of the connection), let's export this number and add simple retry logic around that. Also, let's make EXPECT_EQ() not return on failure, but continue evaluating all conditions; that should make potential debugging easier. With this fix in place I don't observe the flakiness anymore. Signed-off-by: Stanislav Fomichev Signed-off-by: Alexei Starovoitov Cc: Lawrence Brakmo Link: https://lore.kernel.org/bpf/20191204190955.170934-1-sdf@google.com + Changed Files: .../testing/selftests/bpf/progs/test_tcpbpf_kern.c | 1 +; tools/testing/selftests/bpf/test_tcpbpf.h | 1 +; tools/testing/selftests/bpf/test_tcpbpf_user.c | 25 ++++++++++++++++------; 3 files changed, 20 insertions(+), 7 deletions(-) + Parent Hashes: 6bf6affe18dafea6ef12036001162ac7f2dbf738 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit addresses a test flakiness in test_tcpbpf by adding retry logic and improving debugging information.", + "keywords": "test, retry, flakiness", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit addresses test flakiness in test_tcpbpf by adding retry logic and enhancing error handling.", + "keywords": "test, retry, flakiness", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 940/6895 - Commit ID: 6bf6affe18dafea6ef12036001162ac7f2dbf738 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 6bf6affe18dafea6ef12036001162ac7f2dbf738 + Author Name: Stanislav Fomichev + Author Email: sdf@google.com + Commit Date: 1575511075 + Commit Message: + selftests/bpf: Bring back c++ include/link test Commit 5c26f9a78358 ("libbpf: Don't use cxx to test_libpf target") converted existing c++ test to c. We still want to include and link against libbpf from c++ code, so reinstate this test back, this time in a form of a selftest with a clear comment about its purpose. v2: * -lelf -> $(LDLIBS) (Andrii Nakryiko) Fixes: 5c26f9a78358 ("libbpf: Don't use cxx to test_libpf target") Signed-off-by: Stanislav Fomichev Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20191202215931.248178-1-sdf@google.com + Changed Files: tools/lib/bpf/.gitignore | 1 -; tools/lib/bpf/Makefile | 5 +----; tools/lib/bpf/test_libbpf.c | 20 --------------------; tools/testing/selftests/bpf/.gitignore | 1 +; tools/testing/selftests/bpf/Makefile | 6 +++++-; tools/testing/selftests/bpf/test_cpp.cpp | 20 ++++++++++++++++++++; 6 files changed, 27 insertions(+), 26 deletions(-) + Parent Hashes: 01d434ce98d38e36901c72493b96afc4075ee887 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Reinstate and adapt C++ tests for libbpf in selftests framework to ensure compatibility and linkage.", + "keywords": "C++ tests, libbpf, selftests", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Reinstate the C++ include and link test for libbpf in the selftests framework to ensure proper functionality.", + "keywords": "C++ include, link test, libbpf", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 941/6895 - Commit ID: 01d434ce98d38e36901c72493b96afc4075ee887 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 01d434ce98d38e36901c72493b96afc4075ee887 + Author Name: Stanislav Fomichev + Author Email: sdf@google.com + Commit Date: 1575510982 + Commit Message: + selftests/bpf: Don't hard-code root cgroup id Commit 40430452fd5d ("kernfs: use 64bit inos if ino_t is 64bit") changed the way cgroup ids are exposed to the userspace. Instead of assuming fixed root id, let's query it. Fixes: 40430452fd5d ("kernfs: use 64bit inos if ino_t is 64bit") Signed-off-by: Stanislav Fomichev Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191202200143.250793-1-sdf@google.com + Changed Files: tools/testing/selftests/bpf/test_skb_cgroup_id_user.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: edbca120a8cdfa5a5793707e33497aa5185875ca +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit modifies a selftest to dynamically query the root cgroup ID instead of hardcoding it, adapting to changes in kernfs ID handling.", + "keywords": "root cgroup selftests", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups)." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adjusts a selftest to query the dynamic root cgroup ID instead of using a fixed value due to changes in kernfs handling.", + "keywords": "query cgroup selftests", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "cgroup type related programs. It affects programs managing resource limits or network behavior via control groups (cgroups)." + ] +} +-------------------- +-------------------- +Processing Commit 942/6895 - Commit ID: edbca120a8cdfa5a5793707e33497aa5185875ca +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: edbca120a8cdfa5a5793707e33497aa5185875ca + Author Name: Jesper Dangaard Brouer + Author Email: brouer@redhat.com + Commit Date: 1575510855 + Commit Message: + samples/bpf: Fix broken xdp_rxq_info due to map order assumptions In the days of using bpf_load.c the order in which the 'maps' sections were defines in BPF side (*_kern.c) file, were used by userspace side to identify the map via using the map order as an index. In effect the order-index is created based on the order the maps sections are stored in the ELF-object file, by the LLVM compiler. This have also carried over in libbpf via API bpf_map__next(NULL, obj) to extract maps in the order libbpf parsed the ELF-object file. When BTF based maps were introduced a new section type ".maps" were created. I found that the LLVM compiler doesn't create the ".maps" sections in the order they are defined in the C-file. The order in the ELF file is based on the order the map pointer is referenced in the code. This combination of changes lead to xdp_rxq_info mixing up the map file-descriptors in userspace, resulting in very broken behaviour, but without warning the user. This patch fix issue by instead using bpf_object__find_map_by_name() to find maps via their names. (Note, this is the ELF name, which can be longer than the name the kernel retains). Fixes: be5bca44aa6b ("samples: bpf: convert some XDP samples from bpf_load to libbpf") Fixes: 451d1dc886b5 ("samples: bpf: update map definition to new syntax BTF-defined map") Signed-off-by: Jesper Dangaard Brouer Signed-off-by: Alexei Starovoitov Acked-by: Toke Høiland-Jørgensen Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/157529025128.29832.5953245340679936909.stgit@firesoul + Changed Files: samples/bpf/xdp_rxq_info_user.c | 6 +++---; 1 file changed, 3 insertions(+), 3 deletions(-) + Parent Hashes: 099ffd7eddfe03b9b5b43e1f4ffece99121dd7ba +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes map descriptor ordering issue in xdp_rxq_info by using map names instead of order-indexing.", + "keywords": "map ordering, xdp_rxq_info, BTF-defined", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes map descriptor ordering issue in xdp_rxq_info by using map names instead of order-indexing.", + "keywords": "map ordering, xdp_rxq_info, BTF-defined", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 943/6895 - Commit ID: 01d1dff64662646023482806c6db8ef0b280c403 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 01d1dff64662646023482806c6db8ef0b280c403 + Author Name: Linus Torvalds + Author Email: torvalds@linux-foundation.org + Commit Date: 1575406200 + Commit Message: + Merge tag 's390-5.5-2' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull more s390 updates from Vasily Gorbik: - Make stack unwinder reliable and suitable for livepatching. Add unwinder testing module. - Fixes for CALL_ON_STACK helper used for stack switching. - Fix unwinding from bpf code. - Fix getcpu and remove compat support in vdso code. - Fix address space control registers initialization. - Save KASLR offset for early dumps. - Handle new FILTERED_BY_HYPERVISOR reply code in crypto code. - Minor perf code cleanup and potential memory leak fix. - Add couple of error messages for corner cases during PCI device creation. * tag 's390-5.5-2' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: (33 commits) s390: remove compat vdso code s390/livepatch: Implement reliable stack tracing for the consistency model s390/unwind: add stack pointer alignment sanity checks s390/unwind: filter out unreliable bogus %r14 s390/unwind: start unwinding from reliable state s390/test_unwind: add program check context tests s390/test_unwind: add irq context tests s390/test_unwind: print verbose unwinding results s390/test_unwind: add CALL_ON_STACK tests s390: fix register clobbering in CALL_ON_STACK s390/test_unwind: require that unwinding ended successfully s390/unwind: add a test for the internal API s390/unwind: always inline get_stack_pointer s390/pci: add error message on device number limit s390/pci: add error message for UID collision s390/cpum_sf: Check for SDBT and SDB consistency s390/cpum_sf: Use TEAR_REG macro consistantly s390/cpum_sf: Remove unnecessary check for pending SDBs s390/cpum_sf: Replace function name in debug statements s390/kaslr: store KASLR offset for early dumps ... + Changed Files: nan + Parent Hashes: 4d7048f55104434ec64fe0b5196cbc89a8f99548 2115fbf7210bd053ba55a95e7ebc366df41aa9cf +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This is a merge commit incorporating various updates and fixes for the s390 architecture in the Linux kernel.", + "keywords": "s390, updates, merge", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "This is a merge commit incorporating various updates and fixes for the s390 architecture in the Linux kernel.", + "keywords": "s390, updates, merge", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 944/6895 - Commit ID: 734c7022adaa7833aa809b3f2c3fc0cf09b2a48e +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 734c7022adaa7833aa809b3f2c3fc0cf09b2a48e + Author Name: David S. Miller + Author Email: davem@davemloft.net + Commit Date: 1575312629 + Commit Message: + Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf Daniel Borkmann says: ==================== pull-request: bpf 2019-12-02 The following pull-request contains BPF updates for your *net* tree. We've added 10 non-merge commits during the last 6 day(s) which contain a total of 10 files changed, 60 insertions(+), 51 deletions(-). The main changes are: 1) Fix vmlinux BTF generation for binutils pre v2.25, from Stanislav Fomichev. 2) Fix libbpf global variable relocation to take symbol's st_value offset into account, from Andrii Nakryiko. 3) Fix libbpf build on powerpc where check_abi target fails due to different readelf output format, from Aurelien Jarno. 4) Don't set BPF insns RO for the case when they are JITed in order to avoid fragmenting the direct map, from Daniel Borkmann. 5) Fix static checker warning in btf_distill_func_proto() as well as a build error due to empty enum when BPF is compiled out, from Alexei Starovoitov. 6) Fix up generation of bpf_helper_defs.h for perf, from Arnaldo Carvalho de Melo. ==================== Signed-off-by: David S. Miller + Changed Files: nan + Parent Hashes: 596cf45cbf6e4fa7bcb0df33e373a7d062b644b5 3464afdf11f9a1e031e7858a05351ceca1792fea +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This is a merge commit of BPF updates with fixes for various issues like vmlinux BTF generation and libbpf builds.", + "keywords": "merge,BPF,fixes", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "This is a merge commit of BPF updates with fixes for various issues like vmlinux BTF generation and libbpf builds.", + "keywords": "merge,BPF,fixes", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 945/6895 - Commit ID: 3464afdf11f9a1e031e7858a05351ceca1792fea +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 3464afdf11f9a1e031e7858a05351ceca1792fea + Author Name: Aurelien Jarno + Author Email: aurelien@aurel32.net + Commit Date: 1575279114 + Commit Message: + libbpf: Fix readelf output parsing on powerpc with recent binutils On powerpc with recent versions of binutils, readelf outputs an extra field when dumping the symbols of an object file. For example: 35: 0000000000000838 96 FUNC LOCAL DEFAULT [: 8] 1 btf_is_struct The extra "[: 8]" prevents the GLOBAL_SYM_COUNT variable to be computed correctly and causes the check_abi target to fail. Fix that by looking for the symbol name in the last field instead of the 8th one. This way it should also cope with future extra fields. Signed-off-by: Aurelien Jarno Signed-off-by: Daniel Borkmann Tested-by: Michael Ellerman Link: https://lore.kernel.org/bpf/20191201195728.4161537-1-aurelien@aurel32.net + Changed Files: tools/lib/bpf/Makefile | 4 ++--; 1 file changed, 2 insertions(+), 2 deletions(-) + Parent Hashes: e1608f3fa857b600045b6df7f7dadc70eeaa4496 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes readelf output parsing on powerpc with recent binutils by adjusting symbol name field detection.", + "keywords": "libbpf,readelf,powerpc", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes readelf output parsing on powerpc with recent binutils by adjusting symbol name field detection.", + "keywords": "libbpf,readelf,powerpc", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 946/6895 - Commit ID: c3bfc5dd73c6f519ff0636d4e709515f06edef78 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: c3bfc5dd73c6f519ff0636d4e709515f06edef78 + Author Name: Linus Torvalds + Author Email: torvalds@linux-foundation.org + Commit Date: 1575261303 + Commit Message: + Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from David Miller: 1) Fix several scatter gather list issues in kTLS code, from Jakub Kicinski. 2) macb driver device remove has to kill the hresp_err_tasklet. From Chuhong Yuan. 3) Several memory leak and reference count bug fixes in tipc, from Tung Nguyen. 4) Fix mlx5 build error w/o ipv6, from Yue Haibing. 5) Fix jumbo frame and other regressions in r8169, from Heiner Kallweit. 6) Undo some BUG_ON()'s and replace them with WARN_ON_ONCE and proper error propagation/handling. From Paolo Abeni. * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (24 commits) openvswitch: remove another BUG_ON() openvswitch: drop unneeded BUG_ON() in ovs_flow_cmd_build_info() net: phy: realtek: fix using paged operations with RTL8105e / RTL8208 r8169: fix resume on cable plug-in r8169: fix jumbo configuration for RTL8168evl net: emulex: benet: indent a Kconfig depends continuation line selftests: forwarding: fix race between packet receive and tc check net: sched: fix `tc -s class show` no bstats on class with nolock subqueues net: ethernet: ti: ale: ensure vlan/mdb deleted when no members net/mlx5e: Fix build error without IPV6 selftests: pmtu: use -oneline for ip route list cache tipc: fix duplicate SYN messages under link congestion tipc: fix wrong timeout input for tipc_wait_for_cond() tipc: fix wrong socket reference counter after tipc_sk_timeout() returns tipc: fix potential memory leak in __tipc_sendmsg() net: macb: add missed tasklet_kill selftests: bpf: correct perror strings selftests: bpf: test_sockmap: handle file creation failures gracefully net/tls: use sg_next() to walk sg entries net/tls: remove the dead inplace_crypto code ... + Changed Files: nan + Parent Hashes: e5b3fc125d768eacd73bb4dc5019f0ce95635af4 c5d728113532c695c894c2a88a10453ac83b0f3b +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges networking fixes from various contributors, including memory leaks and build errors.", + "keywords": "networking,fixes,merge", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges multiple networking fixes from the netdev branch into the main branch.", + "keywords": "networking,merge,fixes", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 947/6895 - Commit ID: b7fcf31f7036895ca8fc3a30eefffab0e82f75f6 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: b7fcf31f7036895ca8fc3a30eefffab0e82f75f6 + Author Name: Linus Torvalds + Author Email: torvalds@linux-foundation.org + Commit Date: 1575254997 + Commit Message: + Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf fixes from Ingo Molnar: - Make /sys/devices/cpu/rdpmc based RDPMC enforcement more instantaneous - decoder: Update the Intel opcode map - Various tooling fixes, including a few late optimizations and cleanups. * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (23 commits) perf script: Fix invalid LBR/binary mismatch error perf script: Fix brstackinsn for AUXTRACE perf affinity: Add infrastructure to save/restore affinity perf pmu: Use file system cache to optimize sysfs access perf regs: Make perf_reg_name() return "unknown" instead of NULL perf diff: Use llabs() with 64-bit values perf diff: Use llabs() with 64-bit values perf/x86: Implement immediate enforcement of /sys/devices/cpu/rdpmc value of 0 perf tools: Allow to link with libbpf dynamicaly perf tests: Rename tests/map_groups.c to tests/maps.c perf tests: Rename thread-mg-share to thread-maps-share perf maps: Rename map_groups.h to maps.h perf maps: Rename 'mg' variables to 'maps' perf map_symbol: Rename ms->mg to ms->maps perf addr_location: Rename al->mg to al->maps perf thread: Rename thread->mg to thread->maps perf maps: Merge 'struct maps' with 'struct map_groups' x86/insn: perf tools: Add some more instructions to the new instructions test x86/insn: Add some more Intel instructions to the opcode map perf map: Remove unused functions ... + Changed Files: nan + Parent Hashes: 72c0870e3a05d9cd5466d08c3d2a3069ed0a2f9f e680a41fcaf07ccac8817c589fc4824988b48eac +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges perf fixes, updates, and optimizations from Ingo Molnar's branch to the mainline kernel.", + "keywords": "merge,perf,fixes", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges perf fixes, updates, and optimizations from Ingo Molnar's branch to the mainline kernel.", + "keywords": "merge,perf,fixes", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 948/6895 - Commit ID: e1608f3fa857b600045b6df7f7dadc70eeaa4496 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: e1608f3fa857b600045b6df7f7dadc70eeaa4496 + Author Name: Daniel Borkmann + Author Email: daniel@iogearbox.net + Commit Date: 1575221643 + Commit Message: + bpf: Avoid setting bpf insns pages read-only when prog is jited For the case where the interpreter is compiled out or when the prog is jited it is completely unnecessary to set the BPF insn pages as read-only. In fact, on frequent churn of BPF programs, it could lead to performance degradation of the system over time since it would break the direct map down to 4k pages when calling set_memory_ro() for the insn buffer on x86-64 / arm64 and there is no reverse operation. Thus, avoid breaking up large pages for data maps, and only limit this to the module range used by the JIT where it is necessary to set the image read-only and executable. Suggested-by: Peter Zijlstra Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191129222911.3710-1-daniel@iogearbox.net + Changed Files: include/linux/filter.h | 8 ++++++--; 1 file changed, 6 insertions(+), 2 deletions(-) + Parent Hashes: df786c9b947639aedbc7bb44b5dae2a7824af360 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit optimizes BPF program JIT compilation by preventing unnecessary memory protection changes that could degrade performance.", + "keywords": "JIT,performance,memory", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit optimizes system performance by avoiding unnecessary read-only memory settings for BPF instruction pages when the program is JIT compiled.", + "keywords": "JIT,performance,memory", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 949/6895 - Commit ID: 914d52e46490b6599b7f03fad233f4f19bf23cf7 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 914d52e46490b6599b7f03fad233f4f19bf23cf7 + Author Name: Ilya Leoshkevich + Author Email: iii@linux.ibm.com + Commit Date: 1575107564 + Commit Message: + s390: implement perf_arch_fetch_caller_regs On s390 bpf_get_stack_raw_tp() returns 0 entries for both kernel and user stacks. While there is no practical unwinding solution for userspace on s390 at this moment, there certainly is a kernel unwinder. However, it is not properly integrated with BPF. In order to start unwinding, bpf_get_stack_raw_tp() obtains the current kernel register values using perf_fetch_caller_regs(), which is not implemented for s390. The actual unwinding then happens by passing those registers to perf_callchain_kernel(). Implement perf_arch_fetch_caller_regs() for s390, where __builtin_frame_address(0) points to back_chain. Signed-off-by: Ilya Leoshkevich Acked-by: Heiko Carstens Signed-off-by: Vasily Gorbik + Changed Files: arch/s390/include/asm/perf_event.h | 7 +++++++; 1 file changed, 7 insertions(+) + Parent Hashes: ea1f56fa16ae5f6e67f6ea03836b36c6053d33d1 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Implement perf_arch_fetch_caller_regs for s390 to enable kernel stack unwinding in bpf_get_stack_raw_tp.", + "keywords": "s390 perf_arch_fetch_caller_regs bpf", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.", + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "Profile related type programs. It affects programs used for profiling system or application performance." + ] +} +Rethinking... +new content: +{ + "summary": "Implement perf_arch_fetch_caller_regs for s390 to integrate kernel unwinding with BPF.", + "keywords": "s390 kernel unwinding", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.", + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "Profile related type programs. It affects programs used for profiling system or application performance." + ] +} +-------------------- +-------------------- +Processing Commit 950/6895 - Commit ID: df786c9b947639aedbc7bb44b5dae2a7824af360 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: df786c9b947639aedbc7bb44b5dae2a7824af360 + Author Name: Stanislav Fomichev + Author Email: sdf@google.com + Commit Date: 1575019137 + Commit Message: + bpf: Force .BTF section start to zero when dumping from vmlinux While trying to figure out why fentry_fexit selftest doesn't pass for me (old pahole, broken BTF), I found out that my latest patch can break vmlinux .BTF generation. objcopy preserves section start when doing --only-section, so there is a chance (depending on where pahole inserts .BTF section) to have leading empty zeroes. Let's explicitly force section offset to zero. Before: $ objcopy --set-section-flags .BTF=alloc -O binary \ --only-section=.BTF vmlinux .btf.vmlinux.bin $ xxd .btf.vmlinux.bin | head -n1 00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................ After: $ objcopy --change-section-address .BTF=0 \ --set-section-flags .BTF=alloc -O binary \ --only-section=.BTF vmlinux .btf.vmlinux.bin $ xxd .btf.vmlinux.bin | head -n1 00000000: 9feb 0100 1800 0000 0000 0000 80e1 1c00 ................ ^BTF magic As part of this change, I'm also dropping '2>/dev/null' from objcopy invocation to be able to catch possible other issues (objcopy doesn't produce any warnings for me anymore, it did before with --dump-section). Fixes: da5fb18225b4 ("bpf: Support pre-2.25-binutils objcopy for vmlinux BTF") Signed-off-by: Stanislav Fomichev Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Cc: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20191127225759.39923-1-sdf@google.com + Changed Files: scripts/link-vmlinux.sh | 5 +++--; 1 file changed, 3 insertions(+), 2 deletions(-) + Parent Hashes: ce27709b8162e5c501bc54292b8bf6bdecc4bbd4 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes BTF section offset in vmlinux to prevent leading zeros in objcopy operations.", + "keywords": "BTF, objcopy, offset", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes the BTF section offset in vmlinux to prevent leading zeros in objcopy operations.", + "keywords": "BTF,objcopy,offset", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 951/6895 - Commit ID: 2eaa857534b4860dc337496e35f72f50614383b3 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 2eaa857534b4860dc337496e35f72f50614383b3 + Author Name: David S. Miller + Author Email: davem@davemloft.net + Commit Date: 1575009630 + Commit Message: + Merge branch 'net-tls-fix-scatter-gather-list-issues' Jakub Kicinski says: ==================== net: tls: fix scatter-gather list issues This series kicked of by a syzbot report fixes three issues around scatter gather handling in the TLS code. First patch fixes a use- -after-free situation which may occur if record was freed on error. This could have already happened in BPF paths, and patch 2 now makes the same condition occur in non-BPF code. Patch 2 fixes the problem spotted by syzbot. If encryption failed we have to clean the end markings from scatter gather list. As suggested by John the patch frees the record entirely and caller may retry copying data from user space buffer again. Third patch fixes a bug in the TLS 1.3 code spotted while working on patch 2. TLS 1.3 may effectively overflow the SG list which leads to the BUG() in sg_page() being triggered. Patch 4 adds a test case which triggers this bug reliably. Next two patches are small cleanups of dead code and code which makes dangerous assumptions. Last but not least two minor improvements to the sockmap tests. Tested: - bpf/test_sockmap - net/tls - syzbot repro (which used error injection, hence no direct selftest is added to preserve it). ==================== Signed-off-by: David S. Miller + Changed Files: nan + Parent Hashes: 81b6b96475ac7a4ebfceae9f16fb3758327adbfe e5dc9dd3258098bf8b5ceb75fc3433b41eff618a +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes multiple issues in the TLS code related to scatter-gather list handling, improving stability and adding tests.", + "keywords": "TLS,scatter-gather,fixes", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +Rethinking... +new content: +{ + "summary": "The commit merges fixes for TLS issues in scatter-gather lists, affecting both BPF and non-BPF paths for stability improvements.", + "keywords": "TLS,scatter-gather,fixes", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +-------------------- +-------------------- +Processing Commit 952/6895 - Commit ID: e5dc9dd3258098bf8b5ceb75fc3433b41eff618a +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: e5dc9dd3258098bf8b5ceb75fc3433b41eff618a + Author Name: Jakub Kicinski + Author Email: jakub.kicinski@netronome.com + Commit Date: 1575009630 + Commit Message: + selftests: bpf: correct perror strings perror(str) is basically equivalent to print("%s: %s\n", str, strerror(errno)). New line or colon at the end of str is a mistake/breaks formatting. Signed-off-by: Jakub Kicinski Reviewed-by: Simon Horman Signed-off-by: David S. Miller + Changed Files: tools/testing/selftests/bpf/test_sockmap.c | 38 +++++++++++++++---------------; tools/testing/selftests/bpf/xdping.c | 2 +-; 2 files changed, 20 insertions(+), 20 deletions(-) + Parent Hashes: 4b67c515036313f3c3ecba3cb2babb9cbddb3f85 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Correct formatting of perror strings in selftest files for BPF.", + "keywords": "perror, formatting, selftests", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Correct formatting of perror strings in BPF selftest files.", + "keywords": "perror, formatting, selftests", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 953/6895 - Commit ID: 4b67c515036313f3c3ecba3cb2babb9cbddb3f85 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 4b67c515036313f3c3ecba3cb2babb9cbddb3f85 + Author Name: Jakub Kicinski + Author Email: jakub.kicinski@netronome.com + Commit Date: 1575009629 + Commit Message: + selftests: bpf: test_sockmap: handle file creation failures gracefully test_sockmap creates a temporary file to use for sendpage. this may fail for various reasons. Handle the error rather than segfault. Signed-off-by: Jakub Kicinski Reviewed-by: Simon Horman Signed-off-by: David S. Miller + Changed Files: tools/testing/selftests/bpf/test_sockmap.c | 9 +++++++++; 1 file changed, 9 insertions(+) + Parent Hashes: c5daa6cccdc2f94aca2c9b3fa5f94e4469997293 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit enhances test_sockmap to handle file creation errors gracefully to prevent segfaults.", + "keywords": "selftests,file,segfault", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "The commit enhances test_sockmap to handle file creation errors gracefully to prevent segfaults.", + "keywords": "selftests,file,segfault", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 954/6895 - Commit ID: 9e5ffed37df68d0ccfb2fdc528609e23a1e70ebe +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 9e5ffed37df68d0ccfb2fdc528609e23a1e70ebe + Author Name: Jakub Kicinski + Author Email: jakub.kicinski@netronome.com + Commit Date: 1575009629 + Commit Message: + net/tls: remove the dead inplace_crypto code Looks like when BPF support was added by commit d3b18ad31f93 ("tls: add bpf support to sk_msg handling") and commit d829e9c4112b ("tls: convert to generic sk_msg interface") it broke/removed the support for in-place crypto as added by commit 4e6d47206c32 ("tls: Add support for inplace records encryption"). The inplace_crypto member of struct tls_rec is dead, inited to zero, and sometimes set to zero again. It used to be set to 1 when record was allocated, but the skmsg code doesn't seem to have been written with the idea of in-place crypto in mind. Since non trivial effort is required to bring the feature back and we don't really have the HW to measure the benefit just remove the left over support for now to avoid confusing readers. Signed-off-by: Jakub Kicinski Reviewed-by: Simon Horman Signed-off-by: David S. Miller + Changed Files: include/net/tls.h | 1 -; net/tls/tls_sw.c | 6 +-----; 2 files changed, 1 insertion(+), 6 deletions(-) + Parent Hashes: 65190f77424d7b82c4aad7326c9cce6bd91a2fcc +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit removes obsolete in-place crypto support for TLS in sk_msg handling after eBPF additions.", + "keywords": "inplace_crypto,TLS,BPF", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here." + ] +} +Rethinking... +new content: +{ + "summary": "The commit removes obsolete in-place crypto code in TLS affected by past BPF sk_msg handling changes.", + "keywords": "TLS,inplace_crypto,sk_msg", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here." + ] +} +-------------------- +-------------------- +Processing Commit 955/6895 - Commit ID: d10523d0b3d78153ee58d19853ced26c9004c8c4 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: d10523d0b3d78153ee58d19853ced26c9004c8c4 + Author Name: Jakub Kicinski + Author Email: jakub.kicinski@netronome.com + Commit Date: 1575009629 + Commit Message: + net/tls: free the record on encryption error When tls_do_encryption() fails the SG lists are left with the SG_END and SG_CHAIN marks in place. One could hope that once encryption fails we will never see the record again, but that is in fact not true. Commit d3b18ad31f93 ("tls: add bpf support to sk_msg handling") added special handling to ENOMEM and ENOSPC errors which mean we may see the same record re-submitted. As suggested by John free the record, the BPF code is already doing just that. Reported-by: syzbot+df0d4ec12332661dd1f9@syzkaller.appspotmail.com Fixes: d3b18ad31f93 ("tls: add bpf support to sk_msg handling") Signed-off-by: Jakub Kicinski Reviewed-by: Simon Horman Acked-by: John Fastabend Signed-off-by: David S. Miller + Changed Files: net/tls/tls_sw.c | 10 ++++++++--; 1 file changed, 8 insertions(+), 2 deletions(-) + Parent Hashes: c329ef9684de9517d82af5b4758c9e1b64a8a11a +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes a bug in net/tls by freeing the record on encryption error to prevent re-submission issues.", + "keywords": "tls, encryption, error", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "I'm not sure about the implementation component of the commit. The component affected by It is unclear.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes a bug in net/tls by freeing the record on encryption error to prevent re-submission issues.", + "keywords": "tls, encryption, error", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +-------------------- +-------------------- +Processing Commit 956/6895 - Commit ID: c329ef9684de9517d82af5b4758c9e1b64a8a11a +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: c329ef9684de9517d82af5b4758c9e1b64a8a11a + Author Name: Jakub Kicinski + Author Email: jakub.kicinski@netronome.com + Commit Date: 1575009629 + Commit Message: + net/tls: take into account that bpf_exec_tx_verdict() may free the record bpf_exec_tx_verdict() may free the record if tls_push_record() fails, or if the entire record got consumed by BPF. Re-check ctx->open_rec before touching the data. Fixes: d3b18ad31f93 ("tls: add bpf support to sk_msg handling") Signed-off-by: Jakub Kicinski Reviewed-by: Simon Horman Acked-by: John Fastabend Signed-off-by: David S. Miller + Changed Files: net/tls/tls_sw.c | 13 ++++++++-----; 1 file changed, 8 insertions(+), 5 deletions(-) + Parent Hashes: 81b6b96475ac7a4ebfceae9f16fb3758327adbfe +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes bpf_exec_tx_verdict() to account for possible record freeing in net/tls implementation.", + "keywords": "bpf,tx_verdict,record", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes a bug in bpf_exec_tx_verdict() within the net/tls subsystem that frees records incorrectly.", + "keywords": "bpf,tx_verdict,net/tls", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "I'm not sure about the use cases or events of the commit. The relationship between It and specific use cases or events is unclear." + ] +} +-------------------- +-------------------- +Processing Commit 957/6895 - Commit ID: e680a41fcaf07ccac8817c589fc4824988b48eac +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: e680a41fcaf07ccac8817c589fc4824988b48eac + Author Name: Ingo Molnar + Author Email: mingo@kernel.org + Commit Date: 1575006965 + Commit Message: + Merge tag 'perf-core-for-mingo-5.5-20191128' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent Pull perf/core improvements and fixes from Arnaldo Carvalho de Melo: perf script: Adrian Hunter: - Fix brstackinsn for AUXTRACE. - Fix invalid LBR/binary mismatch error. perf diff: Arnaldo Carvalho de Melo: - Use llabs() with 64-bit values, fixing the build in some 32-bit architectures. perf pmu: Andi Kleen: - Use file system cache to optimize sysfs access. x86: Adrian Hunter: - Add some more Intel instructions to the opcode map and to the perf test entry: gf2p8affineinvqb, gf2p8affineqb, gf2p8mulb, v4fmaddps, v4fmaddss, v4fnmaddps, v4fnmaddss, vaesdec, vaesdeclast, vaesenc, vaesenclast, vcvtne2ps2bf16, vcvtneps2bf16, vdpbf16ps, vgf2p8affineinvqb, vgf2p8affineqb, vgf2p8mulb, vp2intersectd, vp2intersectq, vp4dpwssd, vp4dpwssds, vpclmulqdq, vpcompressb, vpcompressw, vpdpbusd, vpdpbusds, vpdpwssd, vpdpwssds, vpexpandb, vpexpandw, vpopcntb, vpopcntd, vpopcntq, vpopcntw, vpshldd, vpshldq, vpshldvd, vpshldvq, vpshldvw, vpshldw, vpshrdd, vpshrdq, vpshrdvd, vpshrdvq, vpshrdvw, vpshrdw, vpshufbitqmb. perf affinity: Andi Kleen: - Add infrastructure to save/restore affinity perf maps: Arnaldo Carvalho de Melo: - Merge 'struct maps' with 'struct map_groups', as there is a 1x1 relationship, simplifying code overal. perf build: Jiri Olsa: - Allow to link with libbpf dynamicaly. Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Ingo Molnar + Changed Files: nan + Parent Hashes: 405b45376de90b3027aaf8c4de035c6bb721fa7e 5172672da02e483d9b3c4d814c3482d0c8ffb1a6 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit merges various performance-related improvements and fixes from the perf/core branch into the current branch.", + "keywords": "Merge,perf,fixed", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "The commit merges performance-related improvements and fixes from the perf/core branch into perf/urgent.", + "keywords": "perf,improvements,fixes", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 958/6895 - Commit ID: ce27709b8162e5c501bc54292b8bf6bdecc4bbd4 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: ce27709b8162e5c501bc54292b8bf6bdecc4bbd4 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1574985822 + Commit Message: + bpf: Fix build in minimal configurations Some kconfigs can have BPF enabled without a single valid program type. In such configurations the build will fail with: ./kernel/bpf/btf.c:3466:1: error: empty enum is invalid Fix it by adding unused value to the enum. Reported-by: Randy Dunlap Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: Randy Dunlap # build-tested Link: https://lore.kernel.org/bpf/20191128043508.2346723-1-ast@kernel.org + Changed Files: kernel/bpf/btf.c | 1 +; 1 file changed, 1 insertion(+) + Parent Hashes: 7c3977d1e80401b1a25efded698b05d60ee26e31 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes build issues in minimal configurations by adding an unused value to an enum.", + "keywords": "build, enum, configuration", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes build issues in minimal configurations by adding an unused value to an enum in the BPF subsystem.", + "keywords": "build, enum, BPF", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 959/6895 - Commit ID: 7c3977d1e80401b1a25efded698b05d60ee26e31 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 7c3977d1e80401b1a25efded698b05d60ee26e31 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1574905616 + Commit Message: + libbpf: Fix sym->st_value print on 32-bit arches The st_value field is a 64-bit value and causing this error on 32-bit arches: In file included from libbpf.c:52: libbpf.c: In function 'bpf_program__record_reloc': libbpf_internal.h:59:22: error: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'Elf64_Addr' {aka 'const long long unsigned int'} [-Werror=format=] Fix it with (__u64) cast. Fixes: 1f8e2bcb2cd5 ("libbpf: Refactor relocation handling") Reported-by: Arnaldo Carvalho de Melo Signed-off-by: Alexei Starovoitov + Changed Files: tools/lib/bpf/libbpf.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: 1fd450f99272791df8ea8e1b0f5657678e118e90 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fix formatting error for the st_value field in libbpf on 32-bit architectures by casting to __u64.", + "keywords": "libbpf, 32-bit, fix", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Fix formatting error for the st_value field in libbpf on 32-bit architectures by casting to __u64.", + "keywords": "libbpf, 32-bit, fix", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 960/6895 - Commit ID: 1fd450f99272791df8ea8e1b0f5657678e118e90 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 1fd450f99272791df8ea8e1b0f5657678e118e90 + Author Name: Arnaldo Carvalho de Melo + Author Email: arnaldo.melo@gmail.com + Commit Date: 1574902351 + Commit Message: + libbpf: Fix up generation of bpf_helper_defs.h $ make -C tools/perf build-test does, ends up with these two problems: make[3]: *** No rule to make target '/tmp/tmp.zq13cHILGB/perf-5.3.0/include/uapi/linux/bpf.h', needed by 'bpf_helper_defs.h'. Stop. make[3]: *** Waiting for unfinished jobs.... make[2]: *** [Makefile.perf:757: /tmp/tmp.zq13cHILGB/perf-5.3.0/tools/lib/bpf/libbpf.a] Error 2 make[2]: *** Waiting for unfinished jobs.... Because $(srcdir) points to the /tmp/tmp.zq13cHILGB/perf-5.3.0 directory and we need '/tools/ after that variable, and after fixing this then we get to another problem: /bin/sh: /home/acme/git/perf/tools/scripts/bpf_helpers_doc.py: No such file or directory make[3]: *** [Makefile:184: bpf_helper_defs.h] Error 127 make[3]: *** Deleting file 'bpf_helper_defs.h' LD /tmp/build/perf/libapi-in.o make[2]: *** [Makefile.perf:778: /tmp/build/perf/libbpf.a] Error 2 make[2]: *** Waiting for unfinished jobs.... Because this requires something outside the tools/ directories that gets collected into perf's detached tarballs, to fix it just add it to tools/perf/MANIFEST, which this patch does, now it works for that case and also for all these other cases. Fixes: e01a75c15969 ("libbpf: Move bpf_{helpers, helper_defs, endian, tracing}.h into libbpf") Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Alexei Starovoitov Cc: Adrian Hunter Cc: Alexei Starovoitov Cc: Andrii Nakryiko Cc: Daniel Borkmann Cc: Jiri Olsa Cc: Martin KaFai Lau Cc: Namhyung Kim Link: https://lkml.kernel.org/n/tip-4pnkg2vmdvq5u6eivc887wen@git.kernel.org Link: https://lore.kernel.org/bpf/20191126151045.GB19483@kernel.org + Changed Files: tools/lib/bpf/Makefile | 4 ++--; tools/perf/MANIFEST | 1 +; 2 files changed, 3 insertions(+), 2 deletions(-) + Parent Hashes: 53f8dd434b6fe666b1c4e0be80a8727e8fa9839f +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes issues in generating bpf_helper_defs.h by updating the Makefile and the MANIFEST for correct tool builds.", + "keywords": "libbpf,Makefile,MANSIFEST", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit resolves build issues for bpf_helper_defs.h by updating the libbpf Makefile and tools/perf MANIFEST.", + "keywords": "libbpf,Makefile,MANIFEST", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 961/6895 - Commit ID: 53f8dd434b6fe666b1c4e0be80a8727e8fa9839f +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 53f8dd434b6fe666b1c4e0be80a8727e8fa9839f + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1574901261 + Commit Message: + libbpf: Fix global variable relocation Similarly to a0d7da26ce86 ("libbpf: Fix call relocation offset calculation bug"), relocations against global variables need to take into account referenced symbol's st_value, which holds offset into a corresponding data section (and, subsequently, offset into internal backing map). For static variables this offset is always zero and data offset is completely described by respective instruction's imm field. Convert a bunch of selftests to global variables. Previously they were relying on `static volatile` trick to ensure Clang doesn't inline static variables, which with global variables is not necessary anymore. Fixes: 393cdfbee809 ("libbpf: Support initialized global variables") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20191127200651.1381348-1-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.c | 43 ++++++++++-------------; tools/testing/selftests/bpf/progs/fentry_test.c | 12 +++----; tools/testing/selftests/bpf/progs/fexit_bpf2bpf.c | 6 ++--; tools/testing/selftests/bpf/progs/fexit_test.c | 12 +++----; tools/testing/selftests/bpf/progs/test_mmap.c | 4 +--; 5 files changed, 36 insertions(+), 41 deletions(-) + Parent Hashes: b568405856906ee4d9ba6284fd36f2928653a623 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit fixes global variable relocation in libbpf and updates selftests accordingly.", + "keywords": "libbpf,relocation,variables", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit fixes global variable relocation in libbpf and updates selftests accordingly.", + "keywords": "libbpf,relocation,variables", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 962/6895 - Commit ID: b568405856906ee4d9ba6284fd36f2928653a623 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: b568405856906ee4d9ba6284fd36f2928653a623 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1574890142 + Commit Message: + libbpf: Fix Makefile' libbpf symbol mismatch diagnostic Fix Makefile's diagnostic diff output when there is LIBBPF_API-versioned symbols mismatch. Fixes: 1bd63524593b ("libbpf: handle symbol versioning properly for libbpf.a") Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20191127200134.1360660-1-andriin@fb.com + Changed Files: tools/lib/bpf/Makefile | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: da5fb18225b49b97bb37c51bcbbb2990a507c364 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes diagnostic output in Makefile for libbpf symbol version mismatches.", + "keywords": "libbpf,Makefile,symbol", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes diagnostic output in Makefile for libbpf symbol version mismatches.", + "keywords": "libbpf,Makefile,diagnostic", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 963/6895 - Commit ID: da5fb18225b49b97bb37c51bcbbb2990a507c364 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: da5fb18225b49b97bb37c51bcbbb2990a507c364 + Author Name: Stanislav Fomichev + Author Email: sdf@google.com + Commit Date: 1574881902 + Commit Message: + bpf: Support pre-2.25-binutils objcopy for vmlinux BTF If vmlinux BTF generation fails, but CONFIG_DEBUG_INFO_BTF is set, .BTF section of vmlinux is empty and kernel will prohibit BPF loading and return "in-kernel BTF is malformed". --dump-section argument to binutils' objcopy was added in version 2.25. When using pre-2.25 binutils, BTF generation silently fails. Convert to --only-section which is present on pre-2.25 binutils. Documentation/process/changes.rst states that binutils 2.21+ is supported, not sure those standards apply to BPF subsystem. v2: * exit and print an error if gen_btf fails (John Fastabend) v3: * resend with Andrii's Acked-by/Tested-by tags Fixes: 341dfcf8d78ea ("btf: expose BTF info through sysfs") Signed-off-by: Stanislav Fomichev Signed-off-by: Alexei Starovoitov Tested-by: Andrii Nakryiko Acked-by: Andrii Nakryiko Cc: John Fastabend Link: https://lore.kernel.org/bpf/20191127161410.57327-1-sdf@google.com + Changed Files: scripts/link-vmlinux.sh | 7 ++++++-; 1 file changed, 6 insertions(+), 1 deletion(-) + Parent Hashes: d0f010434124598988ba1c97fbb0e4e820ff5d8c +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds support for generating vmlinux BTF for older binutils versions by switching from --dump-section to --only-section.", + "keywords": "BTF,objcopy,binutils", + "commit_classification": "A documentation change or typo fix. It only involves changes to documentation files or fixes a typographical error.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adjusts vmlinux BTF generation for compatibility with older binutils by switching to --only-section.", + "keywords": "BTF,objcopy,binutils", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 964/6895 - Commit ID: d0f010434124598988ba1c97fbb0e4e820ff5d8c +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: d0f010434124598988ba1c97fbb0e4e820ff5d8c + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1574813087 + Commit Message: + bpf: Fix static checker warning kernel/bpf/btf.c:4023 btf_distill_func_proto() error: potentially dereferencing uninitialized 't'. kernel/bpf/btf.c 4012 nargs = btf_type_vlen(func); 4013 if (nargs >= MAX_BPF_FUNC_ARGS) { 4014 bpf_log(log, 4015 "The function %s has %d arguments. Too many.\n", 4016 tname, nargs); 4017 return -EINVAL; 4018 } 4019 ret = __get_type_size(btf, func->type, &t); ^^ t isn't initialized for the first -EINVAL return This is unlikely path, since BTF should have been validated at this point. Fix it by returning 'void' BTF. Reported-by: Dan Carpenter Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191126230106.237179-1-ast@kernel.org + Changed Files: kernel/bpf/btf.c | 4 +++-; 1 file changed, 3 insertions(+), 1 deletion(-) + Parent Hashes: a95069ecb7092d03b2ea1c39ee04514fe9627540 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fix a static checker warning by ensuring 't' is initialized in the btf_distill_func_proto function.", + "keywords": "static,checker,warning", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Fix a static checker warning by initializing 't' in the btf_distill_func_proto function in bpf subsystem.", + "keywords": "static,checker,warning", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "BPF Type Format (BTF) Logic. E.g. It affects BTF which is used for CO-RE (Compile Once Run Everywhere) capabilities or changes how BPF programs interact with the verifier using BTF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 965/6895 - Commit ID: 1ae78780eda54023a0fb49ee743dbba39da148e0 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 1ae78780eda54023a0fb49ee743dbba39da148e0 + Author Name: Linus Torvalds + Author Email: torvalds@linux-foundation.org + Commit Date: 1574811763 + Commit Message: + Merge branch 'core-rcu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull RCU updates from Ingo Molnar: "The main changes in this cycle were: - Dynamic tick (nohz) updates, perhaps most notably changes to force the tick on when needed due to lengthy in-kernel execution on CPUs on which RCU is waiting. - Linux-kernel memory consistency model updates. - Replace rcu_swap_protected() with rcu_prepace_pointer(). - Torture-test updates. - Documentation updates. - Miscellaneous fixes" * 'core-rcu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (51 commits) security/safesetid: Replace rcu_swap_protected() with rcu_replace_pointer() net/sched: Replace rcu_swap_protected() with rcu_replace_pointer() net/netfilter: Replace rcu_swap_protected() with rcu_replace_pointer() net/core: Replace rcu_swap_protected() with rcu_replace_pointer() bpf/cgroup: Replace rcu_swap_protected() with rcu_replace_pointer() fs/afs: Replace rcu_swap_protected() with rcu_replace_pointer() drivers/scsi: Replace rcu_swap_protected() with rcu_replace_pointer() drm/i915: Replace rcu_swap_protected() with rcu_replace_pointer() x86/kvm/pmu: Replace rcu_swap_protected() with rcu_replace_pointer() rcu: Upgrade rcu_swap_protected() to rcu_replace_pointer() rcu: Suppress levelspread uninitialized messages rcu: Fix uninitialized variable in nocb_gp_wait() rcu: Update descriptions for rcu_future_grace_period tracepoint rcu: Update descriptions for rcu_nocb_wake tracepoint rcu: Remove obsolete descriptions for rcu_barrier tracepoint rcu: Ensure that ->rcu_urgent_qs is set before resched IPI workqueue: Convert for_each_wq to use built-in list check rcu: Several rcu_segcblist functions can be static rcu: Remove unused function hlist_bl_del_init_rcu() Documentation: Rename rcu_node_context_switch() to rcu_note_context_switch() ... + Changed Files: nan + Parent Hashes: 77a05940eee7e9891cd6add7a690a3e762ee21b0 43e0ae7ae0f567a3f8c10ec7a4078bc482660921 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges RCU updates to address dynamic tick handling and replace rcu_swap_protected with rcu_replace_pointer across multiple components.", + "keywords": "RCU, merge, updates", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges RCU updates addressing dynamic tick handling and replacing rcu_swap_protected with rcu_replace_pointer in multiple components.", + "keywords": "RCU, merge, pointer", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 966/6895 - Commit ID: 7b65e2034fde011d090d4ec472902b71129c6cbd +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 7b65e2034fde011d090d4ec472902b71129c6cbd + Author Name: Jiri Olsa + Author Email: jolsa@kernel.org + Commit Date: 1574777865 + Commit Message: + perf tools: Allow to link with libbpf dynamicaly Currently we support only static linking with kernel's libbpf (tools/lib/bpf). This patch adds libbpf package detection and support to link perf with it dynamically. The libbpf package status is displayed with: $ make VF=1 Auto-detecting system features: ... ... libbpf: [ on ] It's not checked by default, because it's quite new. Once it's on most distros we can switch it on. For the same reason it's not added to the test-all check. Perf does not need advanced version of libbpf, so we can check just for the base bpf_object__open function. Adding new compile variable to detect libbpf package and link bpf dynamically: $ make LIBBPF_DYNAMIC=1 ... LINK perf $ ldd perf | grep bpf libbpf.so.0 => /lib64/libbpf.so.0 (0x00007f46818bc000) If libbpf is not installed, build stops with: Makefile.config:486: *** Error: No libbpf devel library found,\ please install libbpf-devel. Stop. Committer testing: $ make LIBBPF_DYNAMIC=1 -C tools/perf O=/tmp/build/perf make: Entering directory '/home/acme/git/perf/tools/perf' BUILD: Doing 'make -j8' parallel build Makefile.config:493: *** Error: No libbpf devel library found, please install libbpf-devel. Stop. make[1]: *** [Makefile.perf:225: sub-make] Error 2 make: *** [Makefile:70: all] Error 2 make: Leaving directory '/home/acme/git/perf/tools/perf' $ Signed-off-by: Jiri Olsa Tested-by: Arnaldo Carvalho de Melo Cc: Toke Høiland-Jørgensen Cc: Alexander Shishkin Cc: Alexei Starovoitov Cc: Andrii Nakryiko Cc: Daniel Borkmann Cc: Jesper Dangaard Brouer Cc: Martin KaFai Lau Cc: Michael Petlan Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Song Liu Cc: Yonghong Song Cc: bpf@vger.kernel.org Cc: netdev@vger.kernel.org Link: http://lore.kernel.org/lkml/20191126121253.28253-1-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo + Changed Files: tools/build/Makefile.feature | 3 ++-; tools/build/feature/Makefile | 4 ++++; tools/build/feature/test-libbpf.c | 7 +++++++; tools/perf/Makefile.config | 10 ++++++++++; tools/perf/Makefile.perf | 6 +++++-; 5 files changed, 28 insertions(+), 2 deletions(-) + Parent Hashes: a5732681e0e6ea0c3024f9d23bcf99b9237189ee +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit enables dynamic linking with libbpf in perf tools, allowing detection and usage of libbpf package during build.", + "keywords": "dynamic, libbpf, linking", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit enables dynamic linking with libbpf in perf tools by adding package detection and support for it during build.", + "keywords": "dynamic, libbpf, linking", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 967/6895 - Commit ID: 386403a115f95997c2715691226e11a7b5cffcfd +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 386403a115f95997c2715691226e11a7b5cffcfd + Author Name: Linus Torvalds + Author Email: torvalds@linux-foundation.org + Commit Date: 1574740977 + Commit Message: + Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next Pull networking updates from David Miller: "Another merge window, another pull full of stuff: 1) Support alternative names for network devices, from Jiri Pirko. 2) Introduce per-netns netdev notifiers, also from Jiri Pirko. 3) Support MSG_PEEK in vsock/virtio, from Matias Ezequiel Vara Larsen. 4) Allow compiling out the TLS TOE code, from Jakub Kicinski. 5) Add several new tracepoints to the kTLS code, also from Jakub. 6) Support set channels ethtool callback in ena driver, from Sameeh Jubran. 7) New SCTP events SCTP_ADDR_ADDED, SCTP_ADDR_REMOVED, SCTP_ADDR_MADE_PRIM, and SCTP_SEND_FAILED_EVENT. From Xin Long. 8) Add XDP support to mvneta driver, from Lorenzo Bianconi. 9) Lots of netfilter hw offload fixes, cleanups and enhancements, from Pablo Neira Ayuso. 10) PTP support for aquantia chips, from Egor Pomozov. 11) Add UDP segmentation offload support to igb, ixgbe, and i40e. From Josh Hunt. 12) Add smart nagle to tipc, from Jon Maloy. 13) Support L2 field rewrite by TC offloads in bnxt_en, from Venkat Duvvuru. 14) Add a flow mask cache to OVS, from Tonghao Zhang. 15) Add XDP support to ice driver, from Maciej Fijalkowski. 16) Add AF_XDP support to ice driver, from Krzysztof Kazimierczak. 17) Support UDP GSO offload in atlantic driver, from Igor Russkikh. 18) Support it in stmmac driver too, from Jose Abreu. 19) Support TIPC encryption and auth, from Tuong Lien. 20) Introduce BPF trampolines, from Alexei Starovoitov. 21) Make page_pool API more numa friendly, from Saeed Mahameed. 22) Introduce route hints to ipv4 and ipv6, from Paolo Abeni. 23) Add UDP segmentation offload to cxgb4, Rahul Lakkireddy" * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next: (1857 commits) libbpf: Fix usage of u32 in userspace code mm: Implement no-MMU variant of vmalloc_user_node_flags slip: Fix use-after-free Read in slip_open net: dsa: sja1105: fix sja1105_parse_rgmii_delays() macvlan: schedule bc_work even if error enetc: add support Credit Based Shaper(CBS) for hardware offload net: phy: add helpers phy_(un)lock_mdio_bus mdio_bus: don't use managed reset-controller ax88179_178a: add ethtool_op_get_ts_info() mlxsw: spectrum_router: Fix use of uninitialized adjacency index mlxsw: spectrum_router: After underlay moves, demote conflicting tunnels bpf: Simplify __bpf_arch_text_poke poke type handling bpf: Introduce BPF_TRACE_x helper for the tracing tests bpf: Add bpf_jit_blinding_enabled for !CONFIG_BPF_JIT bpf, testing: Add various tail call test cases bpf, x86: Emit patchable direct jump as tail call bpf: Constant map key tracking for prog array pokes bpf: Add poke dependency tracking for prog array maps bpf: Add initial poke descriptor table for jit images bpf: Move owner type, jited info into array auxiliary data ... + Changed Files: nan + Parent Hashes: 642356cb5f4a8c82b5ca5ebac288c327d10df236 622dc5ad8052f4f0c6b7a12787696a5caa3c6a58 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Merge networking updates including XDP, AF_XDP, and BPF trampolines, integrating changes for NET, SCTP, and OVS features and hardware support.", + "keywords": "networking, merge, updates", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "Merge networking updates with features like XDP, SCTP, and BPF trampolines affecting various networking components and drivers.", + "keywords": "networking, merge, updates", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 968/6895 - Commit ID: 622dc5ad8052f4f0c6b7a12787696a5caa3c6a58 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 622dc5ad8052f4f0c6b7a12787696a5caa3c6a58 + Author Name: David S. Miller + Author Email: davem@davemloft.net + Commit Date: 1574725618 + Commit Message: + Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next Daniel Borkmann says: ==================== pull-request: bpf-next 2019-11-26 The following pull-request contains BPF updates for your *net-next* tree. We've added 2 non-merge commits during the last 1 day(s) which contain a total of 2 files changed, 14 insertions(+), 3 deletions(-). The main changes, 2 small fixes are: 1) Fix libbpf out of tree compilation which complained about unknown u32 type used in libbpf_find_vmlinux_btf_id() which needs to be __u32 instead, from Andrii Nakryiko. 2) Follow-up fix for the prior BPF mmap series where kbuild bot complained about missing vmalloc_user_node_flags() for no-MMU, also from Andrii Nakryiko. ==================== Signed-off-by: David S. Miller + Changed Files: nan + Parent Hashes: adf6f8cb3f4c2a15d5f35e6cf9ffeb6856d35312 b615e5a1e067dcb327482d1af7463268b89b1629 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Merge commit updating BPF subsystem with two small bug fixes from bpf-next branch.", + "keywords": "merge, fixes, bpf", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "Merge commit updating BPF subsystem with two small bug fixes from bpf-next branch.", + "keywords": "merge, fixes, bpf", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 969/6895 - Commit ID: b615e5a1e067dcb327482d1af7463268b89b1629 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: b615e5a1e067dcb327482d1af7463268b89b1629 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1574718721 + Commit Message: + libbpf: Fix usage of u32 in userspace code u32 is not defined for libbpf when compiled outside of kernel sources (e.g., in Github projection). Use __u32 instead. Fixes: b8c54ea455dc ("libbpf: Add support to attach to fentry/fexit tracing progs") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191125212948.1163343-1-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: ed81745a4c96841937f1da35c0eb66ac312e1480 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes the usage of u32 in libbpf userspace code by replacing it with __u32.", + "keywords": "libbpf, u32, fix", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes the usage of u32 in libbpf userspace code by replacing it with __u32.", + "keywords": "libbpf, u32, fix", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 970/6895 - Commit ID: ed81745a4c96841937f1da35c0eb66ac312e1480 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: ed81745a4c96841937f1da35c0eb66ac312e1480 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1574718599 + Commit Message: + mm: Implement no-MMU variant of vmalloc_user_node_flags To fix build with !CONFIG_MMU, implement it for no-MMU configurations as well. Fixes: fc9702273e2e ("bpf: Add mmap() support for BPF_MAP_TYPE_ARRAY") Reported-by: kbuild test robot Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Johannes Weiner Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20191123220835.1237773-1-andriin@fb.com + Changed Files: mm/nommu.c | 15 +++++++++++++--; 1 file changed, 13 insertions(+), 2 deletions(-) + Parent Hashes: c431047c4efe7903fb1c5a23e0f3f8eb1efc89f9 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit implements a no-MMU variant of vmalloc_user_node_flags to fix a build issue.", + "keywords": "no-MMU,build fix,vmalloc_user_node_flags", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "I'm not sure about the logic component of the commit. The affected logic component is unclear.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit implements a no-MMU variant of vmalloc_user_node_flags to fix a build issue.", + "keywords": "no-MMU,build fix,vmalloc", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component is totally unrelated to the BPF subsystem. It's not related to any above because it totally not related to the BPF subsystem. It's a rare case wrong data and need removed.", + "major_related_logic_component": "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +-------------------- +-------------------- +Processing Commit 971/6895 - Commit ID: 4eb47198e955fc01d14113f525b62a4bc95554c7 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 4eb47198e955fc01d14113f525b62a4bc95554c7 + Author Name: David S. Miller + Author Email: davem@davemloft.net + Commit Date: 1574661947 + Commit Message: + Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next Alexei Starovoitov says: ==================== pull-request: bpf-next 2019-11-24 The following pull-request contains BPF updates for your *net-next* tree. We've added 27 non-merge commits during the last 4 day(s) which contain a total of 50 files changed, 2031 insertions(+), 548 deletions(-). The main changes are: 1) Optimize bpf_tail_call() from retpoline-ed indirect jump to direct jump, from Daniel. 2) Support global variables in libbpf, from Andrii. 3) Cleanup selftests with BPF_TRACE_x() macro, from Martin. 4) Fix devmap hash, from Toke. 5) Fix register bounds after 32-bit conditional jumps, from Yonghong. ==================== Signed-off-by: David S. Miller + Changed Files: nan + Parent Hashes: 5f04ed74a8a3bcb2122738b7eda857187e85aa34 b553a6ec570044fc1ae300c6fb24f9ce204c5894 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit merges BPF-related updates including optimizations, support for global variables, and fixes in selftests and devmap hash.", + "keywords": "BPF, merge, optimization", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "The commit merges BPF-next updates including optimizations, support for global variables, and fixes in devmap hash and register bounds handling.", + "keywords": "BPF, merge, updates", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 972/6895 - Commit ID: b553a6ec570044fc1ae300c6fb24f9ce204c5894 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: b553a6ec570044fc1ae300c6fb24f9ce204c5894 + Author Name: Daniel Borkmann + Author Email: daniel@iogearbox.net + Commit Date: 1574644331 + Commit Message: + bpf: Simplify __bpf_arch_text_poke poke type handling Given that we have BPF_MOD_NOP_TO_{CALL,JUMP}, BPF_MOD_{CALL,JUMP}_TO_NOP and BPF_MOD_{CALL,JUMP}_TO_{CALL,JUMP} poke types and that we also pass in old_addr as well as new_addr, it's a bit redundant and unnecessarily complicates __bpf_arch_text_poke() itself since we can derive the same from the *_addr that were passed in. Hence simplify and use BPF_MOD_{CALL,JUMP} as types which also allows to clean up call-sites. In addition to that, __bpf_arch_text_poke() currently verifies that text matches expected old_insn before we invoke text_poke_bp(). Also add a check on new_insn and skip rewrite if it already matches. Reason why this is rather useful is that it avoids making any special casing in prog_array_map_poke_run() when old and new prog were NULL and has the benefit that also for this case we perform a check on text whether it really matches our expectations. Suggested-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/fcb00a2b0b288d6c73de4ef58116a821c8fe8f2f.1574555798.git.daniel@iogearbox.net + Changed Files: arch/x86/net/bpf_jit_comp.c | 85 +++++++++++++--------------------------------; include/linux/bpf.h | 10 ++----; kernel/bpf/arraymap.c | 12 +------; kernel/bpf/trampoline.c | 8 ++---; 4 files changed, 32 insertions(+), 83 deletions(-) + Parent Hashes: f9a7cf6eb17cd0110c8c47d9e7969fc2716e5772 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit simplifies the __bpf_arch_text_poke function by reducing redundancy in poke type handling for eBPF program modification.", + "keywords": "simplify,poke,types", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit simplifies BPF architecture text poke function by consolidating poke type handling and adding instruction checks, enhancing efficiency and maintainability.", + "keywords": "BPF,simplify,poke", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 973/6895 - Commit ID: f9a7cf6eb17cd0110c8c47d9e7969fc2716e5772 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: f9a7cf6eb17cd0110c8c47d9e7969fc2716e5772 + Author Name: Martin KaFai Lau + Author Email: kafai@fb.com + Commit Date: 1574644331 + Commit Message: + bpf: Introduce BPF_TRACE_x helper for the tracing tests For BPF_PROG_TYPE_TRACING, the bpf_prog's ctx is an array of u64. This patch borrows the idea from BPF_CALL_x in filter.h to convert a u64 to the arg type of the traced function. The new BPF_TRACE_x has an arg to specify the return type of a bpf_prog. It will be used in the future TCP-ops bpf_prog that may return "void". The new macros are defined in the new header file "bpf_trace_helpers.h". It is under selftests/bpf/ for now. It could be moved to libbpf later after seeing more upcoming non-tracing use cases. The tests are changed to use these new macros also. Hence, the k[s]u8/16/32/64 are no longer needed and they are removed from the bpf_helpers.h. Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191123202504.1502696-1-kafai@fb.com + Changed Files: tools/lib/bpf/bpf_helpers.h | 13 ----; tools/testing/selftests/bpf/bpf_trace_helpers.h | 58 ++++++++++++++++; tools/testing/selftests/bpf/progs/fentry_test.c | 72 +++++---------------; tools/testing/selftests/bpf/progs/fexit_bpf2bpf.c | 27 +++-----; tools/testing/selftests/bpf/progs/fexit_test.c | 83 ++++++-----------------; tools/testing/selftests/bpf/progs/kfree_skb.c | 43 ++++--------; tools/testing/selftests/bpf/progs/test_overhead.c | 16 ++---; 7 files changed, 125 insertions(+), 187 deletions(-) + Parent Hashes: b8cd76ca4ae34731d47cd6a876d912a08efcc240 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Introduced BPF_TRACE_x helper macros for tracing tests and adjusted tests to use them, removing unnecessary helpers.", + "keywords": "BPF_TRACE_x,tracing,macros", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing." + ] +} +Rethinking... +new content: +{ + "summary": "Introduced BPF_TRACE_x helper macros for tracing tests and adjusted tests to use them, removing unnecessary helpers.", + "keywords": "BPF_TRACE_x,tracing,macros", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing." + ] +} +-------------------- +-------------------- +Processing Commit 974/6895 - Commit ID: b8cd76ca4ae34731d47cd6a876d912a08efcc240 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: b8cd76ca4ae34731d47cd6a876d912a08efcc240 + Author Name: Daniel Borkmann + Author Email: daniel@iogearbox.net + Commit Date: 1574644288 + Commit Message: + bpf: Add bpf_jit_blinding_enabled for !CONFIG_BPF_JIT Add a definition of bpf_jit_blinding_enabled() when CONFIG_BPF_JIT is not set in order to fix a recent build regression: [...] CC kernel/bpf/verifier.o CC kernel/bpf/inode.o kernel/bpf/verifier.c: In function ‘fixup_bpf_calls’: kernel/bpf/verifier.c:9132:25: error: implicit declaration of function ‘bpf_jit_blinding_enabled’; did you mean ‘bpf_jit_kallsyms_enabled’? [-Werror=implicit-function-declaration] 9132 | bool expect_blinding = bpf_jit_blinding_enabled(prog); | ^~~~~~~~~~~~~~~~~~~~~~~~ | bpf_jit_kallsyms_enabled CC kernel/bpf/helpers.o CC kernel/bpf/hashtab.o [...] Fixes: d2e4c1e6c294 ("bpf: Constant map key tracking for prog array pokes") Reported-by: Jakub Sitnicki Reported-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/40baf8f3507cac4851a310578edfb98ce73b5605.1574541375.git.daniel@iogearbox.net + Changed Files: include/linux/filter.h | 5 +++++; 1 file changed, 5 insertions(+) + Parent Hashes: 6dbae03b2e851fe58e9d9d1ac9ed58017b07960c +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds a definition for bpf_jit_blinding_enabled to fix a build regression when CONFIG_BPF_JIT is not set.", + "keywords": "bpf jit build", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds bpf_jit_blinding_enabled definition to address a build error without CONFIG_BPF_JIT.", + "keywords": "bpf jit regression", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 975/6895 - Commit ID: 6dbae03b2e851fe58e9d9d1ac9ed58017b07960c +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 6dbae03b2e851fe58e9d9d1ac9ed58017b07960c + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1574643852 + Commit Message: + Merge branch 'optimize-bpf_tail_call' Daniel Borkmann says: ==================== This gets rid of indirect jumps for BPF tail calls whenever possible. The series adds emission for *direct* jumps for tail call maps in order to avoid the retpoline overhead from a493a87f38cf ("bpf, x64: implement retpoline for tail call") for situations that allow for it, meaning, for known constant keys at verification time which are used as index into the tail call map. See patch 7/8 for more general details. Thanks! v1 -> v2: - added more test cases - u8 ip_stable -> bool (Andrii) - removed bpf_map_poke_{un,}lock and simplified the code (Andrii) - added break into prog_array_map_poke_untrack since there's just one prog (Andrii) - fixed typo: for for in commit msg (Andrii) - reworked __bpf_arch_text_poke (Andrii) - added subtests, and comment on tests themselves, NULL-NULL transistion (Andrii) - in constant map key tracking I've moved the map_poke_track callback to once we've finished creating the poke tab as otherwise concurrent access from tail call map would blow up (since we realloc the table) rfc -> v1: - Applied Alexei's and Andrii's feeback from https://lore.kernel.org/bpf/cover.1573779287.git.daniel@iogearbox.net/T/#t ==================== Signed-off-by: Alexei Starovoitov + Changed Files: nan + Parent Hashes: c4781e37c6a22c39cb4a57411d14f42aca124f04 79d49ba048ecace59a9850e8a04b618d7848b8e7 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges optimizations for BPF tail calls by using direct jumps where possible to reduce overhead.", + "keywords": "bpf_tail_call, direct jumps, optimizations", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges optimizations for BPF tail calls by incorporating direct jumps to reduce retpoline overhead.", + "keywords": "BPF tail call, direct jumps, optimization", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 976/6895 - Commit ID: 79d49ba048ecace59a9850e8a04b618d7848b8e7 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 79d49ba048ecace59a9850e8a04b618d7848b8e7 + Author Name: Daniel Borkmann + Author Email: daniel@iogearbox.net + Commit Date: 1574643852 + Commit Message: + bpf, testing: Add various tail call test cases Add several BPF kselftest cases for tail calls which test the various patch directions, and that multiple locations are patched in same and different programs. # ./test_progs -n 45 #45/1 tailcall_1:OK #45/2 tailcall_2:OK #45/3 tailcall_3:OK #45/4 tailcall_4:OK #45/5 tailcall_5:OK #45 tailcalls:OK Summary: 1/5 PASSED, 0 SKIPPED, 0 FAILED I've also verified the JITed dump after each of the rewrite cases that it matches expectations. Also regular test_verifier suite passes fine which contains further tail call tests: # ./test_verifier [...] Summary: 1563 PASSED, 0 SKIPPED, 0 FAILED Checked under JIT, interpreter and JIT + hardening. Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/3d6cbecbeb171117dccfe153306e479798fb608d.1574452833.git.daniel@iogearbox.net + Changed Files: tools/testing/selftests/bpf/prog_tests/tailcalls.c | 487 +++++++++++++++++++++; tools/testing/selftests/bpf/progs/tailcall1.c | 48 ++; tools/testing/selftests/bpf/progs/tailcall2.c | 59 +++; tools/testing/selftests/bpf/progs/tailcall3.c | 31 ++; tools/testing/selftests/bpf/progs/tailcall4.c | 33 ++; tools/testing/selftests/bpf/progs/tailcall5.c | 40 ++; 6 files changed, 698 insertions(+) + Parent Hashes: 428d5df1fa4f28daf622c48dd19da35585c9053c +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Add new eBPF selftest cases for tail calls to test various patch directions and multi-location patching.", + "keywords": "selftest,tailcalls,JIT", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Add new eBPF selftest cases for tail calls to verify patch directions and multi-location patching.", + "keywords": "selftest,tailcalls,JIT", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 977/6895 - Commit ID: 428d5df1fa4f28daf622c48dd19da35585c9053c +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 428d5df1fa4f28daf622c48dd19da35585c9053c + Author Name: Daniel Borkmann + Author Email: daniel@iogearbox.net + Commit Date: 1574643851 + Commit Message: + bpf, x86: Emit patchable direct jump as tail call Add initial code emission for *direct* jumps for tail call maps in order to avoid the retpoline overhead from a493a87f38cf ("bpf, x64: implement retpoline for tail call") for situations that allow for it, meaning, for known constant keys at verification time which are used as index into the tail call map. In case of Cilium which makes heavy use of tail calls, constant keys are used in the vast majority, only for a single occurrence we use a dynamic key. High level outline is that if the target prog is NULL in the map, we emit a 5-byte nop for the fall-through case and if not, we emit a 5-byte direct relative jmp to the target bpf_func + skipped prologue offset. Later during runtime, we patch these 5-byte nop/jmps upon tail call map update or deletions dynamically. Note that on x86-64 the direct jmp works as we reuse the same stack frame and skip prologue (as opposed to some other JIT implementations). One of the issues is that the tail call map slots can change at any given time even during JITing. Therefore, we have two passes: i) emit nops for all patchable locations during main JITing phase until we declare prog->jited = 1 eventually. At this point the image is stable, not public yet and with all jmps disabled. While JITing, we collect additional info like poke->ip in order to remember the patch location for later modifications. In ii) bpf_tail_call_direct_fixup() walks over the progs poke_tab, locks the tail call maps poke_mutex to prevent from parallel updates and patches in the right locations via __bpf_arch_text_poke(). Note, the main bpf_arch_text_poke() cannot be used at this point since we're not yet exposed to kallsyms. For the update we use plain memcpy() since the image is not public and still in read-write mode. After patching, we activate that poke entry through poke->ip_stable. Meaning, at this point any tail call map updates/deletions are not going to ignore that poke entry anymore. Then, bpf_arch_text_poke() might still occur on the read-write image until we finally locked it as read-only. Both modifications on the given image are under text_mutex to avoid interference with each other when update requests come in in parallel for different tail call maps (current one we have locked in JIT and different one where poke->ip_stable was already set). Example prog: # ./bpftool p d x i 1655 0: (b7) r3 = 0 1: (18) r2 = map[id:526] 3: (85) call bpf_tail_call#12 4: (b7) r0 = 1 5: (95) exit Before: # ./bpftool p d j i 1655 0xffffffffc076e55c: 0: nopl 0x0(%rax,%rax,1) 5: push %rbp 6: mov %rsp,%rbp 9: sub $0x200,%rsp 10: push %rbx 11: push %r13 13: push %r14 15: push %r15 17: pushq $0x0 _ 19: xor %edx,%edx |_ index (arg 3) 1b: movabs $0xffff88d95cc82600,%rsi |_ map (arg 2) 25: mov %edx,%edx | index >= array->map.max_entries 27: cmp %edx,0x24(%rsi) | 2a: jbe 0x0000000000000066 |_ 2c: mov -0x224(%rbp),%eax | tail call limit check 32: cmp $0x20,%eax | 35: ja 0x0000000000000066 | 37: add $0x1,%eax | 3a: mov %eax,-0x224(%rbp) |_ 40: mov 0xd0(%rsi,%rdx,8),%rax |_ prog = array->ptrs[index] 48: test %rax,%rax | prog == NULL check 4b: je 0x0000000000000066 |_ 4d: mov 0x30(%rax),%rax | goto *(prog->bpf_func + prologue_size) 51: add $0x19,%rax | 55: callq 0x0000000000000061 | retpoline for indirect jump 5a: pause | 5c: lfence | 5f: jmp 0x000000000000005a | 61: mov %rax,(%rsp) | 65: retq |_ 66: mov $0x1,%eax 6b: pop %rbx 6c: pop %r15 6e: pop %r14 70: pop %r13 72: pop %rbx 73: leaveq 74: retq After; state after JIT: # ./bpftool p d j i 1655 0xffffffffc08e8930: 0: nopl 0x0(%rax,%rax,1) 5: push %rbp 6: mov %rsp,%rbp 9: sub $0x200,%rsp 10: push %rbx 11: push %r13 13: push %r14 15: push %r15 17: pushq $0x0 _ 19: xor %edx,%edx |_ index (arg 3) 1b: movabs $0xffff9d8afd74c000,%rsi |_ map (arg 2) 25: mov -0x224(%rbp),%eax | tail call limit check 2b: cmp $0x20,%eax | 2e: ja 0x000000000000003e | 30: add $0x1,%eax | 33: mov %eax,-0x224(%rbp) |_ 39: jmpq 0xfffffffffffd1785 |_ [direct] goto *(prog->bpf_func + prologue_size) 3e: mov $0x1,%eax 43: pop %rbx 44: pop %r15 46: pop %r14 48: pop %r13 4a: pop %rbx 4b: leaveq 4c: retq After; state after map update (target prog): # ./bpftool p d j i 1655 0xffffffffc08e8930: 0: nopl 0x0(%rax,%rax,1) 5: push %rbp 6: mov %rsp,%rbp 9: sub $0x200,%rsp 10: push %rbx 11: push %r13 13: push %r14 15: push %r15 17: pushq $0x0 19: xor %edx,%edx 1b: movabs $0xffff9d8afd74c000,%rsi 25: mov -0x224(%rbp),%eax 2b: cmp $0x20,%eax . 2e: ja 0x000000000000003e . 30: add $0x1,%eax . 33: mov %eax,-0x224(%rbp) |_ 39: jmpq 0xffffffffffb09f55 |_ goto *(prog->bpf_func + prologue_size) 3e: mov $0x1,%eax 43: pop %rbx 44: pop %r15 46: pop %r14 48: pop %r13 4a: pop %rbx 4b: leaveq 4c: retq After; state after map update (no prog): # ./bpftool p d j i 1655 0xffffffffc08e8930: 0: nopl 0x0(%rax,%rax,1) 5: push %rbp 6: mov %rsp,%rbp 9: sub $0x200,%rsp 10: push %rbx 11: push %r13 13: push %r14 15: push %r15 17: pushq $0x0 19: xor %edx,%edx 1b: movabs $0xffff9d8afd74c000,%rsi 25: mov -0x224(%rbp),%eax 2b: cmp $0x20,%eax . 2e: ja 0x000000000000003e . 30: add $0x1,%eax . 33: mov %eax,-0x224(%rbp) |_ 39: nopl 0x0(%rax,%rax,1) |_ fall-through nop 3e: mov $0x1,%eax 43: pop %rbx 44: pop %r15 46: pop %r14 48: pop %r13 4a: pop %rbx 4b: leaveq 4c: retq Nice bonus is that this also shrinks the code emission quite a bit for every tail call invocation. Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/6ada4c1c9d35eeb5f4ecfab94593dafa6b5c4b09.1574452833.git.daniel@iogearbox.net + Changed Files: arch/x86/net/bpf_jit_comp.c | 282 +++++++++++++++++++++++++++++---------------; 1 file changed, 187 insertions(+), 95 deletions(-) + Parent Hashes: d2e4c1e6c2947269346054ac8937ccfe9e0bcc6b +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit enhances the x86 BPF JIT compiler to emit patchable direct jumps for tail calls to improve performance and reduce retpoline overhead.", + "keywords": "x86,JIT,tail", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "The commit modifies x86 BPF tail call handling to use direct jumps instead of retpolines for performance gains.", + "keywords": "x86,JIT,retpoline", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 978/6895 - Commit ID: d2e4c1e6c2947269346054ac8937ccfe9e0bcc6b +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: d2e4c1e6c2947269346054ac8937ccfe9e0bcc6b + Author Name: Daniel Borkmann + Author Email: daniel@iogearbox.net + Commit Date: 1574643851 + Commit Message: + bpf: Constant map key tracking for prog array pokes Add tracking of constant keys into tail call maps. The signature of bpf_tail_call_proto is that arg1 is ctx, arg2 map pointer and arg3 is a index key. The direct call approach for tail calls can be enabled if the verifier asserted that for all branches leading to the tail call helper invocation, the map pointer and index key were both constant and the same. Tracking of map pointers we already do from prior work via c93552c443eb ("bpf: properly enforce index mask to prevent out-of-bounds speculation") and 09772d92cd5a ("bpf: avoid retpoline for lookup/update/ delete calls on maps"). Given the tail call map index key is not on stack but directly in the register, we can add similar tracking approach and later in fixup_bpf_calls() add a poke descriptor to the progs poke_tab with the relevant information for the JITing phase. We internally reuse insn->imm for the rewritten BPF_JMP | BPF_TAIL_CALL instruction in order to point into the prog's poke_tab, and keep insn->imm as 0 as indicator that current indirect tail call emission must be used. Note that publishing to the tracker must happen at the end of fixup_bpf_calls() since adding elements to the poke_tab reallocates its memory, so we need to wait until its in final state. Future work can generalize and add similar approach to optimize plain array map lookups. Difference there is that we need to look into the key value that sits on stack. For clarity in bpf_insn_aux_data, map_state has been renamed into map_ptr_state, so we get map_{ptr,key}_state as trackers. Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/e8db37f6b2ae60402fa40216c96738ee9b316c32.1574452833.git.daniel@iogearbox.net + Changed Files: include/linux/bpf_verifier.h | 3 +-; kernel/bpf/verifier.c | 120 +++++++++++++++++++++++++++++++++++++++----; 2 files changed, 113 insertions(+), 10 deletions(-) + Parent Hashes: da765a2f599304a81a25e77908d1790414ecdbb6 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds constant map key tracking for BPF program array tail call optimizations.", + "keywords": "constant,map,key", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds constant map key tracking to optimize BPF program array tail calls.", + "keywords": "constant,map,key", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 979/6895 - Commit ID: da765a2f599304a81a25e77908d1790414ecdbb6 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: da765a2f599304a81a25e77908d1790414ecdbb6 + Author Name: Daniel Borkmann + Author Email: daniel@iogearbox.net + Commit Date: 1574643851 + Commit Message: + bpf: Add poke dependency tracking for prog array maps This work adds program tracking to prog array maps. This is needed such that upon prog array updates/deletions we can fix up all programs which make use of this tail call map. We add ops->map_poke_{un,}track() helpers to maps to maintain the list of programs and ops->map_poke_run() for triggering the actual update. bpf_array_aux is extended to contain the list head and poke_mutex in order to serialize program patching during updates/deletions. bpf_free_used_maps() will untrack the program shortly before dropping the reference to the map. For clearing out the prog array once all urefs are dropped we need to use schedule_work() to have a sleepable context. The prog_array_map_poke_run() is triggered during updates/deletions and walks the maintained prog list. It checks in their poke_tabs whether the map and key is matching and runs the actual bpf_arch_text_poke() for patching in the nop or new jmp location. Depending on the type of update, we use one of BPF_MOD_{NOP_TO_JUMP,JUMP_TO_NOP,JUMP_TO_JUMP}. Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/1fb364bb3c565b3e415d5ea348f036ff379e779d.1574452833.git.daniel@iogearbox.net + Changed Files: include/linux/bpf.h | 12 ++++; kernel/bpf/arraymap.c | 183 ++++++++++++++++++++++++++++++++++++++++++++++++--; kernel/bpf/core.c | 9 ++-; kernel/bpf/syscall.c | 20 ++++--; 4 files changed, 212 insertions(+), 12 deletions(-) + Parent Hashes: a66886fe6c24ebeeb6dc10fbd9b75158029eacf7 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds dependency tracking for prog array maps to manage updates and deletions affecting programs.", + "keywords": "poke dependency tracking, prog array, updates deletions", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds dependency tracking for prog array maps to manage updates and deletions affecting programs.", + "keywords": "prog array, dependency tracking, updates", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 980/6895 - Commit ID: a66886fe6c24ebeeb6dc10fbd9b75158029eacf7 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: a66886fe6c24ebeeb6dc10fbd9b75158029eacf7 + Author Name: Daniel Borkmann + Author Email: daniel@iogearbox.net + Commit Date: 1574643851 + Commit Message: + bpf: Add initial poke descriptor table for jit images Add initial poke table data structures and management to the BPF prog that can later be used by JITs. Also add an instance of poke specific data for tail call maps; plan for later work is to extend this also for BPF static keys. Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/1db285ec2ea4207ee0455b3f8e191a4fc58b9ade.1574452833.git.daniel@iogearbox.net + Changed Files: include/linux/bpf.h | 20 ++++++++++++++++++++; include/linux/filter.h | 10 ++++++++++; kernel/bpf/core.c | 34 ++++++++++++++++++++++++++++++++++; 3 files changed, 64 insertions(+) + Parent Hashes: 2beee5f57441413b64a9c2bd657e17beabb98d1c +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit introduces a poke descriptor table to manage JIT images in BPF programs.", + "keywords": "poke, descriptor, JIT", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adds a poke descriptor table for managing JIT images in BPF programs.", + "keywords": "poke, descriptor, JIT", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 981/6895 - Commit ID: 2beee5f57441413b64a9c2bd657e17beabb98d1c +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 2beee5f57441413b64a9c2bd657e17beabb98d1c + Author Name: Daniel Borkmann + Author Email: daniel@iogearbox.net + Commit Date: 1574643851 + Commit Message: + bpf: Move owner type, jited info into array auxiliary data We're going to extend this with further information which is only relevant for prog array at this point. Given this info is not used in critical path, move it into its own structure such that the main array map structure can be kept on diet. Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/b9ddccdb0f6f7026489ee955f16c96381e1e7238.1574452833.git.daniel@iogearbox.net + Changed Files: include/linux/bpf.h | 18 +++++++++++-------; kernel/bpf/arraymap.c | 32 ++++++++++++++++++++++++++++++--; kernel/bpf/core.c | 11 +++++------; kernel/bpf/map_in_map.c | 5 ++---; kernel/bpf/syscall.c | 16 ++++++----------; 5 files changed, 54 insertions(+), 28 deletions(-) + Parent Hashes: 6332be04c039a72fca32ed0a4265bac58d606bb6 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit moves certain data into a separate structure to optimize the eBPF array map's efficiency.", + "keywords": "owner,type,data", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit optimizes the eBPF array map by moving non-critical data into a separate auxiliary structure.", + "keywords": "owner,type,auxiliary", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 982/6895 - Commit ID: 6332be04c039a72fca32ed0a4265bac58d606bb6 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 6332be04c039a72fca32ed0a4265bac58d606bb6 + Author Name: Daniel Borkmann + Author Email: daniel@iogearbox.net + Commit Date: 1574643824 + Commit Message: + bpf: Move bpf_free_used_maps into sleepable section We later on are going to need a sleepable context as opposed to plain RCU callback in order to untrack programs we need to poke at runtime and tracking as well as image update is performed under mutex. Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/09823b1d5262876e9b83a8e75df04cf0467357a4.1574452833.git.daniel@iogearbox.net + Changed Files: include/linux/bpf.h | 4 ++++; kernel/bpf/core.c | 23 +++++++++++++++++++++++; kernel/bpf/syscall.c | 20 --------------------; 3 files changed, 27 insertions(+), 20 deletions(-) + Parent Hashes: 4b3da77b72ad6b3c48c6fe4a395ace7db39a12c5 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit moves bpf_free_used_maps into a sleepable section to accommodate future runtime and tracking updates under mutex.", + "keywords": "bpf_free_used_maps,sleepable,mutex", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The syscall interface. It changes the system calls through which user-space programs interact with eBPF.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit moves the bpf_free_used_maps function to a sleepable section for runtime updates under mutex.", + "keywords": "bpf_free_used_maps,sleepable,mutex", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 983/6895 - Commit ID: 4b3da77b72ad6b3c48c6fe4a395ace7db39a12c5 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 4b3da77b72ad6b3c48c6fe4a395ace7db39a12c5 + Author Name: Daniel Borkmann + Author Email: daniel@iogearbox.net + Commit Date: 1574643527 + Commit Message: + bpf, x86: Generalize and extend bpf_arch_text_poke for direct jumps Add BPF_MOD_{NOP_TO_JUMP,JUMP_TO_JUMP,JUMP_TO_NOP} patching for x86 JIT in order to be able to patch direct jumps or nop them out. We need this facility in order to patch tail call jumps and in later work also BPF static keys. Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/aa4784196a8e5e985af4b30a4fe5336bce6e9643.1574452833.git.daniel@iogearbox.net + Changed Files: arch/x86/net/bpf_jit_comp.c | 64 ++++++++++++++++++++++++++++++++-------------; include/linux/bpf.h | 6 +++++; 2 files changed, 52 insertions(+), 18 deletions(-) + Parent Hashes: c4781e37c6a22c39cb4a57411d14f42aca124f04 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Enhance bpf_arch_text_poke to support direct jump and nop patching for x86 JIT tail calls and future BPF static keys.", + "keywords": "bpf_arch_text_poke,direct jumps,nop patching", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Enhance bpf_arch_text_poke to support direct jump and nop patching for x86 JIT tail calls and future BPF static keys.", + "keywords": "bpf_arch_text_poke,direct jumps,nop patching", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 984/6895 - Commit ID: c4781e37c6a22c39cb4a57411d14f42aca124f04 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: c4781e37c6a22c39cb4a57411d14f42aca124f04 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1574643526 + Commit Message: + selftests/bpf: Add BPF trampoline performance test Add a test that benchmarks different ways of attaching BPF program to a kernel function. Here are the results for 2.4Ghz x86 cpu on a kernel without mitigations: $ ./test_progs -n 49 -v|grep events task_rename base 2743K events per sec task_rename kprobe 2419K events per sec task_rename kretprobe 1876K events per sec task_rename raw_tp 2578K events per sec task_rename fentry 2710K events per sec task_rename fexit 2685K events per sec On a kernel with retpoline: $ ./test_progs -n 49 -v|grep events task_rename base 2401K events per sec task_rename kprobe 1930K events per sec task_rename kretprobe 1485K events per sec task_rename raw_tp 2053K events per sec task_rename fentry 2351K events per sec task_rename fexit 2185K events per sec All 5 approaches: - kprobe/kretprobe in __set_task_comm() - raw tracepoint in trace_task_rename() - fentry/fexit in __set_task_comm() are roughly equivalent. __set_task_comm() by itself is quite fast, so any extra instructions add up. Until BPF trampoline was introduced the fastest mechanism was raw tracepoint. kprobe via ftrace was second best. kretprobe is slow due to trap. New fentry/fexit methods via BPF trampoline are clearly the fastest and the difference is more pronounced with retpoline on, since BPF trampoline doesn't use indirect jumps. Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20191122011515.255371-1-ast@kernel.org + Changed Files: .../selftests/bpf/prog_tests/test_overhead.c | 142 +++++++++++++++++++++; tools/testing/selftests/bpf/progs/test_overhead.c | 43 +++++++; 2 files changed, 185 insertions(+) + Parent Hashes: 161f3cbcda06aa70faed6b703066fedbd7653e23 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Add a performance test comparing different BPF attachment methods to kernel functions in selftests.", + "keywords": "BPF,test,performance", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +Rethinking... +new content: +{ + "summary": "Add a selftest that evaluates BPF trampoline performance compared to other attachment methods.", + "keywords": "BPF,trampoline,performance", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "kprobe/ftrace like type kernel dynamic probe programs. It affects kernel-level probes used for tracing kernel functions. It can be other kernel probes in perf-events.", + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing.", + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 985/6895 - Commit ID: 161f3cbcda06aa70faed6b703066fedbd7653e23 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 161f3cbcda06aa70faed6b703066fedbd7653e23 + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1574643526 + Commit Message: + Merge branch 'jmp32-reg-bounds' Yonghong Song says: ==================== With latest llvm, bpf selftest test_progs, which has +alu32 enabled, failed for strobemeta.o and a few other subtests. The reason is due to that verifier did not provide better var_off.mask after jmp32 instructions. This patch set addressed this issue and after the fix, test_progs passed with alu32. Patch #1 provided detailed explanation of the problem and the fix. Patch #2 added three tests in test_verifier. Changelog: v1 -> v2: - do not directly manipulate tnum.{value,mask} in __reg_bound_offset32(), using tnum_lshift/tnum_rshift functions instead - do __reg_bound_offset32() after regular 64bit __reg_bound_offset() since the latter may give a better upper 32bit var_off, which can be inherited by __reg_bound_offset32(). ==================== Signed-off-by: Alexei Starovoitov + Changed Files: nan + Parent Hashes: 6147a140c99f1ded2b519dfbed17e781e5861bf3 260cb5df9d16c5715b32d73cc8af26ad9a17a792 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit merges changes to improve verifier bounds for jmp32 instructions, ensuring alu32 enabled tests pass.", + "keywords": "verifier, jmp32, alu32", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit merges changes to address verifier issues with jmp32 instructions in eBPF programs on new LLVM versions.", + "keywords": "verifier, jmp32, llvm", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 986/6895 - Commit ID: 6147a140c99f1ded2b519dfbed17e781e5861bf3 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 6147a140c99f1ded2b519dfbed17e781e5861bf3 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1574643526 + Commit Message: + selftests/bpf: Ensure core_reloc_kernel is reading test_progs's data only test_core_reloc_kernel.c selftest is the only CO-RE test that reads and returns for validation calling thread's information (pid, tgid, comm). Thus it has to make sure that only test_prog's invocations are honored. Fixes: df36e621418b ("selftests/bpf: add CO-RE relocs testing setup") Reported-by: Alexei Starovoitov Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20191121175900.3486133-1-andriin@fb.com + Changed Files: tools/testing/selftests/bpf/prog_tests/core_reloc.c | 16 +++++++++++-----; .../testing/selftests/bpf/progs/test_core_reloc_kernel.c | 4 ++++; 2 files changed, 15 insertions(+), 5 deletions(-) + Parent Hashes: 1aace10f41adf1080d1cc54de9b3db98b8b8b0fb +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit modifies selftests to ensure correct handling of data specific to test_progs in CO-RE tests.", + "keywords": "selftests, CO-RE, test_progs", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit ensures that selftests read and validate data specific to test_progs for CO-RE tests.", + "keywords": "selftests, CO-RE, validation", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 987/6895 - Commit ID: 260cb5df9d16c5715b32d73cc8af26ad9a17a792 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 260cb5df9d16c5715b32d73cc8af26ad9a17a792 + Author Name: Yonghong Song + Author Email: yhs@fb.com + Commit Date: 1574643526 + Commit Message: + selftests/bpf: Add verifier tests for better jmp32 register bounds Three test cases are added. Test 1: jmp32 'reg op imm'. Test 2: jmp32 'reg op reg' where dst 'reg' has unknown constant and src 'reg' has known constant Test 3: jmp32 'reg op reg' where dst 'reg' has known constant and src 'reg' has unknown constant Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191121170651.449096-1-yhs@fb.com + Changed Files: tools/testing/selftests/bpf/verifier/jmp32.c | 83 ++++++++++++++++++++++++++++; 1 file changed, 83 insertions(+) + Parent Hashes: 581738a681b6faae5725c2555439189ca81c0f1f +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Added three verifier tests for jmp32 register bounds in eBPF selftests.", + "keywords": "verifier tests jmp32", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Added new eBPF verifier test cases for jmp32 instruction register bounds.", + "keywords": "verifier tests jmp32", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 988/6895 - Commit ID: 1aace10f41adf1080d1cc54de9b3db98b8b8b0fb +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 1aace10f41adf1080d1cc54de9b3db98b8b8b0fb + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1574643526 + Commit Message: + libbpf: Fix bpf_object name determination for bpf_object__open_file() If bpf_object__open_file() gets path like "some/dir/obj.o", it should derive BPF object's name as "obj" (unless overriden through opts->object_name). Instead, due to using `path` as a fallback value for opts->obj_name, path is used as is for object name, so for above example BPF object's name will be verbatim "some/dir/obj", which leads to all sorts of troubles, especially when internal maps are concern (they are using up to 8 characters of object name). Fix that by ensuring object_name stays NULL, unless overriden. Fixes: 291ee02b5e40 ("libbpf: Refactor bpf_object__open APIs to use common opts") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191122003527.551556-1-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: 071cdecec57fb5d5df78e6a12114ad7bccea5b0e +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes bpf_object name determination for bpf_object__open_file() to avoid incorrect naming that affects internal maps.", + "keywords": "libbpf,object,name", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Fix the object name derivation for bpf_object__open_file() in libbpf to prevent misnaming issues.", + "keywords": "libbpf,name,fix", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 989/6895 - Commit ID: 581738a681b6faae5725c2555439189ca81c0f1f +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 581738a681b6faae5725c2555439189ca81c0f1f + Author Name: Yonghong Song + Author Email: yhs@fb.com + Commit Date: 1574643526 + Commit Message: + bpf: Provide better register bounds after jmp32 instructions With latest llvm (trunk https://github.com/llvm/llvm-project), test_progs, which has +alu32 enabled, failed for strobemeta.o. The verifier output looks like below with edit to replace large decimal numbers with hex ones. 193: (85) call bpf_probe_read_user_str#114 R0=inv(id=0) 194: (26) if w0 > 0x1 goto pc+4 R0_w=inv(id=0,umax_value=0xffffffff00000001) 195: (6b) *(u16 *)(r7 +80) = r0 196: (bc) w6 = w0 R6_w=inv(id=0,umax_value=0xffffffff,var_off=(0x0; 0xffffffff)) 197: (67) r6 <<= 32 R6_w=inv(id=0,smax_value=0x7fffffff00000000,umax_value=0xffffffff00000000, var_off=(0x0; 0xffffffff00000000)) 198: (77) r6 >>= 32 R6=inv(id=0,umax_value=0xffffffff,var_off=(0x0; 0xffffffff)) ... 201: (79) r8 = *(u64 *)(r10 -416) R8_w=map_value(id=0,off=40,ks=4,vs=13872,imm=0) 202: (0f) r8 += r6 R8_w=map_value(id=0,off=40,ks=4,vs=13872,umax_value=0xffffffff,var_off=(0x0; 0xffffffff)) 203: (07) r8 += 9696 R8_w=map_value(id=0,off=9736,ks=4,vs=13872,umax_value=0xffffffff,var_off=(0x0; 0xffffffff)) ... 255: (bf) r1 = r8 R1_w=map_value(id=0,off=9736,ks=4,vs=13872,umax_value=0xffffffff,var_off=(0x0; 0xffffffff)) ... 257: (85) call bpf_probe_read_user_str#114 R1 unbounded memory access, make sure to bounds check any array access into a map The value range for register r6 at insn 198 should be really just 0/1. The umax_value=0xffffffff caused later verification failure. After jmp instructions, the current verifier already tried to use just obtained information to get better register range. The current mechanism is for 64bit register only. This patch implemented to tighten the range for 32bit sub-registers after jmp32 instructions. With the patch, we have the below range ranges for the above code sequence: 193: (85) call bpf_probe_read_user_str#114 R0=inv(id=0) 194: (26) if w0 > 0x1 goto pc+4 R0_w=inv(id=0,smax_value=0x7fffffff00000001,umax_value=0xffffffff00000001, var_off=(0x0; 0xffffffff00000001)) 195: (6b) *(u16 *)(r7 +80) = r0 196: (bc) w6 = w0 R6_w=inv(id=0,umax_value=0xffffffff,var_off=(0x0; 0x1)) 197: (67) r6 <<= 32 R6_w=inv(id=0,umax_value=0x100000000,var_off=(0x0; 0x100000000)) 198: (77) r6 >>= 32 R6=inv(id=0,umax_value=1,var_off=(0x0; 0x1)) ... 201: (79) r8 = *(u64 *)(r10 -416) R8_w=map_value(id=0,off=40,ks=4,vs=13872,imm=0) 202: (0f) r8 += r6 R8_w=map_value(id=0,off=40,ks=4,vs=13872,umax_value=1,var_off=(0x0; 0x1)) 203: (07) r8 += 9696 R8_w=map_value(id=0,off=9736,ks=4,vs=13872,umax_value=1,var_off=(0x0; 0x1)) ... 255: (bf) r1 = r8 R1_w=map_value(id=0,off=9736,ks=4,vs=13872,umax_value=1,var_off=(0x0; 0x1)) ... 257: (85) call bpf_probe_read_user_str#114 ... At insn 194, the register R0 has better var_off.mask and smax_value. Especially, the var_off.mask ensures later lshift and rshift maintains proper value range. Suggested-by: Alexei Starovoitov Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191121170650.449030-1-yhs@fb.com + Changed Files: kernel/bpf/verifier.c | 19 +++++++++++++++++++; 1 file changed, 19 insertions(+) + Parent Hashes: 6147a140c99f1ded2b519dfbed17e781e5861bf3 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Enhances the eBPF verifier to provide more precise register bounds for 32-bit jumps.", + "keywords": "verifier, register, bounds", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Enhances the eBPF verifier to provide more precise register bounds for 32-bit jumps.", + "keywords": "verifier, register, bounds", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF verifier. This component ensures that eBPF programs are safe to run within the kernel.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 990/6895 - Commit ID: 071cdecec57fb5d5df78e6a12114ad7bccea5b0e +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 071cdecec57fb5d5df78e6a12114ad7bccea5b0e + Author Name: Toke Høiland-Jørgensen + Author Email: toke@redhat.com + Commit Date: 1574643526 + Commit Message: + xdp: Fix cleanup on map free for devmap_hash map type Tetsuo pointed out that it was not only the device unregister hook that was broken for devmap_hash types, it was also cleanup on map free. So better fix this as well. While we're at it, there's no reason to allocate the netdev_map array for DEVMAP_HASH, so skip that and adjust the cost accordingly. Fixes: 6f9d451ab1a3 ("xdp: Add devmap_hash map type for looking up devices by hashed index") Reported-by: Tetsuo Handa Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20191121133612.430414-1-toke@redhat.com + Changed Files: kernel/bpf/devmap.c | 74 +++++++++++++++++++++++++++++++++--------------------; 1 file changed, 46 insertions(+), 28 deletions(-) + Parent Hashes: 1f60750401c7672419e1b606e2b73727c1f8626c +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes cleanup on map free and unnecessary allocation for devmap_hash in XDP.", + "keywords": "fixes,devmap_hash,XDP", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes cleanup on map free and unnecessary allocation for devmap_hash in XDP.", + "keywords": "fixes,devmap_hash,XDP", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework.", + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 991/6895 - Commit ID: 1f60750401c7672419e1b606e2b73727c1f8626c +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 1f60750401c7672419e1b606e2b73727c1f8626c + Author Name: Alexei Starovoitov + Author Email: ast@kernel.org + Commit Date: 1574643526 + Commit Message: + Merge branch 'libbpf-global-vars' Andrii Nakryiko says: ==================== This patch set salvages all the non-extern-specific changes out of blocked externs patch set ([0]). In addition to small clean ups, it also refactors libbpf's handling of relocations and allows support for global (non-static) variables. [0] https://patchwork.ozlabs.org/project/netdev/list/?series=143358&state=* ==================== Signed-off-by: Alexei Starovoitov + Changed Files: nan + Parent Hashes: a8fdaad5cfd250b9effcec942b3bf7bc5a6c8b17 393cdfbee809891dc6ba859a44cc6441fa8dce9e +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges changes to libbpf for handling global variables and relocations.", + "keywords": "libbpf,global,relocations", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges libbpf changes for global variable support and relocation handling.", + "keywords": "libbpf,global,relocations", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 992/6895 - Commit ID: a8fdaad5cfd250b9effcec942b3bf7bc5a6c8b17 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: a8fdaad5cfd250b9effcec942b3bf7bc5a6c8b17 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1574643525 + Commit Message: + selftests/bpf: Integrate verbose verifier log into test_progs Add exra level of verboseness, activated by -vvv argument. When -vv is specified, verbose libbpf and verifier log (level 1) is output, even for successful tests. With -vvv, verifier log goes to level 2. This is extremely useful to debug verifier failures, as well as just see the state and flow of verification. Before this, you'd have to go and modify load_program()'s source code inside libbpf to specify extra log_level flags, which is suboptimal to say the least. Currently -vv and -vvv triggering verifier output is integrated into test_stub's bpf_prog_load as well as bpf_verif_scale.c tests. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191120003548.4159797-1-andriin@fb.com + Changed Files: .../testing/selftests/bpf/prog_tests/bpf_verif_scale.c | 4 +++-; tools/testing/selftests/bpf/test_progs.c | 18 ++++++++++++------; tools/testing/selftests/bpf/test_progs.h | 10 ++++++++--; tools/testing/selftests/bpf/test_stub.c | 4 ++++; 4 files changed, 27 insertions(+), 9 deletions(-) + Parent Hashes: 5940c5bf6504f66f57f03f1d0046abfaf2198b3a +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit enhances verbosity options for eBPF verification logs in test programs to aid debugging.", + "keywords": "verbosity,verification,debugging", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit enhances verbosity in eBPF test logs to aid debugging by integrating different verbosity levels.", + "keywords": "verbosity,verifier,debugging", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 993/6895 - Commit ID: 393cdfbee809891dc6ba859a44cc6441fa8dce9e +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 393cdfbee809891dc6ba859a44cc6441fa8dce9e + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1574643525 + Commit Message: + libbpf: Support initialized global variables Initialized global variables are no different in ELF from static variables, and don't require any extra support from libbpf. But they are matching semantics of global data (backed by BPF maps) more closely, preventing LLVM/Clang from aggressively inlining constant values and not requiring volatile incantations to prevent those. This patch enables global variables. It still disables uninitialized variables, which will be put into special COM (common) ELF section, because BPF doesn't allow uninitialized data to be accessed. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191121070743.1309473-5-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.c | 9 ++-------; tools/testing/selftests/bpf/progs/test_core_reloc_arrays.c | 4 ++--; .../selftests/bpf/progs/test_core_reloc_bitfields_direct.c | 4 ++--; .../selftests/bpf/progs/test_core_reloc_bitfields_probed.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_existence.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_flavors.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_ints.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_kernel.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_misc.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_mods.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_nesting.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_primitives.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_ptr_as_arr.c | 4 ++--; tools/testing/selftests/bpf/progs/test_core_reloc_size.c | 4 ++--; 14 files changed, 28 insertions(+), 33 deletions(-) + Parent Hashes: 8983b731ceb42939acaa6158abcf8adb56f834bf +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit allows libbpf to support initialized global variables, aligning them with BPF map semantics.", + "keywords": "libbpf,initialized,global", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit allows libbpf to support initialized global variables, aligning them with BPF map semantics.", + "keywords": "libbpf,initialized,global", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 994/6895 - Commit ID: 5940c5bf6504f66f57f03f1d0046abfaf2198b3a +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 5940c5bf6504f66f57f03f1d0046abfaf2198b3a + Author Name: Jakub Kicinski + Author Email: jakub.kicinski@netronome.com + Commit Date: 1574643525 + Commit Message: + selftests, bpftool: Skip the build test if not in tree If selftests are copied over to another machine/location for execution the build test of bpftool will obviously not work, since the sources are not copied. Skip it if we can't find bpftool's Makefile. Reported-by: Naresh Kamboju Signed-off-by: Jakub Kicinski Signed-off-by: Quentin Monnet Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191119105010.19189-3-quentin.monnet@netronome.com + Changed Files: tools/testing/selftests/bpf/test_bpftool_build.sh | 4 ++++; 1 file changed, 4 insertions(+) + Parent Hashes: 31f8b8295bb8997f139fe34b68654f8f1408f0da +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Skip bpftool build test if sources are not available in selftests environment.", + "keywords": "selftests,bpftool,build", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Skip bpftool build test if sources are not available in selftests environment.", + "keywords": "selftests,bpftool,build", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 995/6895 - Commit ID: 8983b731ceb42939acaa6158abcf8adb56f834bf +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 8983b731ceb42939acaa6158abcf8adb56f834bf + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1574643525 + Commit Message: + libbpf: Fix various errors and warning reported by checkpatch.pl Fix a bunch of warnings and errors reported by checkpatch.pl, to make it easier to spot new problems. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191121070743.1309473-4-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.c | 38 +++++++++++++++++++++-----------------; 1 file changed, 21 insertions(+), 17 deletions(-) + Parent Hashes: 1f8e2bcb2cd5ee1a731fb625a5438e2c305f6a7c +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes errors and warnings in libbpf identified by checkpatch.pl for improved code quality.", + "keywords": "libbpf,fix,checkpatch", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes errors and warnings in libbpf identified by checkpatch.pl to enhance code quality.", + "keywords": "libbpf,fix,checkpatch", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 996/6895 - Commit ID: 31f8b8295bb8997f139fe34b68654f8f1408f0da +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 31f8b8295bb8997f139fe34b68654f8f1408f0da + Author Name: Quentin Monnet + Author Email: quentin.monnet@netronome.com + Commit Date: 1574643525 + Commit Message: + selftests, bpftool: Set EXIT trap after usage function The trap on EXIT is used to clean up any temporary directory left by the build attempts. It is not needed when the user simply calls the script with its --help option, and may not be needed either if we add checks (e.g. on the availability of bpftool files) before the build attempts. Let's move this trap and related variables lower down in the code, so that we don't accidentally change the value returned from the script on early exits at pre-checks. Signed-off-by: Quentin Monnet Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Kicinski Link: https://lore.kernel.org/bpf/20191119105010.19189-2-quentin.monnet@netronome.com + Changed Files: tools/testing/selftests/bpf/test_bpftool_build.sh | 26 +++++++++++------------; 1 file changed, 13 insertions(+), 13 deletions(-) + Parent Hashes: a89b2cbf71d64b61e79bbe5cb7ff4664797eeaaf +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit refactors the EXIT trap usage in the bpftool build test script to improve early exit handling.", + "keywords": "EXIT trap refactor", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit refactors the EXIT trap usage in the bpftool build test script to improve early exit handling.", + "keywords": "EXIT trap refactor", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 997/6895 - Commit ID: 1f8e2bcb2cd5ee1a731fb625a5438e2c305f6a7c +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 1f8e2bcb2cd5ee1a731fb625a5438e2c305f6a7c + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1574643525 + Commit Message: + libbpf: Refactor relocation handling Relocation handling code is convoluted and unnecessarily deeply nested. Split out per-relocation logic into separate function. Also refactor the logic to be more a sequence of per-relocation type checks and processing steps, making it simpler to follow control flow. This makes it easier to further extends it to new kinds of relocations (e.g., support for extern variables). This patch also makes relocation's section verification more robust. Previously relocations against not yet supported externs were silently ignored because of obj->efile.text_shndx was zero, when all BPF programs had custom section names and there was no .text section. Also, invalid LDIMM64 relocations against non-map sections were passed through, if they were pointing to a .text section (or 0, which is invalid section). All these bugs are fixed within this refactoring and checks are made more appropriate for each type of relocation. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191121070743.1309473-3-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.c | 261 +++++++++++++++++++++++++++----------------------; 1 file changed, 143 insertions(+), 118 deletions(-) + Parent Hashes: ffc88174cdcf5f51fb7f6298fe9203a36c904f1f +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Refactor relocation handling in libbpf to simplify control flow and improve robustness.", + "keywords": "refactor,relocation,libbpf", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Refactor relocation handling in libbpf to simplify control flow and improve robustness.", + "keywords": "refactor,relocation,libbpf", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 998/6895 - Commit ID: a89b2cbf71d64b61e79bbe5cb7ff4664797eeaaf +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: a89b2cbf71d64b61e79bbe5cb7ff4664797eeaaf + Author Name: Quentin Monnet + Author Email: quentin.monnet@netronome.com + Commit Date: 1574643525 + Commit Message: + tools, bpf: Fix build for 'make -s tools/bpf O=' Building selftests with 'make TARGETS=bpf kselftest' was fixed in commit 55d554f5d140 ("tools: bpf: Use !building_out_of_srctree to determine srctree"). However, by updating $(srctree) in tools/bpf/Makefile for in-tree builds only, we leave out the case where we pass an output directory to build BPF tools, but $(srctree) is not set. This typically happens for: $ make -s tools/bpf O=/tmp/foo Makefile:40: /tools/build/Makefile.feature: No such file or directory Fix it by updating $(srctree) in the Makefile not only for out-of-tree builds, but also if $(srctree) is empty. Detected with test_bpftool_build.sh. Fixes: 55d554f5d140 ("tools: bpf: Use !building_out_of_srctree to determine srctree") Signed-off-by: Quentin Monnet Signed-off-by: Daniel Borkmann Acked-by: Jakub Kicinski Link: https://lore.kernel.org/bpf/20191119105626.21453-1-quentin.monnet@netronome.com + Changed Files: tools/bpf/Makefile | 6 ++++++; 1 file changed, 6 insertions(+) + Parent Hashes: a0f17cc6665c80ab2765f9244c41ec127821f343 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes the build issue for BPF tools when an output directory is specified but srctree is not set.", + "keywords": "build, srctree, Makefile", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes the build issue for BPF tools when an output directory is specified but srctree is not set.", + "keywords": "build, srctree, Makefile", + "commit_classification": "A build system or CI/CD change. It affects the build process continuous integration or deployment pipelines.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 999/6895 - Commit ID: ffc88174cdcf5f51fb7f6298fe9203a36c904f1f +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: ffc88174cdcf5f51fb7f6298fe9203a36c904f1f + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1574643525 + Commit Message: + selftests/bpf: Ensure no DWARF relocations for BPF object files Add -mattr=dwarfris attribute to llc to avoid having relocations against DWARF data. These relocations make it impossible to inspect DWARF contents: all strings are invalid. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191121070743.1309473-2-andriin@fb.com + Changed Files: tools/testing/selftests/bpf/Makefile | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: a8fdaad5cfd250b9effcec942b3bf7bc5a6c8b17 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Modify Makefile to ensure no DWARF relocations for BPF object files.", + "keywords": "DWARF,relocations,Makefile", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Modify Makefile to ensure no DWARF relocations for BPF object files.", + "keywords": "DWARF,relocations,Makefile", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 1000/6895 - Commit ID: a0f17cc6665c80ab2765f9244c41ec127821f343 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: a0f17cc6665c80ab2765f9244c41ec127821f343 + Author Name: Quentin Monnet + Author Email: quentin.monnet@netronome.com + Commit Date: 1574643524 + Commit Message: + tools, bpftool: Fix warning on ignored return value for 'read' When building bpftool, a warning was introduced by commit a94364603610 ("bpftool: Allow to read btf as raw data"), because the return value from a call to 'read()' is ignored. Let's address it. Signed-off-by: Quentin Monnet Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Kicinski Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20191119111706.22440-1-quentin.monnet@netronome.com + Changed Files: tools/bpf/bpftool/btf.c | 6 +++---; 1 file changed, 3 insertions(+), 3 deletions(-) + Parent Hashes: 5d946c5abbaf68083fa6a41824dd79e1f06286d8 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes a warning in bpftool by correctly handling the return value of the 'read' function.", + "keywords": "bpftool,warning,read", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes a warning in bpftool by correctly handling the return value of the 'read' function.", + "keywords": "bpftool,warning,read", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The bpftool utility. It modifies the bpftool utility used for introspecting and interacting with eBPF programs and maps.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 1001/6895 - Commit ID: 5d946c5abbaf68083fa6a41824dd79e1f06286d8 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 5d946c5abbaf68083fa6a41824dd79e1f06286d8 + Author Name: Luc Van Oostenryck + Author Email: luc.vanoostenryck@gmail.com + Commit Date: 1574643524 + Commit Message: + xsk: Fix xsk_poll()'s return type xsk_poll() is defined as returning 'unsigned int' but the .poll method is declared as returning '__poll_t', a bitwise type. Fix this by using the proper return type and using the EPOLL constants instead of the POLL ones, as required for __poll_t. Signed-off-by: Luc Van Oostenryck Signed-off-by: Daniel Borkmann Acked-by: Björn Töpel Link: https://lore.kernel.org/bpf/20191120001042.30830-1-luc.vanoostenryck@gmail.com + Changed Files: net/xdp/xsk.c | 8 ++++----; 1 file changed, 4 insertions(+), 4 deletions(-) + Parent Hashes: c392bccf2c1075b5d2cc9022d0116a516acb721d +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes the xsk_poll() return type to use __poll_t with EPOLL constants, correcting an inconsistency.", + "keywords": "xsk_poll, __poll_t, fix", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes the xsk_poll() return type to use __poll_t with EPOLL constants, correcting an inconsistency.", + "keywords": "xsk_poll, __poll_t, fix", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "eBPF events related Logic. E.g. It changes how events like XDP socket tc or tracing events like tracepoint profile k/uprobe or others like HID schedule LSM attached or affect eBPF programs.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +-------------------- +-------------------- +Processing Commit 1002/6895 - Commit ID: 84bb46cd62283cc371769ec1f77ff7924099f584 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 84bb46cd62283cc371769ec1f77ff7924099f584 + Author Name: Jakub Kicinski + Author Email: jakub.kicinski@netronome.com + Commit Date: 1574531762 + Commit Message: + Revert "bpf: Emit audit messages upon successful prog load and unload" This commit reverts commit 91e6015b082b ("bpf: Emit audit messages upon successful prog load and unload") and its follow up commit 7599a896f2e4 ("audit: Move audit_log_task declaration under CONFIG_AUDITSYSCALL") as requested by Paul Moore. The change needs close review on linux-audit, tests etc. Signed-off-by: Jakub Kicinski + Changed Files: include/linux/audit.h | 5 -----; include/uapi/linux/audit.h | 1 -; kernel/auditsc.c | 2 +-; kernel/bpf/syscall.c | 31 -------------------------------; 4 files changed, 1 insertion(+), 38 deletions(-) + Parent Hashes: 8dcdc9524cad74968b18322651d6fafb288a00ad +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit reverts a previous change that emitted audit messages upon eBPF program loading and unloading.", + "keywords": "revert, audit, bpf", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The syscall interface. It changes the system calls through which user-space programs interact with eBPF.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit reverts changes that emitted audit messages during eBPF program load and unload.", + "keywords": "revert, audit, bpf", + "commit_classification": "It's other type of commit. It does not fit into any of the categories listed above.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 1003/6895 - Commit ID: 8cacac6ecd6d289d4ab52590784636a5b1043c66 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 8cacac6ecd6d289d4ab52590784636a5b1043c66 + Author Name: Ingo Molnar + Author Email: mingo@kernel.org + Commit Date: 1574496013 + Commit Message: + Merge tag 'perf-core-for-mingo-5.5-20191122' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core Pull perf/core improvements and fixes from Arnaldo Carvalho de Melo: perf report: Jin Yao: - Allow entering the annotation view (symbol source/assembly + overhead/cycles/etc column) from the 'perf report --total-cycles' interface. E.g.: # perf record --all-cpus --branch-any --all-kernel ^C[ perf record: Woken up 5 times to write data ] # # perf evlist -v cycles: size: 120, { sample_period, sample_freq }: 4000, sample_type: IP|TID|TIME|CPU|PERIOD|BRANCH_STACK, read_format: ID, disabled: 1, inherit: 1, exclude_user: 1, mmap: 1, comm: 1, freq: 1, task: 1, precise_ip: 3, sample_id_all: 1, exclude_guest: 1, mmap2: 1, comm_exec: 1, ksymbol: 1, bpf_event: 1, branch_sample_type: ANY # # perf report --total-cycles # # Samples: 78762 of event 'cycles' Sampled Sampled Avg Avg Cycles% Cycles Cycles% Cycles [Program Block Range] Shared Object 1.72% 95.8K 0.00% 254 [msr.h:105 -> msr.h:166] [kernel.vmlinux] 1.56% 107.6K 0.00% 618 [compiler.h:199 -> common.c:301] [kernel.vmlinux] 0.83% 46.3K 0.00% 409 [entry_64.S:153 -> entry_64.S:175] [kernel.vmlinux] 0.83% 46.1K 0.00% 83 [jump_label.h:41 -> tsc.c:230] [kernel.vmlinux] 0.64% 36.9K 0.01% 1.4K [hda_intel.c:904 -> hda_intel.c:916] [snd_hda_intel] 0.57% 30.2K 0.00% 282 [file.c:710 -> file.c:730] [kernel.vmlinux] 0.48% 25.8K 0.00% 82 [spinlock.c:158 -> spinlock.c:160] [kernel.vmlinux] 0.45% 23.7K 0.00% 369 [tick-broadcast.c:585 -> tick-broadcast.c:586] [kernel.vmlinux] 0.44% 24.4K 0.00% 73 [msr.h:236 -> tsc.c:1088] [kernel.vmlinux] 0.43% 22.7K 0.00% 144 [cpuidle.c:229 -> cpuidle.c:232] [kernel.vmlinux] Then press 'A' or Enter on one of those lines, just like with 'perf top', say the top one: [msr.h:105 -> msr.h:166], then this shows up: Samples: 78K of event 'cycles', 4000 Hz, Event count (approx.): 78762 native_write_msr /lib/modules/5.4.0-rc8/build/vmlinux [Percent: local period] Percent│ IPC Cycle (Average IPC: 0.02, IPC Coverage: 50.0%) │ │ Disassembly of section .text: │ │ ffffffff8106c480 : │ __wrmsr(): │ return EAX_EDX_VAL(val, low, high); │ } │ │ static inline void notrace __wrmsr(unsigned int msr, u32 low, u32 high) │ { │ asm volatile("1: wrmsr\n" 49.16 │0.02 mov %edi,%ecx │0.02 mov %esi,%eax │0.02 wrmsr │ arch_static_branch(): │ #include │ #include │ │ static __always_inline bool arch_static_branch(struct static_key *key, bool branch) │ { │ asm_volatile_goto("1:" 0.79 │0.02 nop │ native_write_msr(): │ { │ __wrmsr(msr, low, high); │ │ if (msr_tracepoint_active(__tracepoint_write_msr)) │ do_trace_write_msr(msr, ((u64)high << 32 | low), 0); │ } 50.05 │0.02 254 ← retq │ do_trace_write_msr(msr, ((u64)high << 32 | low), 0); │ shl $0x20,%rdx │ mov %esi,%esi │ or %rdx,%rsi │ xor %edx,%edx │ → jmpq do_trace_write_msr We need to improve this to show the source code line numbers in the annotation view, so one can go from that program block to the annotation view and see those source code line numbers straight away. auxtrace/Intel PT: Adrian Hunter: - Add support for AUX area sampling, requires new functionality that will land in 5.5, its already in tip. This includes kernel capability querying so that it fails gracefully with older kernels, duimping aux area samples in 'perf report -D' and 'perf script'. perf.data: Alexey Budankov: - Fix decompression of PERF_RECORD_COMPRESSED records. core: Arnaldo Carvalho de Melo: - Use the 'dcacheline' cmp routine to find the right DSOs taking into account the 'maj', 'min', 'ino' and 'ino_generation', that got moved from 'struct map' to 'struct dso', where it belongs. This further reduces the size of 'struct map', there is still more work to do to maybe get it to max one cacheline. libtraceevent: Hewenliang: - Fix memory leakage in copy_filter_type(). Sudip Mukherjee: - Fix header installation. perf parse: Ian Rogers : - Fix potential memory leak when handling tracepoint errors, found using LLVM's libFuzzer. perf probe: Colin Ian King: - Fix spelling mistake "addrees" -> "address". Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Ingo Molnar + Changed Files: nan + Parent Hashes: 8f6ee51d772d0dab407d868449d2c5d9c8d2b6fc 4584f084aa9d8033d5911935837dbee7b082d0e9 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges performance core improvements and fixes related to various perf subsystems for the Linux kernel 5.5.", + "keywords": "perf, core, merge", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges performance core improvements and fixes related to various perf subsystems for the Linux kernel 5.5.", + "keywords": "perf,core,merge", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 1004/6895 - Commit ID: 8163999db445021f2651a8a47b5632483e8722ea +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 8163999db445021f2651a8a47b5632483e8722ea + Author Name: John Fastabend + Author Email: john.fastabend@gmail.com + Commit Date: 1574372625 + Commit Message: + bpf: skmsg, fix potential psock NULL pointer dereference Report from Dan Carpenter, net/core/skmsg.c:792 sk_psock_write_space() error: we previously assumed 'psock' could be null (see line 790) net/core/skmsg.c 789 psock = sk_psock(sk); 790 if (likely(psock && sk_psock_test_state(psock, SK_PSOCK_TX_ENABLED))) Check for NULL 791 schedule_work(&psock->work); 792 write_space = psock->saved_write_space; ^^^^^^^^^^^^^^^^^^^^^^^^ 793 rcu_read_unlock(); 794 write_space(sk); Ensure psock dereference on line 792 only occurs if psock is not null. Reported-by: Dan Carpenter Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface") Signed-off-by: John Fastabend Signed-off-by: David S. Miller + Changed Files: net/core/skmsg.c | 13 ++++++++-----; 1 file changed, 8 insertions(+), 5 deletions(-) + Parent Hashes: 7599a896f2e46e9c072e02a8299a67d4d2f96675 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes a potential NULL pointer dereference in skmsg handling within the eBPF sockmap interface.", + "keywords": "NULL, skmsg, psock", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes a potential NULL pointer dereference in skmsg handling within the eBPF sockmap interface.", + "keywords": "NULL, skmsg, psock", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The implementation happens in other subsystem and is related to eBPF events. e.g. probes perf events tracepoints network scheduler HID LSM etc. Note it's still related to how eBPF programs interact with these events.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic." + ] +} +-------------------- +-------------------- +Processing Commit 1005/6895 - Commit ID: 7599a896f2e46e9c072e02a8299a67d4d2f96675 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 7599a896f2e46e9c072e02a8299a67d4d2f96675 + Author Name: Jiri Olsa + Author Email: jolsa@kernel.org + Commit Date: 1574367289 + Commit Message: + audit: Move audit_log_task declaration under CONFIG_AUDITSYSCALL The 0-DAY found that audit_log_task is not declared under CONFIG_AUDITSYSCALL which causes compilation error when it is not defined: kernel/bpf/syscall.o: In function `bpf_audit_prog.isra.30': >> syscall.c:(.text+0x860): undefined reference to `audit_log_task' Adding the audit_log_task declaration and stub within CONFIG_AUDITSYSCALL ifdef. Fixes: 91e6015b082b ("bpf: Emit audit messages upon successful prog load and unload") Reported-by: kbuild test robot Signed-off-by: Jiri Olsa Signed-off-by: David S. Miller + Changed Files: include/linux/audit.h | 8 +++++---; 1 file changed, 5 insertions(+), 3 deletions(-) + Parent Hashes: 43da14110cb4d20de0b4b097da88addefeab5f13 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit moves the audit_log_task declaration under CONFIG_AUDITSYSCALL to fix a compilation error.", + "keywords": "audit, declaration, CONFIG_AUDITSYSCALL", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adjusts the audit_log_task declaration to fix compilation errors under specific configurations.", + "keywords": "audit,declaration,compilation", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +-------------------- +-------------------- +Processing Commit 1006/6895 - Commit ID: ee5a489fd9645104925e5cdf8f8e455d833730b9 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: ee5a489fd9645104925e5cdf8f8e455d833730b9 + Author Name: David S. Miller + Author Email: davem@davemloft.net + Commit Date: 1574302283 + Commit Message: + Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next Daniel Borkmann says: ==================== pull-request: bpf-next 2019-11-20 The following pull-request contains BPF updates for your *net-next* tree. We've added 81 non-merge commits during the last 17 day(s) which contain a total of 120 files changed, 4958 insertions(+), 1081 deletions(-). There are 3 trivial conflicts, resolve it by always taking the chunk from 196e8ca74886c433: <<<<<<< HEAD ======= void *bpf_map_area_mmapable_alloc(u64 size, int numa_node); >>>>>>> 196e8ca74886c433dcfc64a809707074b936aaf5 <<<<<<< HEAD void *bpf_map_area_alloc(u64 size, int numa_node) ======= static void *__bpf_map_area_alloc(u64 size, int numa_node, bool mmapable) >>>>>>> 196e8ca74886c433dcfc64a809707074b936aaf5 <<<<<<< HEAD if (size <= (PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER)) { ======= /* kmalloc()'ed memory can't be mmap()'ed */ if (!mmapable && size <= (PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER)) { >>>>>>> 196e8ca74886c433dcfc64a809707074b936aaf5 The main changes are: 1) Addition of BPF trampoline which works as a bridge between kernel functions, BPF programs and other BPF programs along with two new use cases: i) fentry/fexit BPF programs for tracing with practically zero overhead to call into BPF (as opposed to k[ret]probes) and ii) attachment of the former to networking related programs to see input/output of networking programs (covering xdpdump use case), from Alexei Starovoitov. 2) BPF array map mmap support and use in libbpf for global data maps; also a big batch of libbpf improvements, among others, support for reading bitfields in a relocatable manner (via libbpf's CO-RE helper API), from Andrii Nakryiko. 3) Extend s390x JIT with usage of relative long jumps and loads in order to lift the current 64/512k size limits on JITed BPF programs there, from Ilya Leoshkevich. 4) Add BPF audit support and emit messages upon successful prog load and unload in order to have a timeline of events, from Daniel Borkmann and Jiri Olsa. 5) Extension to libbpf and xdpsock sample programs to demo the shared umem mode (XDP_SHARED_UMEM) as well as RX-only and TX-only sockets, from Magnus Karlsson. 6) Several follow-up bug fixes for libbpf's auto-pinning code and a new API call named bpf_get_link_xdp_info() for retrieving the full set of prog IDs attached to XDP, from Toke Høiland-Jørgensen. 7) Add BTF support for array of int, array of struct and multidimensional arrays and enable it for skb->cb[] access in kfree_skb test, from Martin KaFai Lau. 8) Fix AF_XDP by using the correct number of channels from ethtool, from Luigi Rizzo. 9) Two fixes for BPF selftest to get rid of a hang in test_tc_tunnel and to avoid xdping to be run as standalone, from Jiri Benc. 10) Various BPF selftest fixes when run with latest LLVM trunk, from Yonghong Song. 11) Fix a memory leak in BPF fentry test run data, from Colin Ian King. 12) Various smaller misc cleanups and improvements mostly all over BPF selftests and samples, from Daniel T. Lee, Andre Guedes, Anders Roxell, Mao Wenan, Yue Haibing. ==================== Signed-off-by: David S. Miller + Changed Files: nan + Parent Hashes: e2193c9334291ecdc437cdbd9fe9ac35c14fffa8 196e8ca74886c433dcfc64a809707074b936aaf5 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges various BPF updates including new features, bug fixes, and performance optimizations from the bpf-next branch into the net-next tree.", + "keywords": "BPF,merge,updates", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges various BPF updates including new features, bug fixes, and performance optimizations from the bpf-next branch into the net-next tree.", + "keywords": "BPF,merge,updates", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's likely a merge commit. It involves changes across multiple use cases or events." + ] +} +-------------------- +-------------------- +Processing Commit 1007/6895 - Commit ID: 196e8ca74886c433dcfc64a809707074b936aaf5 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 196e8ca74886c433dcfc64a809707074b936aaf5 + Author Name: Daniel Borkmann + Author Email: daniel@iogearbox.net + Commit Date: 1574288338 + Commit Message: + bpf: Switch bpf_map_{area_alloc,area_mmapable_alloc}() to u64 size Given we recently extended the original bpf_map_area_alloc() helper in commit fc9702273e2e ("bpf: Add mmap() support for BPF_MAP_TYPE_ARRAY"), we need to apply the same logic as in ff1c08e1f74b ("bpf: Change size to u64 for bpf_map_{area_alloc, charge_init}()"). To avoid conflicts, extend it for bpf-next. Reported-by: Stephen Rothwell Signed-off-by: Daniel Borkmann + Changed Files: include/linux/bpf.h | 6 +++---; kernel/bpf/syscall.c | 11 +++++++----; 2 files changed, 10 insertions(+), 7 deletions(-) + Parent Hashes: 91e6015b082b08a74e5d9d326f651e5890a93519 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit updates bpf_map area allocation functions to use u64 size to avoid conflicts with recent extensions.", + "keywords": "bpf_map, u64, allocation", + "commit_classification": "I'm not sure about the type of the commit. The nature of It is unclear or uncertain.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The syscall interface. It changes the system calls through which user-space programs interact with eBPF.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime.", + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here.", + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +Rethinking... +new content: +{ + "summary": "The commit modifies bpf_map allocation functions to use u64 for size to extend mmap support.", + "keywords": "bpf_map, u64, mmap", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The syscall interface. It changes the system calls through which user-space programs interact with eBPF.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 1008/6895 - Commit ID: 91e6015b082b08a74e5d9d326f651e5890a93519 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 91e6015b082b08a74e5d9d326f651e5890a93519 + Author Name: Daniel Borkmann + Author Email: daniel@iogearbox.net + Commit Date: 1574286291 + Commit Message: + bpf: Emit audit messages upon successful prog load and unload Allow for audit messages to be emitted upon BPF program load and unload for having a timeline of events. The load itself is in syscall context, so additional info about the process initiating the BPF prog creation can be logged and later directly correlated to the unload event. The only info really needed from BPF side is the globally unique prog ID where then audit user space tooling can query / dump all info needed about the specific BPF program right upon load event and enrich the record, thus these changes needed here can be kept small and non-intrusive to the core. Raw example output: # auditctl -D # auditctl -a always,exit -F arch=x86_64 -S bpf # ausearch --start recent -m 1334 [...] ---- time->Wed Nov 20 12:45:51 2019 type=PROCTITLE msg=audit(1574271951.590:8974): proctitle="./test_verifier" type=SYSCALL msg=audit(1574271951.590:8974): arch=c000003e syscall=321 success=yes exit=14 a0=5 a1=7ffe2d923e80 a2=78 a3=0 items=0 ppid=742 pid=949 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="test_verifier" exe="/root/bpf-next/tools/testing/selftests/bpf/test_verifier" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) type=UNKNOWN[1334] msg=audit(1574271951.590:8974): auid=0 uid=0 gid=0 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=949 comm="test_verifier" exe="/root/bpf-next/tools/testing/selftests/bpf/test_verifier" prog-id=3260 event=LOAD ---- time->Wed Nov 20 12:45:51 2019 type=UNKNOWN[1334] msg=audit(1574271951.590:8975): prog-id=3260 event=UNLOAD ---- [...] Signed-off-by: Daniel Borkmann Signed-off-by: Jiri Olsa Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191120213816.8186-1-jolsa@kernel.org + Changed Files: include/linux/audit.h | 3 +++; include/uapi/linux/audit.h | 1 +; kernel/auditsc.c | 2 +-; kernel/bpf/syscall.c | 31 +++++++++++++++++++++++++++++++; 4 files changed, 36 insertions(+), 1 deletion(-) + Parent Hashes: b2e2f0e6a6f910c906c083584b6e0afd12266f22 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Introduces audit messages for eBPF program load and unload to track events.", + "keywords": "audit,bpf,syscall", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The syscall interface. It changes the system calls through which user-space programs interact with eBPF.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Adds audit message support for eBPF program load and unload to track process events.", + "keywords": "audit,prog,load", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The syscall interface. It changes the system calls through which user-space programs interact with eBPF.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 1009/6895 - Commit ID: b2e2f0e6a6f910c906c083584b6e0afd12266f22 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: b2e2f0e6a6f910c906c083584b6e0afd12266f22 + Author Name: YueHaibing + Author Email: yuehaibing@huawei.com + Commit Date: 1574211452 + Commit Message: + bpf: Make array_map_mmap static Fix sparse warning: kernel/bpf/arraymap.c:481:5: warning: symbol 'array_map_mmap' was not declared. Should it be static? Reported-by: Hulk Robot Signed-off-by: YueHaibing Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20191119142113.15388-1-yuehaibing@huawei.com + Changed Files: kernel/bpf/arraymap.c | 2 +-; 1 file changed, 1 insertion(+), 1 deletion(-) + Parent Hashes: 24f65050276a4f82d5832e974dabfb5be5c07c39 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit makes the function array_map_mmap static to fix a sparse warning in the kernel.", + "keywords": "static,array_map_mmap,sparse", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit marks array_map_mmap as static to correct a visibility warning in the kernel BPF module.", + "keywords": "static,array_map,sparse", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 1010/6895 - Commit ID: 24f65050276a4f82d5832e974dabfb5be5c07c39 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 24f65050276a4f82d5832e974dabfb5be5c07c39 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1574211202 + Commit Message: + selftests/bpf: Enforce no-ALU32 for test_progs-no_alu32 With the most recent Clang, alu32 is enabled by default if -mcpu=probe or -mcpu=v3 is specified. Use a separate build rule with -mcpu=v2 to enforce no ALU32 mode. Suggested-by: Yonghong Song Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20191120002510.4130605-1-andriin@fb.com + Changed Files: tools/testing/selftests/bpf/Makefile | 7 +++++++; 1 file changed, 7 insertions(+) + Parent Hashes: a0d7da26ce86a25e97ae191cb90574ada6daea98 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit enforces no-ALU32 mode for test cases by modifying build rules with -mcpu=v2 in the Makefile.", + "keywords": "no-ALU32, Makefile, test_progs", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit enforces no-ALU32 mode for test cases by modifying build rules with -mcpu=v2 in the Makefile.", + "keywords": "no-ALU32, Makefile, test_progs", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 1011/6895 - Commit ID: d4ffb02dee2fcb20e0c8086a8d1305bf885820bb +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: d4ffb02dee2fcb20e0c8086a8d1305bf885820bb + Author Name: Willem de Bruijn + Author Email: willemb@google.com + Commit Date: 1574204582 + Commit Message: + net/tls: enable sk_msg redirect to tls socket egress Bring back tls_sw_sendpage_locked. sk_msg redirection into a socket with TLS_TX takes the following path: tcp_bpf_sendmsg_redir tcp_bpf_push_locked tcp_bpf_push kernel_sendpage_locked sock->ops->sendpage_locked Also update the flags test in tls_sw_sendpage_locked to allow flag MSG_NO_SHARED_FRAGS. bpf_tcp_sendmsg sets this. Link: https://lore.kernel.org/netdev/CA+FuTSdaAawmZ2N8nfDDKu3XLpXBbMtcCT0q4FntDD2gn8ASUw@mail.gmail.com/T/#t Link: https://github.com/wdebruij/kerneltools/commits/icept.2 Fixes: 0608c69c9a80 ("bpf: sk_msg, sock{map|hash} redirect through ULP") Fixes: f3de19af0f5b ("Revert \"net/tls: remove unused function tls_sw_sendpage_locked\"") Signed-off-by: Willem de Bruijn Acked-by: John Fastabend Signed-off-by: David S. Miller + Changed Files: include/net/tls.h | 2 ++; net/tls/tls_main.c | 1 +; net/tls/tls_sw.c | 11 +++++++++++; 3 files changed, 14 insertions(+) + Parent Hashes: db96c2cb4870173ea9b08df130f1d1cc9b5dd53d +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit enables sk_msg redirect to TLS socket egress and updates flags tests for tls_sw_sendpage_locked.", + "keywords": "sk_msg,TLS,redirect", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +Rethinking... +new content: +{ + "summary": "The commit allows sk_msg redirection to TLS socket egress and updates functionality for tls_sw_sendpage_locked.", + "keywords": "TLS,socket,redirection", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "It's not related to any above. It affects an implementation component not listed but does related to the BPF subsystem.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "Socket related type programs. It relates to programs that process socket-level events such as filtering or manipulating socket traffic.", + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +-------------------- +-------------------- +Processing Commit 1012/6895 - Commit ID: a0d7da26ce86a25e97ae191cb90574ada6daea98 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: a0d7da26ce86a25e97ae191cb90574ada6daea98 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1574204412 + Commit Message: + libbpf: Fix call relocation offset calculation bug When relocating subprogram call, libbpf doesn't take into account relo->text_off, which comes from symbol's value. This generally works fine for subprograms implemented as static functions, but breaks for global functions. Taking a simplified test_pkt_access.c as an example: __attribute__ ((noinline)) static int test_pkt_access_subprog1(volatile struct __sk_buff *skb) { return skb->len * 2; } __attribute__ ((noinline)) static int test_pkt_access_subprog2(int val, volatile struct __sk_buff *skb) { return skb->len + val; } SEC("classifier/test_pkt_access") int test_pkt_access(struct __sk_buff *skb) { if (test_pkt_access_subprog1(skb) != skb->len * 2) return TC_ACT_SHOT; if (test_pkt_access_subprog2(2, skb) != skb->len + 2) return TC_ACT_SHOT; return TC_ACT_UNSPEC; } When compiled, we get two relocations, pointing to '.text' symbol. .text has st_value set to 0 (it points to the beginning of .text section): 0000000000000008 000000050000000a R_BPF_64_32 0000000000000000 .text 0000000000000040 000000050000000a R_BPF_64_32 0000000000000000 .text test_pkt_access_subprog1 and test_pkt_access_subprog2 offsets (targets of two calls) are encoded within call instruction's imm32 part as -1 and 2, respectively: 0000000000000000 test_pkt_access_subprog1: 0: 61 10 00 00 00 00 00 00 r0 = *(u32 *)(r1 + 0) 1: 64 00 00 00 01 00 00 00 w0 <<= 1 2: 95 00 00 00 00 00 00 00 exit 0000000000000018 test_pkt_access_subprog2: 3: 61 10 00 00 00 00 00 00 r0 = *(u32 *)(r1 + 0) 4: 04 00 00 00 02 00 00 00 w0 += 2 5: 95 00 00 00 00 00 00 00 exit 0000000000000000 test_pkt_access: 0: bf 16 00 00 00 00 00 00 r6 = r1 ===> 1: 85 10 00 00 ff ff ff ff call -1 2: bc 01 00 00 00 00 00 00 w1 = w0 3: b4 00 00 00 02 00 00 00 w0 = 2 4: 61 62 00 00 00 00 00 00 r2 = *(u32 *)(r6 + 0) 5: 64 02 00 00 01 00 00 00 w2 <<= 1 6: 5e 21 08 00 00 00 00 00 if w1 != w2 goto +8 7: bf 61 00 00 00 00 00 00 r1 = r6 ===> 8: 85 10 00 00 02 00 00 00 call 2 9: bc 01 00 00 00 00 00 00 w1 = w0 10: 61 62 00 00 00 00 00 00 r2 = *(u32 *)(r6 + 0) 11: 04 02 00 00 02 00 00 00 w2 += 2 12: b4 00 00 00 ff ff ff ff w0 = -1 13: 1e 21 01 00 00 00 00 00 if w1 == w2 goto +1 14: b4 00 00 00 02 00 00 00 w0 = 2 0000000000000078 LBB0_3: 15: 95 00 00 00 00 00 00 00 exit Now, if we compile example with global functions, the setup changes. Relocations are now against specifically test_pkt_access_subprog1 and test_pkt_access_subprog2 symbols, with test_pkt_access_subprog2 pointing 24 bytes into its respective section (.text), i.e., 3 instructions in: 0000000000000008 000000070000000a R_BPF_64_32 0000000000000000 test_pkt_access_subprog1 0000000000000048 000000080000000a R_BPF_64_32 0000000000000018 test_pkt_access_subprog2 Calls instructions now encode offsets relative to function symbols and are both set ot -1: 0000000000000000 test_pkt_access_subprog1: 0: 61 10 00 00 00 00 00 00 r0 = *(u32 *)(r1 + 0) 1: 64 00 00 00 01 00 00 00 w0 <<= 1 2: 95 00 00 00 00 00 00 00 exit 0000000000000018 test_pkt_access_subprog2: 3: 61 20 00 00 00 00 00 00 r0 = *(u32 *)(r2 + 0) 4: 0c 10 00 00 00 00 00 00 w0 += w1 5: 95 00 00 00 00 00 00 00 exit 0000000000000000 test_pkt_access: 0: bf 16 00 00 00 00 00 00 r6 = r1 ===> 1: 85 10 00 00 ff ff ff ff call -1 2: bc 01 00 00 00 00 00 00 w1 = w0 3: b4 00 00 00 02 00 00 00 w0 = 2 4: 61 62 00 00 00 00 00 00 r2 = *(u32 *)(r6 + 0) 5: 64 02 00 00 01 00 00 00 w2 <<= 1 6: 5e 21 09 00 00 00 00 00 if w1 != w2 goto +9 7: b4 01 00 00 02 00 00 00 w1 = 2 8: bf 62 00 00 00 00 00 00 r2 = r6 ===> 9: 85 10 00 00 ff ff ff ff call -1 10: bc 01 00 00 00 00 00 00 w1 = w0 11: 61 62 00 00 00 00 00 00 r2 = *(u32 *)(r6 + 0) 12: 04 02 00 00 02 00 00 00 w2 += 2 13: b4 00 00 00 ff ff ff ff w0 = -1 14: 1e 21 01 00 00 00 00 00 if w1 == w2 goto +1 15: b4 00 00 00 02 00 00 00 w0 = 2 0000000000000080 LBB2_3: 16: 95 00 00 00 00 00 00 00 exit Thus the right formula to calculate target call offset after relocation should take into account relocation's target symbol value (offset within section), call instruction's imm32 offset, and (subtracting, to get relative instruction offset) instruction index of call instruction itself. All that is shifted by number of instructions in main program, given all sub-programs are copied over after main program. Convert few selftests relying on bpf-to-bpf calls to use global functions instead of static ones. Fixes: 48cca7e44f9f ("libbpf: add support for bpf_call") Reported-by: Alexei Starovoitov Signed-off-by: Andrii Nakryiko Acked-by: Yonghong Song Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191119224447.3781271-1-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.c | 8 ++++++--; tools/testing/selftests/bpf/progs/test_btf_haskv.c | 4 ++--; tools/testing/selftests/bpf/progs/test_btf_newkv.c | 4 ++--; tools/testing/selftests/bpf/progs/test_btf_nokv.c | 4 ++--; 4 files changed, 12 insertions(+), 8 deletions(-) + Parent Hashes: 3de88c9113f88c04abda339f1aa629397bf89e02 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes a bug in libbpf's call relocation offset calculation for subprogram calls.", + "keywords": "libbpf,call,relocation", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes a bug in libbpf's call relocation offset calculation for global subprogram functions.", + "keywords": "libbpf,relocation,offset", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 1013/6895 - Commit ID: 3de88c9113f88c04abda339f1aa629397bf89e02 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 3de88c9113f88c04abda339f1aa629397bf89e02 + Author Name: Luigi Rizzo + Author Email: lrizzo@google.com + Commit Date: 1574201195 + Commit Message: + net-af_xdp: Use correct number of channels from ethtool Drivers use different fields to report the number of channels, so take the maximum of all data channels (rx, tx, combined) when determining the size of the xsk map. The current code used only 'combined' which was set to 0 in some drivers e.g. mlx4. Tested: compiled and run xdpsock -q 3 -r -S on mlx4 Signed-off-by: Luigi Rizzo Signed-off-by: Alexei Starovoitov Reviewed-by: Jakub Kicinski Acked-by: Magnus Karlsson Link: https://lore.kernel.org/bpf/20191119001951.92930-1-lrizzo@google.com + Changed Files: tools/lib/bpf/xsk.c | 11 ++++++++---; 1 file changed, 8 insertions(+), 3 deletions(-) + Parent Hashes: 0424c5a4dda5608a2910474e3e8f0fd8e7126f42 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit fixes the method for determining the number of channels for xsk maps in net-af_xdp by using the maximum of rx, tx, and combined fields.", + "keywords": "channels, xsk map, ethtool", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +Rethinking... +new content: +{ + "summary": "This commit fixes the method for determining the number of channels for xsk maps in net-af_xdp by using the maximum of rx, tx, and combined fields.", + "keywords": "channels, xsk map, ethtool", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "XDP related type programs. It relates to programs handling high-performance packet processing through the XDP framework." + ] +} +-------------------- +-------------------- +Processing Commit 1014/6895 - Commit ID: d1242b10ff03a40ae095e6dd54aac4a6f0f547d5 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: d1242b10ff03a40ae095e6dd54aac4a6f0f547d5 + Author Name: Ilya Leoshkevich + Author Email: iii@linux.ibm.com + Commit Date: 1574135476 + Commit Message: + s390/bpf: Remove JITed image size limitations Now that jump and long displacement ranges are no longer a problem, remove the limit on JITed image size. In practice it's still limited by 2G, but with verifier allowing "only" 1M instructions, it's not an issue. Signed-off-by: Ilya Leoshkevich Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191118180340.68373-7-iii@linux.ibm.com + Changed Files: arch/s390/net/bpf_jit_comp.c | 7 -------; 1 file changed, 7 deletions(-) + Parent Hashes: b25c57b6b7dda3799aaebc5f463776e4a0555927 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit removes image size limitation for JIT on s390 architecture.", + "keywords": "JIT,image,size", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit removes limitations on the JITed image size for s390 architecture in the eBPF subsystem.", + "keywords": "JIT,remove,limit", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 1015/6895 - Commit ID: b25c57b6b7dda3799aaebc5f463776e4a0555927 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: b25c57b6b7dda3799aaebc5f463776e4a0555927 + Author Name: Ilya Leoshkevich + Author Email: iii@linux.ibm.com + Commit Date: 1574135476 + Commit Message: + s390/bpf: Use lg(f)rl when long displacement cannot be used If literal pool grows past 524287 mark, it's no longer possible to use long displacement to reference literal pool entries. In JIT setting maintaining multiple literal pool registers is next to impossible, since we operate on one instruction at a time. Therefore, fall back to loading literal pool entry using PC-relative addressing, and then using a register-register form of the following machine instruction. Signed-off-by: Ilya Leoshkevich Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191118180340.68373-6-iii@linux.ibm.com + Changed Files: arch/s390/net/bpf_jit_comp.c | 96 +++++++++++++++++++++++++++++++++++++-------; 1 file changed, 81 insertions(+), 15 deletions(-) + Parent Hashes: 451e448ff4bb137da3d4b8b26a8260a2ff66869a +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit updates the s390 BPF JIT to handle long displacement limitations with PC-relative addressing.", + "keywords": "s390,JIT,displacement", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit addresses long displacement issues in s390 BPF JIT by using PC-relative addressing and register-register instructions.", + "keywords": "s390,BPF,JIT", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 1016/6895 - Commit ID: 451e448ff4bb137da3d4b8b26a8260a2ff66869a +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 451e448ff4bb137da3d4b8b26a8260a2ff66869a + Author Name: Ilya Leoshkevich + Author Email: iii@linux.ibm.com + Commit Date: 1574135476 + Commit Message: + s390/bpf: Use lgrl instead of lg where possible lg and lgrl have the same performance characteristics, but the former requires a base register and is subject to long displacement range limits, while the latter does not. Therefore, lgrl is totally superior to lg and should be used instead whenever possible. Signed-off-by: Ilya Leoshkevich Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191118180340.68373-5-iii@linux.ibm.com + Changed Files: arch/s390/net/bpf_jit_comp.c | 32 ++++++++++++++++++++------------; 1 file changed, 20 insertions(+), 12 deletions(-) + Parent Hashes: c1aff5682da2977c26fc087cf6a28e31a430174b +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit optimizes the s390 BPF JIT by replacing lg with lgrl instructions.", + "keywords": "s390,JIT,optimization", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit optimizes s390 BPF JIT by using lgrl instructions instead of lg for better efficiency.", + "keywords": "s390,JIT,lgrl", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 1017/6895 - Commit ID: c1aff5682da2977c26fc087cf6a28e31a430174b +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: c1aff5682da2977c26fc087cf6a28e31a430174b + Author Name: Ilya Leoshkevich + Author Email: iii@linux.ibm.com + Commit Date: 1574135476 + Commit Message: + s390/bpf: Load literal pool register using larl Currently literal pool register is loaded using basr, which makes it point not to the beginning of the literal pool, but rather to the next instruction. In case JITed code is larger than 512k, this renders literal pool register absolutely useless due to long displacement range restrictions. The solution is to use larl to make literal pool register point to the very beginning of the literal pool. This makes it always possible to address 512k worth of literal pool entries using long displacement. However, for short programs, in which the entire literal pool is covered by basr-generated base, it is still beneficial to use basr, since it is 4 bytes shorter than larl. Detect situations when basr-generated base does not cover the entire literal pool, and in such cases use larl instead. Signed-off-by: Ilya Leoshkevich Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191118180340.68373-4-iii@linux.ibm.com + Changed Files: arch/s390/net/bpf_jit_comp.c | 22 +++++++++++++++++++---; 1 file changed, 19 insertions(+), 3 deletions(-) + Parent Hashes: e0491f64795bfc71ef6b13ba6b6fa6e176fa3c23 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit improves the s390 BPF JIT compiler by changing how the literal pool register is loaded to optimize addressing with \"larl\" instead of \"basr\".", + "keywords": "s390,bpf,larl", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit changes the s390 BPF JIT to use 'larl' for literal pool addressing to handle larger JITed code.", + "keywords": "s390,BPF,JIT", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 1018/6895 - Commit ID: e0491f64795bfc71ef6b13ba6b6fa6e176fa3c23 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: e0491f64795bfc71ef6b13ba6b6fa6e176fa3c23 + Author Name: Ilya Leoshkevich + Author Email: iii@linux.ibm.com + Commit Date: 1574135476 + Commit Message: + s390/bpf: Align literal pool entries When literal pool size exceeds 512k, it's no longer possible to reference all the entries in it using a single base register and long displacement. Therefore, PC-relative lgfrl and lgrl instructions need to be used. Unfortunately, they require their arguments to be aligned to 4- and 8-byte boundaries respectively. This generates certain overhead due to necessary padding bytes. Grouping 4- and 8-byte entries together reduces the maximum overhead to 6 bytes (2 for aligning 4-byte entries and 4 for aligning 8-byte entries). While in theory it is possible to detect whether or not alignment is needed by comparing the literal pool size with 512k, in practice this leads to having two ways of emitting constants, making the code more complicated. Prefer code simplicity over trivial size saving, and always group and align literal pool entries. Signed-off-by: Ilya Leoshkevich Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191118180340.68373-3-iii@linux.ibm.com + Changed Files: arch/s390/net/bpf_jit_comp.c | 37 ++++++++++++++++++++++++-------------; 1 file changed, 24 insertions(+), 13 deletions(-) + Parent Hashes: 4e9b4a6883dd97aff53ae3b08eb900716a5469dc +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit improves literal pool alignment in the s390 BPF JIT compiler to simplify code structure.", + "keywords": "alignment,literal pool,s390", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here." + ] +} +Rethinking... +new content: +{ + "summary": "The commit improves literal pool alignment in the s390 BPF JIT compiler to simplify code structure.", + "keywords": "alignment,literal pool,s390", + "commit_classification": "A cleanup or refactoring in the code. It involves changes to improve code readability maintainability or structure without changing its functionality.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it's other type of use cases or BPF programs related to the BPF subsystem but not listed here." + ] +} +-------------------- +-------------------- +Processing Commit 1019/6895 - Commit ID: 4e9b4a6883dd97aff53ae3b08eb900716a5469dc +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 4e9b4a6883dd97aff53ae3b08eb900716a5469dc + Author Name: Ilya Leoshkevich + Author Email: iii@linux.ibm.com + Commit Date: 1574135476 + Commit Message: + s390/bpf: Use relative long branches Currently maximum JITed code size is limited to 64k, because JIT can emit only relative short branches, whose range is limited by 64k in both directions. Teach JIT to use relative long branches. There are no compare+branch relative long instructions, so using relative long branches consumes more space due to having to having to emit an explicit comparison instruction. Therefore do this only when relative short branch is not enough. Signed-off-by: Ilya Leoshkevich Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191118180340.68373-2-iii@linux.ibm.com + Changed Files: arch/s390/net/bpf_jit_comp.c | 158 ++++++++++++++++++++++++++++++++++---------; 1 file changed, 126 insertions(+), 32 deletions(-) + Parent Hashes: a25ecd9d1e60241df905b29fb84765eb74545c4f +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit modifies the JIT compiler on s390 to support relative long branches by using explicit comparison instructions when needed.", + "keywords": "s390,JIT,branches", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit extends the s390 JIT compiler to support longer branch instructions for handling larger code sizes.", + "keywords": "s390,JIT,long-branches", + "commit_classification": "A performance optimization. It improves the performance of existing code such as reducing latency or improving throughput.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The eBPF JIT compiler for different architectures. It changes how eBPF bytecode is translated into machine code for different hardware architectures.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 1020/6895 - Commit ID: a25ecd9d1e60241df905b29fb84765eb74545c4f +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: a25ecd9d1e60241df905b29fb84765eb74545c4f + Author Name: Colin Ian King + Author Email: colin.king@canonical.com + Commit Date: 1574134379 + Commit Message: + bpf: Fix memory leak on object 'data' The error return path on when bpf_fentry_test* tests fail does not kfree 'data'. Fix this by adding the missing kfree. Addresses-Coverity: ("Resource leak") Fixes: faeb2dce084a ("bpf: Add kernel test functions for fentry testing") Signed-off-by: Colin Ian King Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191118114059.37287-1-colin.king@canonical.com + Changed Files: net/bpf/test_run.c | 4 +++-; 1 file changed, 3 insertions(+), 1 deletion(-) + Parent Hashes: 2ea2612b987ad703235c92be21d4e98ee9c2c67c +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit fixes a memory leak in the bpf_fentry_test error path by adding a missing kfree for the 'data' object.", + "keywords": "memory, leak, kfree", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit fixes a memory leak in the bpf_fentry_test error path by adding a missing kfree for the 'data' object.", + "keywords": "memory, leak, kfree", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "Control Plane interface Logic. E.g. It modifies the interface through which user-space programs control or interact with eBPF in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 1021/6895 - Commit ID: 6960f7e3b2d77ebcb20d5cecdd74d7ca1ed425aa +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 6960f7e3b2d77ebcb20d5cecdd74d7ca1ed425aa + Author Name: David S. Miller + Author Email: davem@davemloft.net + Commit Date: 1574125398 + Commit Message: + Merge branch 'page_pool-followup-changes-to-restore-tracepoint-features' Jesper Dangaard says: ==================== page_pool: followup changes to restore tracepoint features This patchset is a followup to Jonathan patch, that do not release pool until inflight == 0. That changed page_pool to be responsible for its own delayed destruction instead of relying on xdp memory model. As the page_pool maintainer, I'm promoting the use of tracepoint to troubleshoot and help driver developers verify correctness when converting at driver to use page_pool. The role of xdp:mem_disconnect have changed, which broke my bpftrace tools for shutdown verification. With these changes, the same capabilities are regained. ==================== Signed-off-by: David S. Miller + Changed Files: nan + Parent Hashes: b95e86d846b63b02ecdc94802ddbeaf9005fb6d9 832ccf6f80cda06ad2373cd1f40291b0183958b4 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit merges changes to restore tracepoint features in page_pool, impacting bpftrace tools and driver debugging.", + "keywords": "tracepoint,page_pool,bpftrace", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing." + ] +} +Rethinking... +new content: +{ + "summary": "The commit merges changes to restore tracepoint features in page_pool, impacting bpftrace tools and driver debugging.", + "keywords": "tracepoint,page_pool,bpftrace", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "Tracepoints related type programs. It modifies programs that attach to tracepoints for low-level kernel event tracing." + ] +} +-------------------- +-------------------- +Processing Commit 1022/6895 - Commit ID: 2ea2612b987ad703235c92be21d4e98ee9c2c67c +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 2ea2612b987ad703235c92be21d4e98ee9c2c67c + Author Name: Yonghong Song + Author Email: yhs@fb.com + Commit Date: 1574109420 + Commit Message: + selftests, bpf: Workaround an alu32 sub-register spilling issue Currently, with latest llvm trunk, selftest test_progs failed obj file test_seg6_loop.o with the following error in verifier: infinite loop detected at insn 76 The byte code sequence looks like below, and noted that alu32 has been turned off by default for better generated codes in general: 48: w3 = 100 49: *(u32 *)(r10 - 68) = r3 ... ; if (tlv.type == SR6_TLV_PADDING) { 76: if w3 == 5 goto -18 ... 85: r1 = *(u32 *)(r10 - 68) ; for (int i = 0; i < 100; i++) { 86: w1 += -1 87: if w1 == 0 goto +5 88: *(u32 *)(r10 - 68) = r1 The main reason for verification failure is due to partial spills at r10 - 68 for induction variable "i". Current verifier only handles spills with 8-byte values. The above 4-byte value spill to stack is treated to STACK_MISC and its content is not saved. For the above example: w3 = 100 R3_w=inv100 fp-64_w=inv1086626730498 *(u32 *)(r10 - 68) = r3 R3_w=inv100 fp-64_w=inv1086626730498 ... r1 = *(u32 *)(r10 - 68) R1_w=inv(id=0,umax_value=4294967295,var_off=(0x0; 0xffffffff)) fp-64=inv1086626730498 To resolve this issue, verifier needs to be extended to track sub-registers in spilling, or llvm needs to enhanced to prevent sub-register spilling in register allocation phase. The former will increase verifier complexity and the latter will need some llvm "hacking". Let us workaround this issue by declaring the induction variable as "long" type so spilling will happen at non sub-register level. We can revisit this later if sub-register spilling causes similar or other verification issues. Signed-off-by: Yonghong Song Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20191117214036.1309510-1-yhs@fb.com + Changed Files: tools/testing/selftests/bpf/progs/test_seg6_loop.c | 4 +++-; 1 file changed, 3 insertions(+), 1 deletion(-) + Parent Hashes: 3b054b7133b4ad93671c82e8d6185258e3f1a7a5 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit provides a workaround for a sub-register spilling issue in eBPF selftests due to verifier limitations.", + "keywords": "workaround, spilling, selftests", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit provides a workaround for a verifier issue in eBPF selftests related to sub-register spilling.", + "keywords": "workaround, sub-register, eBPF", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "A eBPF Instruction Logic. E.g. It changes how eBPF instructions are interpreted validated or executed by the eBPF virtual machine in the kernel.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 1023/6895 - Commit ID: 3b054b7133b4ad93671c82e8d6185258e3f1a7a5 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 3b054b7133b4ad93671c82e8d6185258e3f1a7a5 + Author Name: Jiri Benc + Author Email: jbenc@redhat.com + Commit Date: 1574109109 + Commit Message: + selftests, bpf: Fix test_tc_tunnel hanging When run_kselftests.sh is run, it hangs after test_tc_tunnel.sh. The reason is test_tc_tunnel.sh ensures the server ('nc -l') is run all the time, starting it again every time it is expected to terminate. The exception is the final client_connect: the server is not started anymore, which ensures no process is kept running after the test is finished. For a sit test, though, the script is terminated prematurely without the final client_connect and the 'nc' process keeps running. This in turn causes the run_one function in kselftest/runner.sh to hang forever, waiting for the runaway process to finish. Ensure a remaining server is terminated on cleanup. Fixes: f6ad6accaa99 ("selftests/bpf: expand test_tc_tunnel with SIT encap") Signed-off-by: Jiri Benc Signed-off-by: Daniel Borkmann Acked-by: Willem de Bruijn Link: https://lore.kernel.org/bpf/60919291657a9ee89c708d8aababc28ebe1420be.1573821780.git.jbenc@redhat.com + Changed Files: tools/testing/selftests/bpf/test_tc_tunnel.sh | 5 +++++; 1 file changed, 5 insertions(+) + Parent Hashes: 56bf877a508099f16fb78c71a348f39d0dc5fd72 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Fixes a hanging issue in test_tc_tunnel.sh by ensuring server termination on cleanup during selftest execution.", + "keywords": "selftests, fix, cleanup", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Fixes a hanging issue in test_tc_tunnel.sh by ensuring server termination on cleanup during selftest execution.", + "keywords": "selftests, fix, cleanup", + "commit_classification": "A bug fix. It primarily resolves a bug or issue in the code.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 1024/6895 - Commit ID: 56bf877a508099f16fb78c71a348f39d0dc5fd72 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 56bf877a508099f16fb78c71a348f39d0dc5fd72 + Author Name: Jiri Benc + Author Email: jbenc@redhat.com + Commit Date: 1574109105 + Commit Message: + selftests, bpf: xdping is not meant to be run standalone The actual test to run is test_xdping.sh, which is already in TEST_PROGS. The xdping program alone is not runnable with 'make run_tests', it immediatelly fails due to missing arguments. Move xdping to TEST_GEN_PROGS_EXTENDED in order to be built but not run. Fixes: cd5385029f1d ("selftests/bpf: measure RTT from xdp using xdping") Signed-off-by: Jiri Benc Signed-off-by: Daniel Borkmann Reviewed-by: Alan Maguire Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/4365c81198f62521344c2215909634407184387e.1573821726.git.jbenc@redhat.com + Changed Files: tools/testing/selftests/bpf/Makefile | 4 ++--; 1 file changed, 2 insertions(+), 2 deletions(-) + Parent Hashes: b97e12e594eb3d0fba35c99a83fef56ff692048b +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adjusts xdping in the BPF selftests to be built but not run standalone by moving it to TEST_GEN_PROGS_EXTENDED.", + "keywords": "selftests, xdping, Makefile", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "The commit adjusts xdping in the BPF selftests to be built but not run standalone by moving it to TEST_GEN_PROGS_EXTENDED.", + "keywords": "selftests, xdping, Makefile", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "The general utilities Logic. E.g. It modifies the tools scripts or code used for building testing config or debugging eBPF.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 1025/6895 - Commit ID: b97e12e594eb3d0fba35c99a83fef56ff692048b +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: b97e12e594eb3d0fba35c99a83fef56ff692048b + Author Name: Daniel Borkmann + Author Email: daniel@iogearbox.net + Commit Date: 1574073731 + Commit Message: + Merge branch 'bpf-array-mmap' Andrii Nakryiko says: ==================== This patch set adds ability to memory-map BPF array maps (single- and multi-element). The primary use case is memory-mapping BPF array maps, created to back global data variables, created by libbpf implicitly. This allows for much better usability, along with avoiding syscalls to read or update data completely. Due to memory-mapping requirements, BPF array map that is supposed to be memory-mapped, has to be created with special BPF_F_MMAPABLE attribute, which triggers slightly different memory allocation strategy internally. See patch 1 for details. Libbpf is extended to detect kernel support for this flag, and if supported, will specify it for all global data maps automatically. Patch #1 refactors bpf_map_inc() and converts bpf_map's refcnt to atomic64_t to make refcounting never fail. Patch #2 does similar refactoring for bpf_prog_add()/bpf_prog_inc(). v5->v6: - add back uref counting (Daniel); v4->v5: - change bpf_prog's refcnt to atomic64_t (Daniel); v3->v4: - add mmap's open() callback to fix refcounting (Johannes); - switch to remap_vmalloc_pages() instead of custom fault handler (Johannes); - converted bpf_map's refcnt/usercnt into atomic64_t; - provide default bpf_map_default_vmops handling open/close properly; v2->v3: - change allocation strategy to avoid extra pointer dereference (Jakub); v1->v2: - fix map lookup code generation for BPF_F_MMAPABLE case; - prevent BPF_F_MMAPABLE flag for all but plain array map type; - centralize ref-counting in generic bpf_map_mmap(); - don't use uref counting (Alexei); - use vfree() directly; - print flags with %x (Song); - extend tests to verify bpf_map_{lookup,update}_elem() logic as well. ==================== Signed-off-by: Daniel Borkmann + Changed Files: nan + Parent Hashes: 2893c996d8ae021611d02906b9e6fcd0c765fba4 5051b384523be92925d13694fabbc6bedf2f907b +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit merges a branch to add memory-mapping capability to BPF array maps for better usability and performance.", + "keywords": "BPF mmap array", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "It's like a merge commit. It includes significant changes across multiple components of the system.", + "major_related_logic_component": "It's likely a merge commit. E.g. It involves changes across multiple logic components or is related to merging branches.", + "usecases_or_submodule_events": [ + "It's not related to any above because it totally not related to the BPF subsystem. The affected componenet and message has no interaction with BPF subsystem at all. It's a rare case wrong data and need removed." + ] +} +Rethinking... +new content: +{ + "summary": "This commit merges changes to support memory-mapping of BPF array maps enhancing performance and usability.", + "keywords": "memory-map BPF array", + "commit_classification": "It's like a merge commit. It merges changes from another branch or repository.", + "commit_complexity": "Merge-like. The commit merges multiple branches or contains changes that affect various features or components. making it broader than a typical feature or bug fix.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 1026/6895 - Commit ID: 5051b384523be92925d13694fabbc6bedf2f907b +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 5051b384523be92925d13694fabbc6bedf2f907b + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1574073720 + Commit Message: + selftests/bpf: Add BPF_TYPE_MAP_ARRAY mmap() tests Add selftests validating mmap()-ing BPF array maps: both single-element and multi-element ones. Check that plain bpf_map_update_elem() and bpf_map_lookup_elem() work correctly with memory-mapped array. Also convert CO-RE relocation tests to use memory-mapped views of global data. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20191117172806.2195367-6-andriin@fb.com + Changed Files: .../testing/selftests/bpf/prog_tests/core_reloc.c | 45 +++--; tools/testing/selftests/bpf/prog_tests/mmap.c | 220 +++++++++++++++++++++; tools/testing/selftests/bpf/progs/test_mmap.c | 45 +++++; 3 files changed, 292 insertions(+), 18 deletions(-) + Parent Hashes: 7fe74b436236b17ac57e46527166d22bcc230175 +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "Add self-tests for mmap functionality in BPF array maps with single and multi-element validation.", + "keywords": "selftests,BPF,array", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "Add self-tests for mmap functionality in BPF array maps with validation for single and multi-element usage.", + "keywords": "selftests,BPF,mmap", + "commit_classification": "A test case or test infrastructure change. It adds or modifies test cases test scripts or testing infrastructure.", + "commit_complexity": "Moderate. Affects 21-100 lines or across a few files (up to 3-4). Involves adding or modifying features or making structural changes that require some system knowledge.", + "major_related_implementation_component": "The test cases and makefiles. It adds or modifies test cases or makefile scripts used for testing or building eBPF programs.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 1027/6895 - Commit ID: 7fe74b436236b17ac57e46527166d22bcc230175 +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: 7fe74b436236b17ac57e46527166d22bcc230175 + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1574073719 + Commit Message: + libbpf: Make global data internal arrays mmap()-able, if possible Add detection of BPF_F_MMAPABLE flag support for arrays and add it as an extra flag to internal global data maps, if supported by kernel. This allows users to memory-map global data and use it without BPF map operations, greatly simplifying user experience. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Song Liu Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20191117172806.2195367-5-andriin@fb.com + Changed Files: tools/lib/bpf/libbpf.c | 32 ++++++++++++++++++++++++++++++--; 1 file changed, 30 insertions(+), 2 deletions(-) + Parent Hashes: fc9702273e2edb90400a34b3be76f7b08fa3344b +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "This commit adds support for mmap()-able global data arrays in libbpf by detecting and using the BPF_F_MMAPABLE flag when supported by the kernel.", + "keywords": "global,data,mmap", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: +{ + "summary": "This commit adds support for mmap()-able global data arrays in libbpf by detecting and using the BPF_F_MMAPABLE flag when supported by the kernel.", + "keywords": "global,data,mmap", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Simple. Affects 1-20 lines or across 1-2 files. Typically involves minor bug fixes or small refactoring tasks. requiring minimal configuration or understanding of the system.", + "major_related_implementation_component": "The libbpf library. It affects the library that simplifies interaction with eBPF from user-space applications.", + "major_related_logic_component": "Runtime features Logic. E.g. It modifies how runtime features such as helpers kfuncs interact with kernel component or the runtime configurations.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +-------------------- +-------------------- +Processing Commit 1028/6895 - Commit ID: fc9702273e2edb90400a34b3be76f7b08fa3344b +Survey Title: Commit Classification Survey + + +Description: A survey about the commit in Linux eBPF, to help better understand the design and evolution of bpf subsystem. For choice, try to be as specific as possible based on the commit message and code changes. If the commit message is not clear or does not provide enough information, you can choose the 'I'm not sure' option. + +Commit Details: + Commit ID: fc9702273e2edb90400a34b3be76f7b08fa3344b + Author Name: Andrii Nakryiko + Author Email: andriin@fb.com + Commit Date: 1574073719 + Commit Message: + bpf: Add mmap() support for BPF_MAP_TYPE_ARRAY Add ability to memory-map contents of BPF array map. This is extremely useful for working with BPF global data from userspace programs. It allows to avoid typical bpf_map_{lookup,update}_elem operations, improving both performance and usability. There had to be special considerations for map freezing, to avoid having writable memory view into a frozen map. To solve this issue, map freezing and mmap-ing is happening under mutex now: - if map is already frozen, no writable mapping is allowed; - if map has writable memory mappings active (accounted in map->writecnt), map freezing will keep failing with -EBUSY; - once number of writable memory mappings drops to zero, map freezing can be performed again. Only non-per-CPU plain arrays are supported right now. Maps with spinlocks can't be memory mapped either. For BPF_F_MMAPABLE array, memory allocation has to be done through vmalloc() to be mmap()'able. We also need to make sure that array data memory is page-sized and page-aligned, so we over-allocate memory in such a way that struct bpf_array is at the end of a single page of memory with array->value being aligned with the start of the second page. On deallocation we need to accomodate this memory arrangement to free vmalloc()'ed memory correctly. One important consideration regarding how memory-mapping subsystem functions. Memory-mapping subsystem provides few optional callbacks, among them open() and close(). close() is called for each memory region that is unmapped, so that users can decrease their reference counters and free up resources, if necessary. open() is *almost* symmetrical: it's called for each memory region that is being mapped, **except** the very first one. So bpf_map_mmap does initial refcnt bump, while open() will do any extra ones after that. Thus number of close() calls is equal to number of open() calls plus one more. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Song Liu Acked-by: John Fastabend Acked-by: Johannes Weiner Link: https://lore.kernel.org/bpf/20191117172806.2195367-4-andriin@fb.com + Changed Files: include/linux/bpf.h | 11 +++--; include/linux/vmalloc.h | 1 +; include/uapi/linux/bpf.h | 3 ++; kernel/bpf/arraymap.c | 58 ++++++++++++++++++++++---; kernel/bpf/syscall.c | 99 ++++++++++++++++++++++++++++++++++++++++--; mm/vmalloc.c | 20 +++++++++; tools/include/uapi/linux/bpf.h | 3 ++; 7 files changed, 183 insertions(+), 12 deletions(-) + Parent Hashes: 85192dbf4de08795afe2b88e52a36fc6abfc3dba +- Please provide a summary of It in one short sentence not longer than 30 words. Only output one sentence. + +- Please extract no more than 3 keywords from the commit. Only output 3 keywords without any special characters. + +- What may be the main type of the commit? + +- What is the estimated complexity of implementing this commit considering file and line changes? Note that complexity is most about the impact of the changes. line changes is just a reference. + +- What major implementation component is modified by the commit? It's typically where the code changes happened. + +- What major logic component is affected by the commit? Logic component is different from implementation component. it's typically related to the feature. For example a instruction logic change may affect JIT and verifier. + +- What major eBPF use cases events or hooks in other subsystems may the commit relate to and be designed for? Note a lot of the commits happend in other subsystems. e.g. perf event. networks. scheduler. But it's still related to how eBPF programs interact with these events. You need to think and seleted the right use cases or events related to the commit, if not applied, seleted + +old content: +{ + "summary": "The commit adds mmap() support to BPF_MAP_TYPE_ARRAY for improved performance and usability when working with global data from userspace programs.", + "keywords": "mmap, BPF_ARRAY, usability", + "commit_classification": "A new feature. It adds a new capability or feature that was not previously present.", + "commit_complexity": "Complex. Affects more than 100 lines or across 5 or more files. Involves significant changes such as adding new subsystems or refactoring core components requiring deep system knowledge.", + "major_related_implementation_component": "The eBPF maps. It changes how data structures shared between user-space and kernel-space (maps) are created or managed.", + "major_related_logic_component": "Maps Logic. E.g. It changes how eBPF maps are created accessed or managed by both user-space and kernel-space.", + "usecases_or_submodule_events": [ + "It's not related to any above because it improves the overall eBPF infrastructure. It enhances core infrastructure components like the verifier btf or runtime." + ] +} +Rethinking... +new content: