user/sven/linux.git/samples, branch v5.4.38

vmalloc: fix remap_vmalloc_range() bounds checks

2020-04-29T14:33:14Z

commit bdebd6a2831b6fab69eb85cee74a8ba77f1a1cc2 upstream. remap_vmalloc_range() has had various issues with the bounds checks it promises to perform ("This function checks that addr is a valid vmalloc'ed area, and that it is big enough to cover the vma") over time, e.g.: - not detecting pgoff< Signed-off-by: Andrew Morton Cc: stable@vger.kernel.org Cc: Alexei Starovoitov Cc: Daniel Borkmann Cc: Martin KaFai Lau Cc: Song Liu Cc: Yonghong Song Cc: Andrii Nakryiko Cc: John Fastabend Cc: KP Singh Link: http://lkml.kernel.org/r/20200415222312.236431-1-jannh@google.com Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

samples/bpf: Set -fno-stack-protector when building BPF programs

2020-02-24T07:36:36Z

[ Upstream commit 450278977acbf494a20367c22fbb38729772d1fc ] 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 Signed-off-by: Sasha Levin

samples/bpf: Xdp_redirect_cpu fix missing tracepoint attach

2020-02-11T12:35:29Z

commit f9e6bfdbaf0cf304d72c70a05d81acac01a04f48 upstream. 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 Signed-off-by: Greg Kroah-Hartman

samples/bpf: Don't try to remove user's homedir on clean

2020-02-11T12:35:29Z

commit b2e5e93ae8af6a34bca536cdc4b453ab1e707b8b upstream. 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 Signed-off-by: Greg Kroah-Hartman

samples/bpf: Fix broken xdp_rxq_info due to map order assumptions

2020-01-26T09:00:58Z

commit edbca120a8cdfa5a5793707e33497aa5185875ca upstream. 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 Signed-off-by: Greg Kroah-Hartman

samples: bpf: update map definition to new syntax BTF-defined map

2020-01-26T09:00:58Z

commit 451d1dc886b548d6e18c933adca326c1307023c9 upstream. Since, the new syntax of BTF-defined map has been introduced, the syntax for using maps under samples directory are mixed up. For example, some are already using the new syntax, and some are using existing syntax by calling them as 'legacy'. As stated at commit abd29c931459 ("libbpf: allow specifying map definitions using BTF"), the BTF-defined map has more compatablility with extending supported map definition features. The commit doesn't replace all of the map to new BTF-defined map, because some of the samples still use bpf_load instead of libbpf, which can't properly create BTF-defined map. This will only updates the samples which uses libbpf API for loading bpf program. (ex. bpf_prog_load_xattr) Signed-off-by: Daniel T. Lee Acked-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman

samples: bpf: fix syscall_tp due to unused syscall

2020-01-12T11:21:26Z

[ Upstream commit fe3300897cbfd76c6cb825776e5ac0ca50a91ca4 ] 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 Signed-off-by: Sasha Levin

samples: bpf: Replace symbol compare of trace_event

2020-01-12T11:21:26Z

[ Upstream commit bba1b2a890253528c45aa66cf856f289a215bfbc ] 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 Signed-off-by: Sasha Levin

samples/trace_printk: Wait for IRQ work to finish

2020-01-09T09:20:00Z

commit 01f36a554e3ef32f9fc4b81a4437cf08fd0e4742 upstream. trace_printk schedules work via irq_work_queue(), but doesn't wait until it was processed. The kprobe_module.tc testcase does: :;: "Load module again, which means the event1 should be recorded";: modprobe trace-printk grep "event1:" trace so the grep which checks the trace file might run before the irq work was processed. Fix this by adding a irq_work_sync(). Link: http://lore.kernel.org/linux-trace-devel/20191218074427.96184-3-svens@linux.ibm.com Cc: stable@vger.kernel.org Fixes: af2a0750f3749 ("selftests/ftrace: Improve kprobe on module testcase to load/unload module") Signed-off-by: Sven Schnelle Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman

samples/seccomp: Zero out members based on seccomp_notif_sizes

2020-01-09T09:19:57Z

commit 771b894f2f3dfedc2ba5561731fffa0e39b1bbb6 upstream. The sizes by which seccomp_notif and seccomp_notif_resp are allocated are based on the SECCOMP_GET_NOTIF_SIZES ioctl. This allows for graceful extension of these datastructures. If userspace zeroes out the datastructure based on its version, and it is lagging behind the kernel's version, it will end up sending trailing garbage. On the other hand, if it is ahead of the kernel version, it will write extra zero space, and potentially cause corruption. Signed-off-by: Sargun Dhillon Suggested-by: Tycho Andersen Link: https://lore.kernel.org/r/20191230203503.4925-1-sargun@sargun.me Fixes: fec7b6690541 ("samples: add an example of seccomp user trap") Cc: stable@vger.kernel.org Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman