5.10.41-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainercover 5.10.41-rc1 review
This is the start of the stable review cycle for the 5.10.41 release. There are 9 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 29 May 2021 15:11:29 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.41-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 5.10.41-rc1
Dongliang Mu <[email protected]>
NFC: nci: fix memory leak in nci_allocate_device
Dave Rigby <[email protected]>
perf unwind: Set userdata for all __report_module() paths
Jan Kratochvil <[email protected]>
perf unwind: Fix separate debug info files when using elfutils' libdw's unwinder
Wanpeng Li <[email protected]>
KVM: x86: Defer vtime accounting 'til after IRQ handling
Wanpeng Li <[email protected]>
context_tracking: Move guest exit vtime accounting to separate helpers
Wanpeng Li <[email protected]>
context_tracking: Move guest exit context tracking to separate helpers
Daniel Borkmann <[email protected]>
bpf: No need to simulate speculative domain for immediates
Daniel Borkmann <[email protected]>
bpf: Fix mask direction swap upon off reg sign change
Daniel Borkmann <[email protected]>
bpf: Wrap aux data inside bpf_sanitize_info container
-------------
Diffstat:
Makefile | 4 ++-- arch/x86/kvm/svm/svm.c | 6 +++--- arch/x86/kvm/vmx/vmx.c | 6 +++--- arch/x86/kvm/x86.c | 9 ++++++++ include/linux/context_tracking.h | 25 ++++++++++++++++++---- include/net/nfc/nci_core.h | 1 + kernel/bpf/verifier.c | 46 ++++++++++++++++++++++++---------------- net/nfc/nci/core.c | 1 + net/nfc/nci/hci.c | 5 +++++ tools/perf/util/unwind-libdw.c | 35 ++++++++++++++++++++++++++---- 10 files changed, 104 insertions(+), 34 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/9 bpf: Wrap aux data inside bpf_sanitize_info container
From: Daniel Borkmann <[email protected]>
commit 3d0220f6861d713213b015b582e9f21e5b28d2e0 upstream.
Add a container structure struct bpf_sanitize_info which holds the current aux info, and update call-sites to sanitize_ptr_alu() to pass it in. This is needed for passing in additional state later on.
--- kernel/bpf/verifier.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-)
kernel/bpf/verifier.c +11 -7
@@ -5743,15 +5743,19 @@ static bool sanitize_needed(u8 opcode)return opcode ==BPF_ADD || opcode ==BPF_SUB ; } +struct bpf_sanitize_info { +struct bpf_insn_aux_data aux; +}; +static int sanitize_ptr_alu (struct bpf_verifier_env *env,struct bpf_insn *insn,const struct bpf_reg_state *ptr_reg,const struct bpf_reg_state *off_reg,struct bpf_reg_state *dst_reg, -struct bpf_insn_aux_data *tmp_aux, +struct bpf_sanitize_info *info,const bool commit_window) { -struct bpf_insn_aux_data *aux = commit_window ?cur_aux (env) : tmp_aux; +struct bpf_insn_aux_data *aux = commit_window ?cur_aux (env) : &info->aux;struct bpf_verifier_state *vstate = env->cur_state;bool off_is_imm =tnum_is_const (off_reg->var_off);bool off_is_neg = off_reg->smin_value <0 ;
@@ -5780,8 +5784,8 @@ static int sanitize_ptr_alu(struct bpf_v/* In commit phase we narrow the masking window based on * the observed pointer move after the simulated operation. */ - alu_state = tmp_aux->alu_state; - alu_limit =abs (tmp_aux->alu_limit - alu_limit); + alu_state = info->aux.alu_state; + alu_limit =abs (info->aux.alu_limit - alu_limit); }else { alu_state = off_is_neg ?BPF_ALU_NEG_VALUE :0 ; alu_state |= off_is_imm ?BPF_ALU_IMMEDIATE :0 ;
@@ -5942,7 +5946,7 @@ static int adjust_ptr_min_max_vals(struc smin_ptr = ptr_reg->smin_value, smax_ptr = ptr_reg->smax_value;u64 umin_val = off_reg->umin_value, umax_val = off_reg->umax_value, umin_ptr = ptr_reg->umin_value, umax_ptr = ptr_reg->umax_value; -struct bpf_insn_aux_data tmp_aux = {}; +struct bpf_sanitize_info info = {};u8 opcode =BPF_OP (insn->code);u32 dst = insn->dst_reg;int ret;
@@ -6011,7 +6015,7 @@ static int adjust_ptr_min_max_vals(strucif (sanitize_needed (opcode)) { ret =sanitize_ptr_alu (env, insn, ptr_reg, off_reg, dst_reg, - &tmp_aux, false); + &info, false);if (ret <0 )return sanitize_err (env, insn, ret, off_reg, dst_reg); }
@@ -6152,7 +6156,7 @@ static int adjust_ptr_min_max_vals(strucreturn -EACCES ;if (sanitize_needed (opcode)) { ret =sanitize_ptr_alu (env, insn, dst_reg, off_reg, dst_reg, - &tmp_aux, true); + &info, true);if (ret <0 )return sanitize_err (env, insn, ret, off_reg, dst_reg); }
Greg Kroah-Hartman
maintainerPATCH 2/9 bpf: Fix mask direction swap upon off reg sign change
In reply to Greg Kroah-HartmanFrom: Daniel Borkmann <[email protected]>
commit bb01a1bba579b4b1c5566af24d95f1767859771e upstream.
Masking direction as indicated via mask_to_left is considered to be calculated once and then used to derive pointer limits. Thus, this needs to be placed into bpf_sanitize_info instead so we can pass it to sanitize_ptr_alu() call after the pointer move. Piotr noticed a corner case where the off reg causes masking direction change which then results in an incorrect final aux->alu_limit.
--- kernel/bpf/verifier.c | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-)
kernel/bpf/verifier.c +12 -10
@@ -5666,18 +5666,10 @@ enum { };static int retrieve_ptr_limit (const struct bpf_reg_state *ptr_reg, -const struct bpf_reg_state *off_reg, -u32 *alu_limit,u8 opcode) +u32 *alu_limit,bool mask_to_left) { -bool off_is_neg = off_reg->smin_value <0 ; -bool mask_to_left = (opcode ==BPF_ADD && off_is_neg) || - (opcode ==BPF_SUB && !off_is_neg);u32 max =0 , ptr_limit =0 ; -if (!tnum_is_const (off_reg->var_off) && - (off_reg->smin_value <0 ) != (off_reg->smax_value <0 )) -return REASON_BOUNDS ; -switch (ptr_reg->type) {case PTR_TO_STACK :/* Offset 0 is out-of-bounds, but acceptable start for the
@@ -5745,6 +5737,7 @@ static bool sanitize_needed(u8 opcode)struct bpf_sanitize_info {struct bpf_insn_aux_data aux; +bool mask_to_left; }; static int sanitize_ptr_alu(struct bpf_verifier_env *env,
@@ -5776,7 +5769,16 @@ static int sanitize_ptr_alu(struct bpf_vif (vstate->speculative) goto do_sim; - err =retrieve_ptr_limit (ptr_reg, off_reg, &alu_limit, opcode); +if (!commit_window) { +if (!tnum_is_const (off_reg->var_off) && + (off_reg->smin_value <0 ) != (off_reg->smax_value <0 )) +return REASON_BOUNDS ; + + info->mask_to_left = (opcode ==BPF_ADD && off_is_neg) || + (opcode ==BPF_SUB && !off_is_neg); + } + + err =retrieve_ptr_limit (ptr_reg, &alu_limit, info->mask_to_left);if (err <0 )return err;
Greg Kroah-Hartman
maintainerPATCH 3/9 bpf: No need to simulate speculative domain for immediates
In reply to Greg Kroah-HartmanFrom: Daniel Borkmann <[email protected]>
commit a7036191277f9fa68d92f2071ddc38c09b1e5ee5 upstream.
In 801c6058d14a ("bpf: Fix leakage of uninitialized bpf stack under speculation") we replaced masking logic with direct loads of immediates if the register is a known constant. Given in this case we do not apply any masking, there is also no reason for the operation to be truncated under the speculative domain.
Therefore, there is also zero reason for the verifier to branch-off and simulate this case, it only needs to do it for unknown but bounded scalars. As a side-effect, this also enables few test cases that were previously rejected due to simulation under zero truncation.
--- kernel/bpf/verifier.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
kernel/bpf/verifier.c +5 -1
@@ -5802,8 +5802,12 @@ do_sim:/* If we're in commit phase, we're done here given we already * pushed the truncated dst_reg into the speculative verification * stack. +* +* Also, when register is a known constant, we rewrite register-based +* operation to immediate-based, and thus do not need masking (and as +* a consequence, do not need to simulate the zero-truncation either). */ -if (commit_window) +if (commit_window || off_is_imm)return 0 ;/* Simulate and find potential out-of-bounds access under
Greg Kroah-Hartman
maintainerPATCH 4/9 context_tracking: Move guest exit context tracking to separate helpers
In reply to Greg Kroah-HartmanFrom: Wanpeng Li <[email protected]>
commit 866a6dadbb027b2955a7ae00bab9705d382def12 upstream.
Provide separate context tracking helpers for guest exit, the standalone helpers will be called separately by KVM x86 in later patches to fix tick-based accounting.
--- include/linux/context_tracking.h | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
include/linux/context_tracking.h +8 -1
@@ -129,10 +129,15 @@ static __always_inline void guest_enter_ } } -static __always_inline void guest_exit_irqoff(void) +static __always_inline void context_tracking_guest_exit(void) {if (context_tracking_enabled ())__context_tracking_exit (CONTEXT_GUEST ); +} + +static __always_inline void guest_exit_irqoff(void) +{ +context_tracking_guest_exit ();instrumentation_begin ();if (vtime_accounting_enabled_this_cpu ())
@@ -157,6 +162,8 @@ static __always_inline void guest_enter_instrumentation_end (); } +static __always_inline void context_tracking_guest_exit(void) { } + static __always_inline void guest_exit_irqoff(void) {instrumentation_begin ();
Greg Kroah-Hartman
maintainerPATCH 5/9 context_tracking: Move guest exit vtime accounting to separate helpers
In reply to Greg Kroah-HartmanFrom: Wanpeng Li <[email protected]>
commit 88d8220bbf06dd8045b2ac4be1046290eaa7773a upstream.
Provide separate vtime accounting functions for guest exit instead of open coding the logic within the context tracking code. This will allow KVM x86 to handle vtime accounting slightly differently when using tick-based accounting.
--- include/linux/context_tracking.h | 22 ++++++++++++++++------ 1 file changed, 16 insertions(+), 6 deletions(-)
include/linux/context_tracking.h +16 -6
@@ -135,15 +135,20 @@ static __always_inline void context_trac__context_tracking_exit (CONTEXT_GUEST ); } -static __always_inline void guest_exit_irqoff(void) +static __always_inline void vtime_account_guest_exit(void) { -context_tracking_guest_exit (); - -instrumentation_begin ();if (vtime_accounting_enabled_this_cpu ())vtime_guest_exit (current);else current->flags &= ~PF_VCPU ; +} + +static __always_inline void guest_exit_irqoff(void) +{ +context_tracking_guest_exit (); + +instrumentation_begin (); +vtime_account_guest_exit ();instrumentation_end (); }
@@ -164,12 +169,17 @@ static __always_inline void guest_enter_ static __always_inline void context_tracking_guest_exit(void) { } +static __always_inline void vtime_account_guest_exit(void) +{ +vtime_account_kernel (current); + current->flags &= ~PF_VCPU ; +} + static __always_inline void guest_exit_irqoff(void) {instrumentation_begin ();/* Flush the guest cputime we spent on the guest */ -vtime_account_kernel (current); - current->flags &= ~PF_VCPU ; +vtime_account_guest_exit ();instrumentation_end (); }#endif /* CONFIG_VIRT_CPU_ACCOUNTING_GEN */
Greg Kroah-Hartman
maintainerPATCH 6/9 KVM: x86: Defer vtime accounting til after IRQ handling
In reply to Greg Kroah-HartmanFrom: Wanpeng Li <[email protected]>
commit 160457140187c5fb127b844e5a85f87f00a01b14 upstream.
Defer the call to account guest time until after servicing any IRQ(s) that happened in the guest or immediately after VM-Exit. Tick-based accounting of vCPU time relies on PF_VCPU being set when the tick IRQ handler runs, and IRQs are blocked throughout the main sequence of vcpu_enter_guest(), including the call into vendor code to actually enter and exit the guest.
This fixes a bug where reported guest time remains '0', even when running an infinite loop in the guest:
https://bugzilla.kernel.org/show_bug.cgi?id=209831
--- arch/x86/kvm/svm/svm.c | 6 +++--- arch/x86/kvm/vmx/vmx.c | 6 +++--- arch/x86/kvm/x86.c | 9 +++++++++ 3 files changed, 15 insertions(+), 6 deletions(-)
arch/x86/kvm/svm/svm.c +3 -3
@@ -3532,15 +3532,15 @@ static noinstr void svm_vcpu_enter_exit(* have them in state 'on' as recorded before entering guest mode. * Same as enter_from_user_mode(). * -* guest_exit_irqoff() restores host context and reinstates RCU if -* enabled and required. +* context_tracking_guest_exit() restores host context and reinstates +* RCU if enabled and required. * * This needs to be done before the below as native_read_msr() * contains a tracepoint and x86_spec_ctrl_restore_host() calls * into world and some more. */ lockdep_hardirqs_off (CALLER_ADDR0 ); -guest_exit_irqoff (); +context_tracking_guest_exit ();instrumentation_begin ();trace_hardirqs_off_finish ();
arch/x86/kvm/vmx/vmx.c +3 -3
@@ -6640,15 +6640,15 @@ static noinstr void vmx_vcpu_enter_exit(* have them in state 'on' as recorded before entering guest mode. * Same as enter_from_user_mode(). * -* guest_exit_irqoff() restores host context and reinstates RCU if -* enabled and required. +* context_tracking_guest_exit() restores host context and reinstates +* RCU if enabled and required. * * This needs to be done before the below as native_read_msr() * contains a tracepoint and x86_spec_ctrl_restore_host() calls * into world and some more. */ lockdep_hardirqs_off (CALLER_ADDR0 ); -guest_exit_irqoff (); +context_tracking_guest_exit ();instrumentation_begin ();trace_hardirqs_off_finish ();
arch/x86/kvm/x86.c +9 -0
@@ -9063,6 +9063,15 @@ static int vcpu_enter_guest(struct kvm_vlocal_irq_disable ();kvm_after_interrupt (vcpu); +/* +* Wait until after servicing IRQs to account guest time so that any +* ticks that occurred while running the guest are properly accounted +* to the guest. Waiting until IRQs are enabled degrades the accuracy +* of accounting via context tracking, but the loss of accuracy is +* acceptable for all known use cases. +*/ +vtime_account_guest_exit (); +if (lapic_in_kernel (vcpu)) {s64 delta = vcpu->arch.apic->lapic_timer.advance_expire_delta;if (delta !=S64_MIN ) {
Greg Kroah-Hartman
maintainerPATCH 7/9 perf unwind: Fix separate debug info files when using elfutils libdws unwinder
In reply to Greg Kroah-HartmanFrom: Jan Kratochvil <[email protected]>
commit bf53fc6b5f415cddc7118091cb8fd6a211b2320d upstream.
elfutils needs to be provided main binary and separate debug info file respectively. Providing separate debug info file instead of the main binary is not sufficient.
One needs to try both supplied filename and its possible cache by its build-id depending on the use case.
--- tools/perf/util/unwind-libdw.c | 32 +++++++++++++++++++++++++++----- 1 file changed, 27 insertions(+), 5 deletions(-)
tools/perf/util/unwind-libdw.c +27 -5
@@ -20,10 +20,24 @@static char *debuginfo_path; +static int __find_debuginfo (Dwfl_Module *mod__maybe_unused ,void **userdata, +const char *modname__maybe_unused ,Dwarf_Addr base__maybe_unused , +const char *file_name,const char *debuglink_file__maybe_unused , +GElf_Word debuglink_crc__maybe_unused ,char **debuginfo_file_name) +{ +const struct dso *dso = *userdata; + +assert (dso); +if (dso->symsrc_filename &&strcmp (file_name, dso->symsrc_filename)) + *debuginfo_file_name =strdup (dso->symsrc_filename); +return -1 ; +} +static const Dwfl_Callbacks offline_callbacks = { - .find_debuginfo = dwfl_standard_find_debuginfo, + .find_debuginfo = __find_debuginfo, .debuginfo_path = &debuginfo_path, .section_address = dwfl_offline_section_address, +// .find_elf is not set as we use dwfl_report_elf() instead. }; static int __report_module(struct addr_location *al, u64 ip,
@@ -46,16 +60,24 @@ static int __report_module(struct addr_l mod =dwfl_addrmodule (ui->dwfl, ip);if (mod) {Dwarf_Addr s; +void **userdatap; -dwfl_module_info (mod,NULL , &s,NULL ,NULL ,NULL ,NULL ,NULL ); +dwfl_module_info (mod, &userdatap, &s,NULL ,NULL ,NULL ,NULL ,NULL ); + *userdatap = dso;if (s != al->map->start - al->map->pgoff) mod =0 ; }if (!mod) - mod =dwfl_report_elf (ui->dwfl, dso->short_name, - (dso->symsrc_filename ? dso->symsrc_filename : dso->long_name),-1 , al->map->start - al->map->pgoff, - false); + mod =dwfl_report_elf (ui->dwfl, dso->short_name, dso->long_name,-1 , + al->map->start - al->map->pgoff, false); +if (!mod) { +char filename[PATH_MAX ]; + +if (dso__build_id_filename (dso, filename,sizeof (filename), false)) + mod =dwfl_report_elf (ui->dwfl, dso->short_name, filename,-1 , + al->map->start - al->map->pgoff, false); + }return mod &&dwfl_addrmodule (ui->dwfl, ip) == mod ?0 :-1 ; }
Greg Kroah-Hartman
maintainerPATCH 8/9 perf unwind: Set userdata for all __report_module() paths
In reply to Greg Kroah-HartmanFrom: Dave Rigby <[email protected]>
commit 4e1481445407b86a483616c4542ffdc810efb680 upstream.
When locating the DWARF module for a given address, __find_debuginfo() requires a 'struct dso' passed via the userdata argument.
However, this field is only set in __report_module() if the module is found in via dwfl_addrmodule(), not if it is found later via dwfl_report_elf().
Set userdata irrespective of how the DWARF module was found, as long as we found a module.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=211801
--- tools/perf/util/unwind-libdw.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
tools/perf/util/unwind-libdw.c +8 -3
@@ -60,10 +60,8 @@ static int __report_module(struct addr_l mod =dwfl_addrmodule (ui->dwfl, ip);if (mod) {Dwarf_Addr s; -void **userdatap; -dwfl_module_info (mod, &userdatap, &s,NULL ,NULL ,NULL ,NULL ,NULL ); - *userdatap = dso; +dwfl_module_info (mod,NULL , &s,NULL ,NULL ,NULL ,NULL ,NULL );if (s != al->map->start - al->map->pgoff) mod =0 ; }
@@ -79,6 +77,13 @@ static int __report_module(struct addr_l al->map->start - al->map->pgoff, false); } +if (mod) { +void **userdatap; + +dwfl_module_info (mod, &userdatap,NULL ,NULL ,NULL ,NULL ,NULL ,NULL ); + *userdatap = dso; + } +return mod &&dwfl_addrmodule (ui->dwfl, ip) == mod ?0 :-1 ; }
Greg Kroah-Hartman
maintainerPATCH 9/9 NFC: nci: fix memory leak in nci_allocate_device
In reply to Greg Kroah-HartmanFrom: Dongliang Mu <[email protected]>
commit e0652f8bb44d6294eeeac06d703185357f25d50b upstream.
nfcmrvl_disconnect fails to free the hci_dev field in struct nci_dev. Fix this by freeing hci_dev in nci_free_device.
BUG: memory leak
unreferenced object 0xffff888111ea6800 (size 1024):
comm "kworker/1:0", pid 19, jiffies 4294942308 (age 13.580s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 60 fd 0c 81 88 ff ff .........`......
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<000000004bc25d43>] kmalloc include/linux/slab.h:552 [inline]
[<000000004bc25d43>] kzalloc include/linux/slab.h:682 [inline]
[<000000004bc25d43>] nci_hci_allocate+0x21/0xd0 net/nfc/nci/hci.c:784
[<00000000c59cff92>] nci_allocate_device net/nfc/nci/core.c:1170 [inline]
[<00000000c59cff92>] nci_allocate_device+0x10b/0x160 net/nfc/nci/core.c:1132
[<00000000006e0a8e>] nfcmrvl_nci_register_dev+0x10a/0x1c0 drivers/nfc/nfcmrvl/main.c:153
[<000000004da1b57e>] nfcmrvl_probe+0x223/0x290 drivers/nfc/nfcmrvl/usb.c:345
[<00000000d506aed9>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396
[<00000000bc632c92>] really_probe+0x159/0x4a0 drivers/base/dd.c:554
[<00000000f5009125>] driver_probe_device+0x84/0x100 drivers/base/dd.c:740
[<000000000ce658ca>] __device_attach_driver+0xee/0x110 drivers/base/dd.c:846
[<000000007067d05f>] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:431
[<00000000f8e13372>] __device_attach+0x122/0x250 drivers/base/dd.c:914
[<000000009cf68860>] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:491
[<00000000359c965a>] device_add+0x5be/0xc30 drivers/base/core.c:3109
[<00000000086e4bd3>] usb_set_configuration+0x9d9/0xb90 drivers/usb/core/message.c:2164
[<00000000ca036872>] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238
[<00000000d40d36f6>] usb_probe_device+0x5c/0x140 drivers/usb/core/driver.c:293
[<00000000bc632c92>] really_probe+0x159/0x4a0 drivers/base/dd.c:554--- include/net/nfc/nci_core.h | 1 + net/nfc/nci/core.c | 1 + net/nfc/nci/hci.c | 5 +++++ 3 files changed, 7 insertions(+)
include/net/nfc/nci_core.h +1 -0
@@ -298,6 +298,7 @@ int nci_nfcc_loopback(struct nci_dev *nd struct sk_buff **resp);struct nci_hci_dev *nci_hci_allocate (struct nci_dev *ndev); +void nci_hci_deallocate (struct nci_dev *ndev);int nci_hci_send_event (struct nci_dev *ndev,u8 gate,u8 event,const u8 *param,size_t param_len); int nci_hci_send_cmd(struct nci_dev *ndev, u8 gate,
net/nfc/nci/core.c +1 -0
@@ -1175,6 +1175,7 @@ EXPORT_SYMBOL(nci_allocate_device);void nci_free_device (struct nci_dev *ndev) {nfc_free_device (ndev->nfc_dev); +nci_hci_deallocate (ndev);kfree (ndev); }EXPORT_SYMBOL (nci_free_device);
net/nfc/nci/hci.c +5 -0
@@ -795,3 +795,8 @@ struct nci_hci_dev *nci_hci_allocate(strreturn hdev; } + +void nci_hci_deallocate (struct nci_dev *ndev) +{ +kfree (ndev->hci_dev); +}
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.41 release. There are 9 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 29 May 2021 15:11:29 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.41-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.10.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v5.10:
12 builds: 12 pass, 0 fail
28 boots: 28 pass, 0 fail
70 tests: 70 pass, 0 failLinux version: 5.10.41-rc1-gec1cc3ee7be2
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04Jon
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.41 release. There are 9 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 29 May 2021 15:11:29 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.41-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.10.y
and the diffstat can be found below.thanks,
greg k-h
5.10.41-rc1 Successfully Compiled and booted on my Raspberry PI 4b (8g) (bcm2711)
Hi!
Quoted 4 lines
This is the start of the stable review cycle for the 5.10.41 release. There are 9 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
CIP testing did not find any problems here:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.10.y
Best regards,
Pavel
Signature · 2 lines
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.41 release. There are 9 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 29 May 2021 15:11:29 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.41-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.10.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.41 release. There are 9 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 29 May 2021 15:11:29 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.41-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.10.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB, using 32-bit and 64-bit ARM kernels:
Signature · 1 line
Florian
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.41 release. There are 9 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 29 May 2021 15:11:29 +0000. Anything received after that time might be too late.
Build results:
total: 156 pass: 156 fail: 0 Qemu test results: total: 455 pass: 455 fail: 0
Guenter
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.41 release. There are 9 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 29 May 2021 15:11:29 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.41-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.10.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
## Build
* kernel: 5.10.41-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git branch: linux-5.10.y
* git commit: ec1cc3ee7be23032bad8bf00052c9b75fdfe9971
* git describe: v5.10.40-10-gec1cc3ee7be2
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.40-10-gec1cc3ee7be2
## No regressions (compared to v5.10.40)
## No fixes (compared to v5.10.40)
## Test result summary
total: 78784, pass: 64361, fail: 2504, skip: 11224, xfail: 695,
## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 193 total, 193 passed, 0 failed
* arm64: 27 total, 27 passed, 0 failed
* dragonboard-410c: 1 total, 1 passed, 0 failed
* hi6220-hikey: 1 total, 1 passed, 0 failed
* i386: 26 total, 26 passed, 0 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 45 total, 45 passed, 0 failed
* parisc: 9 total, 9 passed, 0 failed
* powerpc: 27 total, 27 passed, 0 failed
* riscv: 21 total, 21 passed, 0 failed
* s390: 18 total, 18 passed, 0 failed
* sh: 18 total, 18 passed, 0 failed
* sparc: 9 total, 9 passed, 0 failed
* x15: 1 total, 1 passed, 0 failed
* x86: 1 total, 1 passed, 0 failed
* x86_64: 27 total, 27 passed, 0 failed
## Test suites summary
* fwts
* igt-gpu-tools
* install-android-platform-tools-r2600
* kselftest-
* kselftest-android
* kselftest-bpf
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-lkdtm
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-vsyscall-mode-native-
* kselftest-vsyscall-mode-none-
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* packetdrill
* perf
* rcutorture
* ssuite
* v4l2-compliance
--
Linaro LKFT
https://lkft.linaro.org
Hi Greg,
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.41 release. There are 9 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 29 May 2021 15:11:29 +0000. Anything received after that time might be too late.
Build test:
mips (gcc version 11.1.1 20210523): 63 configs -> no failure arm (gcc version 11.1.1 20210523): 105 configs -> no new failure arm64 (gcc version 11.1.1 20210523): 2 configs -> no failure x86_64 (gcc version 10.2.1 20210110): 2 configs -> no failure
Boot test:x86_64: Booted on my test laptop. No regression.x86_64: Booted on qemu. No regression.
arm64: Booted on rpi4b (4GB model). No regression.
--
Regards
Sudip
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.41 release. There are 9 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 29 May 2021 15:11:29 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.41-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.10.y
and the diffstat can be found below.thanks,
greg k-h
Tested on arm64 and x86 for 5.10.41-rc1,
Kernel repo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Branch: linux-5.10.y
Version: 5.10.41-rc1
Commit: ec1cc3ee7be23032bad8bf00052c9b75fdfe9971
Compiler: gcc version 7.3.0 (GCC)
arm64:
--------------------------------------------------------------------
Testcase Result Summary:
total: 8896
passed: 8896
failed: 0
timeout: 0
--------------------------------------------------------------------
x86:
--------------------------------------------------------------------
Testcase Result Summary:
total: 8896
passed: 8896
failed: 0
timeout: 0
--------------------------------------------------------------------