user/sven/linux.git, branch v5.6.14

Linux 5.6.14

2020-05-20T06:22:38Z

Makefile: disallow data races on gcc-10 as well

2020-05-20T06:22:38Z

commit b1112139a103b4b1101d0d2d72931f2d33d8c978 upstream. gcc-10 will rename --param=allow-store-data-races=0 to -fno-allow-store-data-races. The flag change happened at https://gcc.gnu.org/PR92046. Signed-off-by: Sergei Trofimovich Acked-by: Jiri Kosina Signed-off-by: Masahiro Yamada Cc: Thomas Backlund Signed-off-by: Greg Kroah-Hartman

bpf: Restrict bpf_trace_printk()'s %s usage and add %pks, %pus specifier

2020-05-20T06:22:38Z

commit b2a5212fb634561bb734c6356904e37f6665b955 upstream. Usage of plain %s conversion specifier in bpf_trace_printk() suffers from the very same issue as bpf_probe_read{,str}() helpers, that is, it is broken on archs with overlapping address ranges. While the helpers have been addressed through work in 6ae08ae3dea2 ("bpf: Add probe_read_{user, kernel} and probe_read_{user, kernel}_str helpers"), we need an option for bpf_trace_printk() as well to fix it. Similarly as with the helpers, force users to make an explicit choice by adding %pks and %pus specifier to bpf_trace_printk() which will then pick the corresponding strncpy_from_unsafe*() variant to perform the access under KERNEL_DS or USER_DS. The %pk* (kernel specifier) and %pu* (user specifier) can later also be extended for other objects aside strings that are probed and printed under tracing, and reused out of other facilities like bpf_seq_printf() or BTF based type printing. Existing behavior of %s for current users is still kept working for archs where it is not broken and therefore gated through CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE. For archs not having this property we fall-back to pick probing under KERNEL_DS as a sensible default. Fixes: 8d3b7dce8622 ("bpf: add support for %s specifier to bpf_trace_printk()") Reported-by: Linus Torvalds Reported-by: Christoph Hellwig Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Cc: Masami Hiramatsu Cc: Brendan Gregg Link: https://lore.kernel.org/bpf/20200515101118.6508-4-daniel@iogearbox.net Signed-off-by: Greg Kroah-Hartman

selftests/bpf: Enforce returning 0 for fentry/fexit programs

2020-05-20T06:22:38Z

commit 6d74f64b922b8394dccc52576659cb0dc0a1da7b upstream. There are a few fentry/fexit programs returning non-0. The tests with these programs will break with the previous patch which enfoced return-0 rules. Fix them properly. Fixes: ac065870d928 ("selftests/bpf: Add BPF_PROG, BPF_KPROBE, and BPF_KRETPROBE macros") Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200514053207.1298479-1-yhs@fb.com Signed-off-by: Greg Kroah-Hartman

bpf: Enforce returning 0 for fentry/fexit progs

2020-05-20T06:22:38Z

commit e92888c72fbdc6f9d07b3b0604c012e81d7c0da7 upstream. Currently, tracing/fentry and tracing/fexit prog return values are not enforced. In trampoline codes, the fentry/fexit prog return values are ignored. Let us enforce it to be 0 to avoid confusion and allows potential future extension. This patch also explicitly added return value checking for tracing/raw_tp, tracing/fmod_ret, and freplace programs such that these program return values can be anything. The purpose are two folds: 1. to make it explicit about return value expectations for these programs in verifier. 2. for tracing prog_type, if a future attach type is added, the default is -ENOTSUPP which will enforce to specify return value ranges explicitly. Fixes: fec56f5890d9 ("bpf: Introduce BPF trampoline") Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200514053206.1298415-1-yhs@fb.com Signed-off-by: Greg Kroah-Hartman

KVM: x86: Fix off-by-one error in kvm_vcpu_ioctl_x86_setup_mce

2020-05-20T06:22:37Z

commit c4e0e4ab4cf3ec2b3f0b628ead108d677644ebd9 upstream. Bank_num is a one-based count of banks, not a zero-based index. It overflows the allocated space only when strictly greater than KVM_MAX_MCE_BANKS. Fixes: a9e38c3e01ad ("KVM: x86: Catch potential overrun in MCE setup") Signed-off-by: Jue Wang Signed-off-by: Jim Mattson Reviewed-by: Peter Shier Message-Id: <20200511225616.19557-1-jmattson@google.com> Reviewed-by: Vitaly Kuznetsov Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman

riscv: perf: RISCV_BASE_PMU should be independent

2020-05-20T06:22:37Z

commit 48084c3595cb7429f6ba734cfea1313573b9a7fa upstream. Selecting PERF_EVENTS without selecting RISCV_BASE_PMU results in a build error. Signed-off-by: Kefeng Wang [Palmer: commit text] Fixes: 178e9fc47aae("perf: riscv: preliminary RISC-V support") Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman

RDMA/uverbs: Move IB_EVENT_DEVICE_FATAL to destroy_uobj

2020-05-20T06:22:37Z

commit ccfdbaa5cf4601b9b71601893029dcc9245c002b upstream. When multiple async FDs were allowed to exist the idea was for all broadcast events to be delivered to all async FDs, however IB_EVENT_DEVICE_FATAL was missed. Instead of having ib_uverbs_free_hw_resources() special case the global async_fd, have it cause the event during the uobject destruction. Every async fd is now a uobject so simply generate the IB_EVENT_DEVICE_FATAL while destroying the async fd uobject. This ensures every async FD gets a copy of the event. Fixes: d680e88e2013 ("RDMA/core: Add UVERBS_METHOD_ASYNC_EVENT_ALLOC") Link: https://lore.kernel.org/r/20200507063348.98713-3-leon@kernel.org Signed-off-by: Yishai Hadas Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman

RDMA/uverbs: Do not discard the IB_EVENT_DEVICE_FATAL event

2020-05-20T06:22:37Z

commit c485b19d52c4ba269dfd027945dee81755fdd530 upstream. The commit below moved all of the destruction to the disassociate step and cleaned up the event channel during destroy_uobj. However, when ib_uverbs_free_hw_resources() pushes IB_EVENT_DEVICE_FATAL and then immediately goes to destroy all uobjects this causes ib_uverbs_free_event_queue() to discard the queued event if userspace hasn't already read() it. Unlike all other event queues async FD needs to defer the ib_uverbs_free_event_queue() until FD release. This still unregisters the handler from the IB device during disassociation. Fixes: 3e032c0e92aa ("RDMA/core: Make ib_uverbs_async_event_file into a uobject") Link: https://lore.kernel.org/r/20200507063348.98713-2-leon@kernel.org Signed-off-by: Yishai Hadas Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman

powerpc/ima: Fix secure boot rules in ima arch policy

2020-05-20T06:22:36Z

commit fa4f3f56ccd28ac031ab275e673ed4098855fed4 upstream. To prevent verifying the kernel module appended signature twice (finit_module), once by the module_sig_check() and again by IMA, powerpc secure boot rules define an IMA architecture specific policy rule only if CONFIG_MODULE_SIG_FORCE is not enabled. This, unfortunately, does not take into account the ability of enabling "sig_enforce" on the boot command line (module.sig_enforce=1). Including the IMA module appraise rule results in failing the finit_module syscall, unless the module signing public key is loaded onto the IMA keyring. This patch fixes secure boot policy rules to be based on CONFIG_MODULE_SIG instead. Fixes: 4238fad366a6 ("powerpc/ima: Add support to initialize ima policy rules") Signed-off-by: Nayna Jain Signed-off-by: Michael Ellerman Signed-off-by: Mimi Zohar Link: https://lore.kernel.org/r/1588342612-14532-1-git-send-email-nayna@linux.ibm.com Signed-off-by: Greg Kroah-Hartman